資訊專欄INFORMATION COLUMN
執(zhí)行如下sql：
select * from test where (from_id=89090909090909 or to_id=89090909090909); |
某天應用突然聯(lián)系說查詢出錯誤結果集，因為涉及核心數(shù)據(jù)庫，這讓我緊張了一下。經(jīng)過與應用溝通，可以判斷，不管是程序jdbc連接還是plsql客戶端連接都可以復現(xiàn)問題。與應用溝通后，我也拿到sql進行了測試，問題復現(xiàn)的概率很高。到這里這個問題已經(jīng)很難進行下去了，sql比較簡單，mos上搜索后未發(fā)現(xiàn)相關的bug。于是提交oracle后臺分析，大家都懂的，oracle后臺提供了相應的文檔腳本收集相關日志。但效果并不好，來來回回收集了很多次日志也未能抓到異常信息。
再次與應用溝通，發(fā)現(xiàn)最后一列是通過addcloumn方式添加的，且是notnull的。通過mos搜索發(fā)現(xiàn)，還真有符合這種情況的bug：
可惜沒有符合當前你19.6版本數(shù)據(jù)庫的。
在溝通過程中已經(jīng)發(fā)現(xiàn)了可能和addcolumn，且是notnull方式添加字段有關。于是按原表表結構新建一張表：
場景一、最后一個字段建表后再添加，問題可以復現(xiàn)；
場景二、最后一個字段建表時一起建上，問題未能復現(xiàn)。
當前：按以上場景二方式重建表即可。
文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉載請注明本文地址：http://systransis.cn/yun/129948.html
19C?DG?Broker配置和測試 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; ...
摘要：前言在使用加載數(shù)據(jù)數(shù)據(jù)庫常見的優(yōu)化操作后端掘金一索引將放第一位，不用說，這種優(yōu)化方式我們一直都在悄悄使用，那便是主鍵索引。 Redis 內存壓縮實戰(zhàn) - 后端 - 掘金在討論Redis內存壓縮的時候，我們需要了解一下幾個Redis的相關知識。 壓縮列表 ziplist Redis的ziplist是用一段連續(xù)的內存來存儲列表數(shù)據(jù)的一個數(shù)據(jù)結構，它的結構示例如下圖 zlbytes: 記錄整...
閱讀 1356·2023-01-11 13:20
閱讀 1707·2023-01-11 13:20
閱讀 1215·2023-01-11 13:20
閱讀 1906·2023-01-11 13:20
閱讀 4165·2023-01-11 13:20
閱讀 2757·2023-01-11 13:20
閱讀 1402·2023-01-11 13:20
閱讀 3671·2023-01-11 13:20
