1. ORA-00600 KGL-heap-size-exceeded 到底卡在哪ORA-00600 [KGL-heap-size-exceeded] 是 Oracle 數(shù)據(jù)庫里比較典型的一類內(nèi)部錯(cuò)誤字面意思是 KGLKernel Generic Library堆內(nèi)存超限。KGL 堆主要存放游標(biāo)、庫緩存對象、SQL 元數(shù)據(jù)這些東西它跟 shared pool 是綁在一起的。一旦 KGL 堆被撐爆數(shù)據(jù)庫會(huì)大量生成 core 文件業(yè)務(wù) TPS 直接掉到接近 0等故障時(shí)段過去又自己恢復(fù)然后高峰期再反復(fù)出現(xiàn)。這個(gè)場景適合誰看手上有一套 Oracle 12.2 環(huán)境、alert 日志里出現(xiàn)過 KGL-heap-size-exceeded、shared pool 等待嚴(yán)重、SQL version count 高到離譜的 DBA 或運(yùn)維同學(xué)。核心檢索詞就是 ORA-00600、KGL-heap-size-exceeded、cursor 不共享、BIND_EQUIV_FAILURE。我先把問題鏈路捋一遍。故障時(shí)間點(diǎn)看 AWRshared pool 相關(guān)等待非常重KGL 占用 9G 以上shared pool 統(tǒng)計(jì)占用到 90% 左右。報(bào)錯(cuò) SQL 的 version count 達(dá)到 900而_cursor_obsolete_threshold當(dāng)時(shí)是 1024也就是說游標(biāo)版本還沒到淘汰閾值但已經(jīng)堆了一大片。用V$SQL_BIND_CAPTURE和v$sql_shared_cursor查 cursor 為什么不共享發(fā)現(xiàn)BIND_EQUIV_FAILURE為 Y綁定變量等價(jià)性判斷失敗導(dǎo)致同一個(gè) SQL 反復(fù)生成子游標(biāo)KGL 堆被這些子游標(biāo)撐滿。常規(guī)動(dòng)作是加 shared pool從 20G 調(diào)到 40G故障確實(shí)不再出現(xiàn)但那條 SQL 的 version count 依舊很高。再把_cursor_obsolete_threshold從 1024 降到 50version count 才緩解。查 MOS 2610645.1發(fā)現(xiàn)BIND_EQUIV_FAILURE可能是 12.2 的 bug官方給了 Patch 28794230 和一組_optimizer_use_feedback、_optimizer_adaptive_cursor_sharing、_optimizer_extended_cursor_sharing_rel的 workaround。問題在于這些線索散落在 AWR、V$ 視圖、MOS 文檔和一堆隱藏參數(shù)里人工對照很費(fèi)時(shí)間。我想把 Codex 接到 TaoToken 的統(tǒng)一 API 通道上讓它幫我整理排查思路、對照 MOS 方案取舍但 Codex 本身不連 Oracle數(shù)據(jù)庫側(cè)的 SQL、AWR、alter system 還是我在本地 SQL*Plus 里執(zhí)行只把粘貼出來的結(jié)果交給 Codex 分析。2. 把 Codex 的 Base URL 改到 TaoToken這一步是前置準(zhǔn)備。TaoToken 只提供 Key 和 Base URL讓 Codex 走統(tǒng)一 API 通道不碰你的數(shù)據(jù)庫。先打開 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注冊賬號(hào)然后在控制臺(tái)創(chuàng)建 API Key。創(chuàng)建 Key 的入口在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 登錄后點(diǎn)新建復(fù)制那串 Key 存好。Base URL 填https://taotoken.net/api注意兩點(diǎn)不要加/v1也不要用官網(wǎng)首頁地址。很多人習(xí)慣性寫成https://taotoken.net/api/v1結(jié)果請求 404這個(gè)坑我見得太多了。Codex 的配置一般放在~/.codex/config.toml或者環(huán)境變量里下面給一份可復(fù)制的配置。# ~/.codex/config.toml model gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat如果你更習(xí)慣用環(huán)境變量也可以這樣export TAOTOKEN_API_KEYsk-你從TaoToken控制臺(tái)復(fù)制的Key export OPENAI_BASE_URLhttps://taotoken.net/api配置完保存別急著讓它分析 ORA-00600先發(fā)一條普通請求確認(rèn)通道是通的。這一步很關(guān)鍵通道沒通后面全是白費(fèi)。3. 可復(fù)制配置與驗(yàn)證請求3.1 先確認(rèn) Codex 能正常對話在終端里跑一條最簡單的請求確認(rèn) Key 和 Base URL 都生效codex exec 用一句話說明 Oracle shared pool 的作用如果返回正常文本說明 Codex 已經(jīng)通過 TaoToken 兼容通道跑起來了。如果報(bào) 401檢查 Key 有沒有復(fù)制全如果報(bào) 404八成是 Base URL 多寫了/v1。想直接在網(wǎng)頁里驗(yàn)證模型是否可用可以打開模型對話頁 https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 發(fā)一條測試消息能回就說明賬號(hào)和 Key 都沒問題。3.2 數(shù)據(jù)庫側(cè)采集Codex 側(cè)分析記住一個(gè)原則Codex 不連 Oracle。下面這些 SQL 你在本地 SQL*Plus 執(zhí)行把結(jié)果粘貼給 Codex。先看故障時(shí)間點(diǎn)的 shared pool 和 KGL 占用-- 查看 shared pool 各子池占用 SELECT pool, name, bytes/1024/1024 AS mb FROM v$sgastat WHERE pool shared pool AND name IN (free memory, miscellaneous) ORDER BY bytes DESC; -- 查看 KGL 相關(guān)堆占用 SELECT ksmchcls, SUM(ksmchsiz)/1024/1024 AS mb FROM x$ksmsp WHERE ksmchcls LIKE KGL% GROUP BY ksmchcls ORDER BY mb DESC;再看那條 version count 900 的 SQL確認(rèn) cursor 不共享的原因SELECT c.sql_id, c.SQL_TYPE_MISMATCH, c.BIND_EQUIV_FAILURE, b.POSITION, b.DATATYPE_STRING, b.LAST_CAPTURED FROM V$SQL_BIND_CAPTURE b, v$sql_shared_cursor c WHERE c.CHILD_ADDRESS b.CHILD_ADDRESS AND c.SQL_ID 9pvt6prqzddvy;把這兩段結(jié)果、AWR 里 shared pool 等待的片段、以及BIND_EQUIV_FAILUREY的行一起粘貼給 Codex讓它逐條對照原文排查步驟和 MOS 2610645.1 的方案取舍。你可以這樣給它下指令下面是我從 Oracle 12.2 環(huán)境采集的 V$SQL_BIND_CAPTURE、v$sql_shared_cursor 和 AWR 片段。 現(xiàn)象ORA-00600 [KGL-heap-size-exceeded]KGL 占用 9Gshared pool 20G 調(diào)到 40G 后故障消失但 version count 仍高 _cursor_obsolete_threshold 從 1024 降到 50 后緩解BIND_EQUIV_FAILUREY。 請幫我1) 按可能性排序 cursor 不共享的原因2) 對照 MOS 2610645.1 的 Patch 28794230 和 _optimizer_use_feedback 等 workaround 給出取舍建議 3) 列出還需要在本地 SQL*Plus 補(bǔ)采哪些視圖。不要假設(shè)你能連數(shù)據(jù)庫。3.3 參數(shù)調(diào)整的本地執(zhí)行下面這些 alter system 仍然在本地 SQL*Plus 執(zhí)行Codex 只幫你判斷該不該做、順序怎么排-- 調(diào)整 shared pool需根據(jù)實(shí)際 SGA 評(píng)估 ALTER SYSTEM SET shared_pool_size 40G SCOPE SPFILE; -- 降低游標(biāo)淘汰閾值緩解 version count ALTER SYSTEM SET _cursor_obsolete_threshold 50 SCOPE SPFILE; -- MOS 2610645.1 給出的 workaround先評(píng)估再執(zhí)行 ALTER SYSTEM SET _optimizer_use_feedback FALSE SCOPE SPFILE; ALTER SYSTEM SET _optimizer_adaptive_cursor_sharing FALSE SCOPE SPFILE; ALTER SYSTEM SET _optimizer_extended_cursor_sharing_rel NONE SCOPE SPFILE;隱藏參數(shù)改動(dòng)前一定要在測試庫驗(yàn)證生產(chǎn)庫改完要重啟才生效的記得安排窗口。Codex 能幫你把這幾條參數(shù)的影響面、回退方式列清楚但執(zhí)行權(quán)在你手里。4. 驗(yàn)證請求與成功結(jié)果通道驗(yàn)證分兩層。第一層是 Codex 本身可用前面那條codex exec返回正常文本就算過。第二層是讓它真的能處理 ORA-00600 的排查素材。我實(shí)測下來把v$sql_shared_cursor的完整輸出和 AWR 的 Top 10 等待事件粘進(jìn)去Codex 能給出這樣的結(jié)構(gòu)化輸出先按BIND_EQUIV_FAILURE、SQL_TYPE_MISMATCH、ROLL_INVALID_MISMATCH等字段逐項(xiàng)判斷再對照 MOS 2610645.1 說明 Patch 28794230 和 workaround 的適用條件最后列出還需要補(bǔ)采的視圖比如v$sql_shared_cursor里其他標(biāo)志位、v$librarycache的 reload 情況。成功的結(jié)果長這樣你拿到一份排查清單知道先看哪個(gè)字段、哪個(gè)參數(shù)改動(dòng)風(fēng)險(xiǎn)高、哪個(gè) workaround 可以先在測試庫試。數(shù)據(jù)庫側(cè)的 alter system 還是你自己敲Codex 不碰生產(chǎn)庫。如果你后面要長期做這類排查甚至想把 Codex 掛到日常運(yùn)維腳本里做輔助分析可以看看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 適合需要持續(xù)調(diào)用、批量整理排查記錄的場景。5. 本篇常見錯(cuò)排查5.1 Base URL 寫錯(cuò)導(dǎo)致 404最常見的錯(cuò)誤是把 Base URL 寫成https://taotoken.net/api/v1或者直接寫官網(wǎng)首頁。正確值是https://taotoken.net/api不加/v1。報(bào) 404 先查這里。5.2 Key 沒生效報(bào) 401檢查環(huán)境變量名和配置文件里的env_key是否一致。如果你在 config.toml 里寫env_key TAOTOKEN_API_KEY那環(huán)境變量就必須叫這個(gè)名字大小寫敏感。Key 復(fù)制時(shí)前后帶空格也會(huì)導(dǎo)致 401。5.3 讓 Codex 直接連 OracleCodex 不連 Oracle也不該給它數(shù)據(jù)庫連接串。所有 V$ 視圖、AWR、alter system 都在本地 SQL*Plus 執(zhí)行只把文本結(jié)果粘貼過去。試圖讓它直連生產(chǎn)庫既做不到也不安全。5.4 隱藏參數(shù)改完沒重啟_cursor_obsolete_threshold、_optimizer_use_feedback這些用SCOPE SPFILE改的必須重啟實(shí)例才生效。只改 spfile 不重啟查詢v$parameter看到的還是舊值會(huì)誤以為沒生效。5.5 把 shared pool 調(diào)大就當(dāng)解決了shared pool 從 20G 調(diào)到 40G 只是緩解了 KGL 堆被撐爆的速度version count 依舊高說明 cursor 不共享的根因還在。BIND_EQUIV_FAILUREY對應(yīng)的 12.2 bug 和 workaround 才是要對照處理的部分別停在加內(nèi)存這一步。5.6 忽略 core 文件占滿 /oracle 目錄故障時(shí)大量 cdmp core 文件會(huì)把 /oracle 目錄撐滿進(jìn)而引發(fā)更多問題。排查時(shí)先清理 core 文件釋放空間再去看 AWR 和 V$ 視圖否則連日志都寫不進(jìn)去。6. 把 Codex 配通到 TaoToken 之后從 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 拿到 Key把 Codex 的 Base URL 填成https://taotoken.net/api通道就通了。之后你可以在本地 SQL*Plus 采集V$SQL_BIND_CAPTURE、v$sql_shared_cursor、BIND_EQUIV_FAILURE和 KGL 堆超限的線索粘貼給 Codex讓它幫你整理 ORA-00600 與 cursor 共享問題的排查思路、對照 MOS 2610645.1 的方案取舍。接入文檔在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 配置細(xì)節(jié)和參數(shù)說明都在里面?？刂婆_(tái) https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 可以管理 Key 和用量。數(shù)據(jù)庫側(cè)的 alter system 和 Patch 決策始終由你在本地執(zhí)行Codex 只做分析輔助這條邊界別越過去。 ORA-00600 KGL-heap-size-exceeded 排查，把 Codex 的 Base URL 改到 TaoToken
1. ORA-00600 KGL-heap-size-exceeded 到底卡在哪ORA-00600 [KGL-heap-size-exceeded] 是 Oracle 數(shù)據(jù)庫里比較典型的一類內(nèi)部錯(cuò)誤字面意思是 KGLKernel Generic Library堆內(nèi)存超限。KGL 堆主要存放游標(biāo)、庫緩存對象、SQL 元數(shù)據(jù)這些東西它跟 shared pool 是綁在一起的。一旦 KGL 堆被撐爆數(shù)據(jù)庫會(huì)大量生成 core 文件業(yè)務(wù) TPS 直接掉到接近 0等故障時(shí)段過去又自己恢復(fù)然后高峰期再反復(fù)出現(xiàn)。這個(gè)場景適合誰看手上有一套 Oracle 12.2 環(huán)境、alert 日志里出現(xiàn)過 KGL-heap-size-exceeded、shared pool 等待嚴(yán)重、SQL version count 高到離譜的 DBA 或運(yùn)維同學(xué)。核心檢索詞就是 ORA-00600、KGL-heap-size-exceeded、cursor 不共享、BIND_EQUIV_FAILURE。我先把問題鏈路捋一遍。故障時(shí)間點(diǎn)看 AWRshared pool 相關(guān)等待非常重KGL 占用 9G 以上shared pool 統(tǒng)計(jì)占用到 90% 左右。報(bào)錯(cuò) SQL 的 version count 達(dá)到 900而_cursor_obsolete_threshold當(dāng)時(shí)是 1024也就是說游標(biāo)版本還沒到淘汰閾值但已經(jīng)堆了一大片。用V$SQL_BIND_CAPTURE和v$sql_shared_cursor查 cursor 為什么不共享發(fā)現(xiàn)BIND_EQUIV_FAILURE為 Y綁定變量等價(jià)性判斷失敗導(dǎo)致同一個(gè) SQL 反復(fù)生成子游標(biāo)KGL 堆被這些子游標(biāo)撐滿。常規(guī)動(dòng)作是加 shared pool從 20G 調(diào)到 40G故障確實(shí)不再出現(xiàn)但那條 SQL 的 version count 依舊很高。再把_cursor_obsolete_threshold從 1024 降到 50version count 才緩解。查 MOS 2610645.1發(fā)現(xiàn)BIND_EQUIV_FAILURE可能是 12.2 的 bug官方給了 Patch 28794230 和一組_optimizer_use_feedback、_optimizer_adaptive_cursor_sharing、_optimizer_extended_cursor_sharing_rel的 workaround。問題在于這些線索散落在 AWR、V$ 視圖、MOS 文檔和一堆隱藏參數(shù)里人工對照很費(fèi)時(shí)間。我想把 Codex 接到 TaoToken 的統(tǒng)一 API 通道上讓它幫我整理排查思路、對照 MOS 方案取舍但 Codex 本身不連 Oracle數(shù)據(jù)庫側(cè)的 SQL、AWR、alter system 還是我在本地 SQL*Plus 里執(zhí)行只把粘貼出來的結(jié)果交給 Codex 分析。2. 把 Codex 的 Base URL 改到 TaoToken這一步是前置準(zhǔn)備。TaoToken 只提供 Key 和 Base URL讓 Codex 走統(tǒng)一 API 通道不碰你的數(shù)據(jù)庫。先打開 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注冊賬號(hào)然后在控制臺(tái)創(chuàng)建 API Key。創(chuàng)建 Key 的入口在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 登錄后點(diǎn)新建復(fù)制那串 Key 存好。Base URL 填https://taotoken.net/api注意兩點(diǎn)不要加/v1也不要用官網(wǎng)首頁地址。很多人習(xí)慣性寫成https://taotoken.net/api/v1結(jié)果請求 404這個(gè)坑我見得太多了。Codex 的配置一般放在~/.codex/config.toml或者環(huán)境變量里下面給一份可復(fù)制的配置。# ~/.codex/config.toml model gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat如果你更習(xí)慣用環(huán)境變量也可以這樣export TAOTOKEN_API_KEYsk-你從TaoToken控制臺(tái)復(fù)制的Key export OPENAI_BASE_URLhttps://taotoken.net/api配置完保存別急著讓它分析 ORA-00600先發(fā)一條普通請求確認(rèn)通道是通的。這一步很關(guān)鍵通道沒通后面全是白費(fèi)。3. 可復(fù)制配置與驗(yàn)證請求3.1 先確認(rèn) Codex 能正常對話在終端里跑一條最簡單的請求確認(rèn) Key 和 Base URL 都生效codex exec 用一句話說明 Oracle shared pool 的作用如果返回正常文本說明 Codex 已經(jīng)通過 TaoToken 兼容通道跑起來了。如果報(bào) 401檢查 Key 有沒有復(fù)制全如果報(bào) 404八成是 Base URL 多寫了/v1。想直接在網(wǎng)頁里驗(yàn)證模型是否可用可以打開模型對話頁 https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 發(fā)一條測試消息能回就說明賬號(hào)和 Key 都沒問題。3.2 數(shù)據(jù)庫側(cè)采集Codex 側(cè)分析記住一個(gè)原則Codex 不連 Oracle。下面這些 SQL 你在本地 SQL*Plus 執(zhí)行把結(jié)果粘貼給 Codex。先看故障時(shí)間點(diǎn)的 shared pool 和 KGL 占用-- 查看 shared pool 各子池占用 SELECT pool, name, bytes/1024/1024 AS mb FROM v$sgastat WHERE pool shared pool AND name IN (free memory, miscellaneous) ORDER BY bytes DESC; -- 查看 KGL 相關(guān)堆占用 SELECT ksmchcls, SUM(ksmchsiz)/1024/1024 AS mb FROM x$ksmsp WHERE ksmchcls LIKE KGL% GROUP BY ksmchcls ORDER BY mb DESC;再看那條 version count 900 的 SQL確認(rèn) cursor 不共享的原因SELECT c.sql_id, c.SQL_TYPE_MISMATCH, c.BIND_EQUIV_FAILURE, b.POSITION, b.DATATYPE_STRING, b.LAST_CAPTURED FROM V$SQL_BIND_CAPTURE b, v$sql_shared_cursor c WHERE c.CHILD_ADDRESS b.CHILD_ADDRESS AND c.SQL_ID 9pvt6prqzddvy;把這兩段結(jié)果、AWR 里 shared pool 等待的片段、以及BIND_EQUIV_FAILUREY的行一起粘貼給 Codex讓它逐條對照原文排查步驟和 MOS 2610645.1 的方案取舍。你可以這樣給它下指令下面是我從 Oracle 12.2 環(huán)境采集的 V$SQL_BIND_CAPTURE、v$sql_shared_cursor 和 AWR 片段。 現(xiàn)象ORA-00600 [KGL-heap-size-exceeded]KGL 占用 9Gshared pool 20G 調(diào)到 40G 后故障消失但 version count 仍高 _cursor_obsolete_threshold 從 1024 降到 50 后緩解BIND_EQUIV_FAILUREY。 請幫我1) 按可能性排序 cursor 不共享的原因2) 對照 MOS 2610645.1 的 Patch 28794230 和 _optimizer_use_feedback 等 workaround 給出取舍建議 3) 列出還需要在本地 SQL*Plus 補(bǔ)采哪些視圖。不要假設(shè)你能連數(shù)據(jù)庫。3.3 參數(shù)調(diào)整的本地執(zhí)行下面這些 alter system 仍然在本地 SQL*Plus 執(zhí)行Codex 只幫你判斷該不該做、順序怎么排-- 調(diào)整 shared pool需根據(jù)實(shí)際 SGA 評(píng)估 ALTER SYSTEM SET shared_pool_size 40G SCOPE SPFILE; -- 降低游標(biāo)淘汰閾值緩解 version count ALTER SYSTEM SET _cursor_obsolete_threshold 50 SCOPE SPFILE; -- MOS 2610645.1 給出的 workaround先評(píng)估再執(zhí)行 ALTER SYSTEM SET _optimizer_use_feedback FALSE SCOPE SPFILE; ALTER SYSTEM SET _optimizer_adaptive_cursor_sharing FALSE SCOPE SPFILE; ALTER SYSTEM SET _optimizer_extended_cursor_sharing_rel NONE SCOPE SPFILE;隱藏參數(shù)改動(dòng)前一定要在測試庫驗(yàn)證生產(chǎn)庫改完要重啟才生效的記得安排窗口。Codex 能幫你把這幾條參數(shù)的影響面、回退方式列清楚但執(zhí)行權(quán)在你手里。4. 驗(yàn)證請求與成功結(jié)果通道驗(yàn)證分兩層。第一層是 Codex 本身可用前面那條codex exec返回正常文本就算過。第二層是讓它真的能處理 ORA-00600 的排查素材。我實(shí)測下來把v$sql_shared_cursor的完整輸出和 AWR 的 Top 10 等待事件粘進(jìn)去Codex 能給出這樣的結(jié)構(gòu)化輸出先按BIND_EQUIV_FAILURE、SQL_TYPE_MISMATCH、ROLL_INVALID_MISMATCH等字段逐項(xiàng)判斷再對照 MOS 2610645.1 說明 Patch 28794230 和 workaround 的適用條件最后列出還需要補(bǔ)采的視圖比如v$sql_shared_cursor里其他標(biāo)志位、v$librarycache的 reload 情況。成功的結(jié)果長這樣你拿到一份排查清單知道先看哪個(gè)字段、哪個(gè)參數(shù)改動(dòng)風(fēng)險(xiǎn)高、哪個(gè) workaround 可以先在測試庫試。數(shù)據(jù)庫側(cè)的 alter system 還是你自己敲Codex 不碰生產(chǎn)庫。如果你后面要長期做這類排查甚至想把 Codex 掛到日常運(yùn)維腳本里做輔助分析可以看看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 適合需要持續(xù)調(diào)用、批量整理排查記錄的場景。5. 本篇常見錯(cuò)排查5.1 Base URL 寫錯(cuò)導(dǎo)致 404最常見的錯(cuò)誤是把 Base URL 寫成https://taotoken.net/api/v1或者直接寫官網(wǎng)首頁。正確值是https://taotoken.net/api不加/v1。報(bào) 404 先查這里。5.2 Key 沒生效報(bào) 401檢查環(huán)境變量名和配置文件里的env_key是否一致。如果你在 config.toml 里寫env_key TAOTOKEN_API_KEY那環(huán)境變量就必須叫這個(gè)名字大小寫敏感。Key 復(fù)制時(shí)前后帶空格也會(huì)導(dǎo)致 401。5.3 讓 Codex 直接連 OracleCodex 不連 Oracle也不該給它數(shù)據(jù)庫連接串。所有 V$ 視圖、AWR、alter system 都在本地 SQL*Plus 執(zhí)行只把文本結(jié)果粘貼過去。試圖讓它直連生產(chǎn)庫既做不到也不安全。5.4 隱藏參數(shù)改完沒重啟_cursor_obsolete_threshold、_optimizer_use_feedback這些用SCOPE SPFILE改的必須重啟實(shí)例才生效。只改 spfile 不重啟查詢v$parameter看到的還是舊值會(huì)誤以為沒生效。5.5 把 shared pool 調(diào)大就當(dāng)解決了shared pool 從 20G 調(diào)到 40G 只是緩解了 KGL 堆被撐爆的速度version count 依舊高說明 cursor 不共享的根因還在。BIND_EQUIV_FAILUREY對應(yīng)的 12.2 bug 和 workaround 才是要對照處理的部分別停在加內(nèi)存這一步。5.6 忽略 core 文件占滿 /oracle 目錄故障時(shí)大量 cdmp core 文件會(huì)把 /oracle 目錄撐滿進(jìn)而引發(fā)更多問題。排查時(shí)先清理 core 文件釋放空間再去看 AWR 和 V$ 視圖否則連日志都寫不進(jìn)去。6. 把 Codex 配通到 TaoToken 之后從 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 拿到 Key把 Codex 的 Base URL 填成https://taotoken.net/api通道就通了。之后你可以在本地 SQL*Plus 采集V$SQL_BIND_CAPTURE、v$sql_shared_cursor、BIND_EQUIV_FAILURE和 KGL 堆超限的線索粘貼給 Codex讓它幫你整理 ORA-00600 與 cursor 共享問題的排查思路、對照 MOS 2610645.1 的方案取舍。接入文檔在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 配置細(xì)節(jié)和參數(shù)說明都在里面?？刂婆_(tái) https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 可以管理 Key 和用量。數(shù)據(jù)庫側(cè)的 alter system 和 Patch 決策始終由你在本地執(zhí)行Codex 只做分析輔助這條邊界別越過去。