資訊專欄INFORMATION COLUMN
執(zhí)行如下sql：
select * from test where (from_id=89090909090909 or to_id=89090909090909); |
某天應(yīng)用突然聯(lián)系說查詢出錯誤結(jié)果集，因為涉及核心數(shù)據(jù)庫，這讓我緊張了一下。經(jīng)過與應(yīng)用溝通，可以判斷，不管是程序jdbc連接還是plsql客戶端連接都可以復(fù)現(xiàn)問題。與應(yīng)用溝通后，我也拿到sql進(jìn)行了測試，問題復(fù)現(xiàn)的概率很高。到這里這個問題已經(jīng)很難進(jìn)行下去了，sql比較簡單，mos上搜索后未發(fā)現(xiàn)相關(guān)的bug。于是提交oracle后臺分析，大家都懂的，oracle后臺提供了相應(yīng)的文檔腳本收集相關(guān)日志。但效果并不好，來來回回收集了很多次日志也未能抓到異常信息。
再次與應(yīng)用溝通，發(fā)現(xiàn)最后一列是通過addcloumn方式添加的，且是notnull的。通過mos搜索發(fā)現(xiàn)，還真有符合這種情況的bug：
可惜沒有符合當(dāng)前你19.6版本數(shù)據(jù)庫的。
在溝通過程中已經(jīng)發(fā)現(xiàn)了可能和addcolumn，且是notnull方式添加字段有關(guān)。于是按原表表結(jié)構(gòu)新建一張表：
場景一、最后一個字段建表后再添加，問題可以復(fù)現(xiàn)；
場景二、最后一個字段建表時一起建上，問題未能復(fù)現(xiàn)。
當(dāng)前：按以上場景二方式重建表即可。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.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 內(nèi)存壓縮實戰(zhàn) - 后端 - 掘金在討論Redis內(nèi)存壓縮的時候，我們需要了解一下幾個Redis的相關(guān)知識。 壓縮列表 ziplist Redis的ziplist是用一段連續(xù)的內(nèi)存來存儲列表數(shù)據(jù)的一個數(shù)據(jù)結(jié)構(gòu)，它的結(jié)構(gòu)示例如下圖 zlbytes: 記錄整...
閱讀 1459·2023-01-11 13:20
閱讀 1812·2023-01-11 13:20
閱讀 1263·2023-01-11 13:20
閱讀 2005·2023-01-11 13:20
閱讀 4226·2023-01-11 13:20
閱讀 2879·2023-01-11 13:20
閱讀 1488·2023-01-11 13:20
閱讀 3807·2023-01-11 13:20
