1. plsql Developer 批量 KILL 阻塞會(huì)話的真實(shí)場(chǎng)景與痛點(diǎn)在 Oracle 日常運(yùn)維里最讓人血壓升高的不是數(shù)據(jù)庫(kù)宕機(jī)而是某個(gè)業(yè)務(wù)庫(kù)突然卡成 PPT登錄 plsql Developer 一看幾十上百個(gè)會(huì)話全堵在同一個(gè)對(duì)象上。你打開(kāi)會(huì)話列表v$session里status全是ACTIVElast_call_et動(dòng)輒幾千秒blocking_session一列指向同一個(gè)源頭。這時(shí)候如果一個(gè)個(gè)右鍵 Kill手速再快也要點(diǎn)十幾分鐘而且很容易漏掉剛冒出來(lái)的新阻塞。我試過(guò)最原始的做法在 plsql Developer 的 SQL Window 里手動(dòng)敲alter system kill session sid,serial#;一條一條復(fù)制粘貼。問(wèn)題是會(huì)話是動(dòng)態(tài)的你殺完一批被阻塞的那批立刻從WAITING變成ACTIVE又產(chǎn)生新的鎖等待。等你回頭再查SID 已經(jīng)變了之前拼好的語(yǔ)句全廢。更麻煩的是有些會(huì)話處于KILLED狀態(tài)但資源沒(méi)釋放v$session里還掛著PMON 回收又慢業(yè)務(wù)方電話一個(gè)接一個(gè)。所以真正需要的不是「怎么殺一個(gè)會(huì)話」而是「怎么批量、可重復(fù)、可驗(yàn)證地清理一批異常進(jìn)程」。這就涉及三個(gè)層次第一用一條 SQL 精準(zhǔn)圈出該殺的會(huì)話而不是誤傷IFSAPP、AUTOS這類(lèi)后臺(tái)賬號(hào)第二把查詢(xún)結(jié)果自動(dòng)拼成ALTER SYSTEM KILL SESSION語(yǔ)句并執(zhí)行第三執(zhí)行前后都要有校驗(yàn)確認(rèn)會(huì)話真的釋放、鎖真的解開(kāi)。這里有個(gè)容易被忽略的點(diǎn)很多 DBA 把清理腳本寫(xiě)死在 plsql Developer 的匿名塊里但腳本本身需要維護(hù)、需要版本管理、需要跨環(huán)境復(fù)用。如果能把「會(huì)話診斷 KILL 語(yǔ)句生成」這部分能力通過(guò)統(tǒng)一的 API 通道調(diào)起來(lái)配合一個(gè)穩(wěn)定的 Key 做鑒權(quán)就能把零散的 SQL 片段沉淀成可復(fù)用的運(yùn)維工具。TaoToken 在這里扮演的角色就是給這類(lèi)腳本調(diào)用提供一個(gè)統(tǒng)一的 Key 和 API 入口讓你不用在每個(gè)環(huán)境里重復(fù)配置鑒權(quán)信息腳本里只認(rèn)一個(gè) Base URL 和一個(gè) Key 就行。下面我會(huì)按「先查、再拼、后殺、終驗(yàn)」的順序把整套流程拆成可以直接復(fù)制的步驟。核心檢索詞就是 plsql 批量 KILL 進(jìn)程適合每天要和阻塞會(huì)話打交道的 Oracle DBA以及需要把清理動(dòng)作腳本化、自動(dòng)化的運(yùn)維同學(xué)。整套操作在 plsql Developer 的 Command Window 或 SQL Window 里都能跑不需要額外裝客戶(hù)端。2. TaoToken 統(tǒng)一 Key 前置準(zhǔn)備讓清理腳本有穩(wěn)定的調(diào)用通道在寫(xiě) KILL 腳本之前先把調(diào)用通道理清楚。很多 DBA 的清理腳本是「裸奔」的——直接嵌在 plsql Developer 里誰(shuí)都能改換個(gè)環(huán)境就要重新配連接串。如果你希望這套腳本能跨庫(kù)、跨環(huán)境復(fù)用甚至以后接進(jìn)自動(dòng)化巡檢就需要一個(gè)統(tǒng)一的鑒權(quán)入口。TaoToken 提供的就是這個(gè)入口一個(gè) Base URL 加一個(gè) Key腳本里只引用這兩個(gè)值不用把賬號(hào)密碼散落在各處。先明確三個(gè)必須寫(xiě)全的要素后面所有配置都圍繞它們展開(kāi)要素值說(shuō)明Base URLhttps://taotoken.net/apiAPI 通道地址不加 UTM 參數(shù)API Key在控制臺(tái)生成形如sk-開(kāi)頭的字符串只顯示一次Model ID按需選擇用于讓模型輔助生成/審查 KILL 語(yǔ)句獲取 Key 的路徑是打開(kāi)官網(wǎng)https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content進(jìn)入控制臺(tái)在 API Keys 頁(yè)面新建一個(gè) Key。這里要注意Key 只在創(chuàng)建時(shí)完整顯示一次關(guān)掉頁(yè)面就看不到了所以生成后立刻復(fù)制到安全的地方。如果你用的是 Claude Code 這類(lèi)編碼工具還需要在配置里同時(shí)填 Base URL、Key 和 Model ID 三件套缺一個(gè)都會(huì)報(bào)鑒權(quán)失敗。為什么清理腳本要接這個(gè)通道因?yàn)榕?KILL 的本質(zhì)是「根據(jù)診斷結(jié)果動(dòng)態(tài)生成 SQL」。診斷邏輯哪些會(huì)話該殺、阻塞鏈怎么走可以用自然語(yǔ)言描述給模型讓模型幫你審查拼接出來(lái)的 KILL 語(yǔ)句有沒(méi)有語(yǔ)法問(wèn)題、有沒(méi)有誤傷系統(tǒng)賬號(hào)。比如你把v$session的查詢(xún)結(jié)果貼給模型讓它判斷USERNAME NOT IN (IFSAPP,AUTOS,THK)這個(gè)過(guò)濾條件是否覆蓋了所有后臺(tái)賬號(hào)模型能給出補(bǔ)充建議。這一步不是必須但在會(huì)話量很大、過(guò)濾條件復(fù)雜的時(shí)候能幫你少踩坑。配置層面如果你在 plsql Developer 里通過(guò)外部腳本調(diào)用可以準(zhǔn)備一個(gè)settings.json或.env文件存放通道信息。以常見(jiàn)的編碼工具配置為例路徑和字段要寫(xiě)對(duì){ base_url: https://taotoken.net/api, api_key: sk-你的Key, model_id: claude-sonnet-4-5, timeout: 60 }注意base_url結(jié)尾不要多加斜杠api_key不要帶空格。如果你用的是 Codex 的auth.json字段名可能是OPENAI_BASE_URL和OPENAI_API_KEY但值同樣指向上面這個(gè) Base URL 和你的 Key。Cline 的 MCP 配置里則是baseUrl和apiKey大小寫(xiě)敏感寫(xiě)錯(cuò)一個(gè)字母就會(huì)連不上。這一步的目標(biāo)不是讓你立刻去調(diào)模型而是先把「通道」建好。后面第 3 節(jié)的 KILL 腳本里我會(huì)把「生成 KILL 語(yǔ)句」和「執(zhí)行 KILL 語(yǔ)句」分開(kāi)生成部分可以本地拼也可以走通道讓模型輔助校驗(yàn)。通道建好了腳本才有穩(wěn)定的依賴(lài)不會(huì)因?yàn)閾Q個(gè)環(huán)境就找不到鑒權(quán)信息。3. 可復(fù)制的會(huì)話查詢(xún) SQL 與 KILL 語(yǔ)句拼接模板這一節(jié)是整套流程的核心直接給可復(fù)制的代碼。先解決「查什么」再解決「怎么拼」。第一步圈出該殺的會(huì)話。原始 excerpt 里的游標(biāo)邏輯是從v$session和v$process關(guān)聯(lián)過(guò)濾TYPEUSER、status ! KILLED并且存在dba_ddl_locks里的鎖等待同時(shí)排除IFSAPP、AUTOS、THK三個(gè)賬號(hào)。這個(gè)思路是對(duì)的但有幾個(gè)地方可以加固一是last_call_et要設(shè)閾值避免殺掉剛提交的正常會(huì)話二是要顯示blocking_session方便定位源頭三是machine和program一起看避免誤殺同賬號(hào)的不同應(yīng)用。下面這條查詢(xún)可以直接在 plsql Developer 的 SQL Window 里跑先看結(jié)果再?zèng)Q定殺不殺SELECT s.sid, s.serial#, s.username, s.status, s.machine, s.program, s.last_call_et, s.blocking_session, s.event, alter system kill session || s.sid || , || s.serial# || immediate; AS kill_stmt FROM v$session s, v$process p WHERE s.type USER AND p.addr s.paddr AND s.status ! KILLED AND s.last_call_et 600 AND s.username NOT IN (IFSAPP, AUTOS, THK) AND EXISTS (SELECT 1 FROM dba_ddl_locks a WHERE a.session_id s.sid) ORDER BY s.last_call_et DESC;這里last_call_et 600表示只處理空閑超過(guò) 10 分鐘的會(huì)話你可以按業(yè)務(wù)調(diào)整。kill_stmt這一列已經(jīng)拼好了完整的 KILL 語(yǔ)句注意我加了immediate關(guān)鍵字它會(huì)強(qiáng)制回滾當(dāng)前事務(wù)并立即釋放會(huì)話比不帶immediate的默認(rèn)行為更干脆。但immediate有代價(jià)如果會(huì)話正在做大批量 DML回滾可能耗時(shí)較長(zhǎng)甚至產(chǎn)生大量 undo。所以生產(chǎn)環(huán)境建議先不帶immediate跑一批觀察釋放情況再?zèng)Q定是否加。第二步把查詢(xún)結(jié)果批量拼成可執(zhí)行腳本。如果你不想用游標(biāo)可以直接用SELECT ... INTO配合DBMS_OUTPUT輸出然后復(fù)制到 Command Window 執(zhí)行。但更穩(wěn)的做法是寫(xiě)一個(gè)匿名塊像 excerpt 那樣循環(huán)執(zhí)行同時(shí)把每條語(yǔ)句和異常都記下來(lái)DECLARE v_minutes NUMBER : 10; v_kill_sql VARCHAR2(200); v_count NUMBER : 0; CURSOR c_sessions IS SELECT s.sid, s.serial#, s.username, s.last_call_et FROM v$session s, v$process p WHERE s.type USER AND p.addr s.paddr AND s.status ! KILLED AND s.last_call_et v_minutes * 60 AND s.username NOT IN (IFSAPP, AUTOS, THK) AND EXISTS (SELECT 1 FROM dba_ddl_locks a WHERE a.session_id s.sid) ORDER BY s.last_call_et DESC; BEGIN FOR r IN c_sessions LOOP v_kill_sql : alter system kill session || r.sid || , || r.serial# || immediate; BEGIN EXECUTE IMMEDIATE v_kill_sql; v_count : v_count 1; DBMS_OUTPUT.PUT_LINE(KILLED: || r.sid || , || r.serial# || user || r.username); EXCEPTION WHEN OTHERS THEN DBMS_OUTPUT.PUT_LINE(FAILED: || r.sid || , || r.serial# || err || SQLERRM); END; END LOOP; DBMS_OUTPUT.PUT_LINE(TOTAL KILLED: || v_count); END; /跑之前記得在 plsql Developer 里開(kāi)啟DBMS_OUTPUT菜單Tools→DBMS Output點(diǎn)綠色加號(hào)綁定當(dāng)前連接。否則你只看到PL/SQL procedure successfully completed看不到具體殺了哪些。第三步如果你想把「生成 KILL 語(yǔ)句」這一步交給模型輔助審查可以把上面的查詢(xún)結(jié)果導(dǎo)出成 CSV通過(guò) TaoToken 的 API 通道發(fā)過(guò)去讓模型檢查有沒(méi)有語(yǔ)法錯(cuò)誤、有沒(méi)有漏掉系統(tǒng)賬號(hào)。調(diào)用時(shí)用https://taotoken.net/api作為 Base URL帶上你的 Key 和 Model ID。這一步的配置片段如下路徑按你的工具實(shí)際位置填# 示例編碼工具配置片段 [provider] base_url https://taotoken.net/api api_key sk-你的Key model claude-sonnet-4-5注意模型只做審查和建議真正的EXECUTE IMMEDIATE還是在數(shù)據(jù)庫(kù)里執(zhí)行。不要把生產(chǎn)庫(kù)的連接信息直接交給外部通道只傳會(huì)話列表這種脫敏數(shù)據(jù)。4. 執(zhí)行前后驗(yàn)證確認(rèn)會(huì)話釋放與鎖解開(kāi)殺完不等于結(jié)束必須驗(yàn)證。很多 DBA 執(zhí)行完 KILL 就關(guān)窗口結(jié)果業(yè)務(wù)方反饋還是卡回頭一查發(fā)現(xiàn)會(huì)話狀態(tài)變成KILLED但沒(méi)釋放或者鎖還在。所以執(zhí)行前后各做一次檢查形成閉環(huán)。執(zhí)行前先記錄基線。跑這條查詢(xún)把當(dāng)前阻塞會(huì)話數(shù)和鎖等待數(shù)記下來(lái)SELECT COUNT(*) AS blocked_sessions FROM v$session WHERE blocking_session IS NOT NULL AND type USER; SELECT COUNT(*) AS ddl_lock_count FROM dba_ddl_locks WHERE session_id IN (SELECT sid FROM v$session WHERE type USER);執(zhí)行后等 30 秒到 1 分鐘再跑同樣的查詢(xún)。理想情況下blocked_sessions應(yīng)該降到 0 或接近 0ddl_lock_count明顯下降。如果沒(méi)降說(shuō)明有會(huì)話處于KILLED但 PMON 還沒(méi)回收這時(shí)候可以查v$session里statusKILLED的會(huì)話SELECT sid, serial#, username, status, last_call_et, event FROM v$session WHERE status KILLED AND type USER;如果這些會(huì)話長(zhǎng)時(shí)間不消失說(shuō)明它們可能在回滾大事務(wù)。這時(shí)候不要重復(fù)殺重復(fù)ALTER SYSTEM KILL SESSION對(duì)已經(jīng)KILLED的會(huì)話無(wú)效。可以查v$transaction看回滾進(jìn)度SELECT s.sid, s.serial#, t.used_ublk, t.used_urec FROM v$session s, v$transaction t WHERE s.taddr t.addr AND s.status KILLED;used_ublk是占用的 undo 塊數(shù)如果它在持續(xù)下降說(shuō)明回滾在進(jìn)行耐心等。如果幾個(gè)小時(shí)都不動(dòng)才考慮在操作系統(tǒng)層面處理但那屬于另一套流程不在本文范圍。驗(yàn)證鎖是否解開(kāi)還可以查v$locked_objectSELECT lo.session_id, o.object_name, o.object_type, lo.locked_mode FROM v$locked_object lo, dba_objects o WHERE lo.object_id o.object_id AND lo.session_id IN (SELECT sid FROM v$session WHERE type USER);執(zhí)行前如果這個(gè)查詢(xún)返回一堆行執(zhí)行后應(yīng)該大幅減少。如果某個(gè)對(duì)象還被鎖著看session_id對(duì)應(yīng)哪個(gè)會(huì)話再?zèng)Q定是否補(bǔ)殺。這里有個(gè)實(shí)測(cè)經(jīng)驗(yàn)immediate雖然快但在高并發(fā)寫(xiě)入場(chǎng)景下強(qiáng)制回滾可能讓 IO 飆升。如果你的庫(kù)對(duì) IO 敏感建議先用不帶immediate的語(yǔ)句殺一批觀察v$session的status變化確認(rèn)釋放節(jié)奏后再?zèng)Q定是否加immediate。另外殺會(huì)話前最好和業(yè)務(wù)方確認(rèn)時(shí)間窗口避免在批量跑批時(shí)誤殺。5. 常見(jiàn)報(bào)錯(cuò)排查401、local proxy failed、reading choices、OAuth這一節(jié)對(duì)照真實(shí)報(bào)錯(cuò)把接入和腳本執(zhí)行中容易踩的坑列出來(lái)。每個(gè)報(bào)錯(cuò)都給出原因和修法。401 Unauthorized。這個(gè)最常見(jiàn)出現(xiàn)在你通過(guò) API 通道調(diào)用時(shí)。原因通常是 Key 寫(xiě)錯(cuò)、Key 過(guò)期、或者 Base URL 和 Key 不匹配。檢查三件套Base URL 是不是https://taotoken.net/apiKey 是不是sk-開(kāi)頭且沒(méi)有多余空格Model ID 是不是當(dāng)前 Key 有權(quán)限的模型。如果你在settings.json里配置注意 JSON 不能有注釋末尾不能有多余逗號(hào)。修法重新生成 Key復(fù)制時(shí)確認(rèn)沒(méi)有換行符然后重啟調(diào)用腳本。local proxy failed。這個(gè)報(bào)錯(cuò)說(shuō)明你的調(diào)用鏈路里配置了本地代理但代理沒(méi)起來(lái)或者端口不對(duì)。檢查你的環(huán)境變量HTTP_PROXY、HTTPS_PROXY是否指向了一個(gè)不存在的端口。如果你在 plsql Developer 里通過(guò)外部腳本調(diào)用腳本繼承的是系統(tǒng)環(huán)境變量可能你之前設(shè)過(guò)代理忘了清。修法臨時(shí)清空代理變量再跑或者把 Base URL 直連。注意這里說(shuō)的是本地網(wǎng)絡(luò)配置問(wèn)題不涉及任何跨境網(wǎng)絡(luò)操作純粹是端口和進(jìn)程排查。reading choices 相關(guān)報(bào)錯(cuò)。這個(gè)通常出現(xiàn)在模型返回結(jié)果解析階段報(bào)錯(cuò)信息里帶reading choices或cannot read property of undefined。原因是返回體結(jié)構(gòu)和你的解析代碼不匹配比如你按 OpenAI 格式取choices[0].message.content但實(shí)際返回的是流式分塊。修法先打印完整返回體確認(rèn)字段路徑再改解析邏輯。如果你用的是編碼工具檢查它的版本是否支持當(dāng)前 API 返回格式必要時(shí)升級(jí)工具。OAuth 相關(guān)報(bào)錯(cuò)。如果你在 Claude Code 或類(lèi)似工具里看到 OAuth 失敗說(shuō)明工具嘗試走 OAuth 流程而不是 API Key。修法在配置里顯式指定用 API Key 鑒權(quán)填全 Base URL、Key、Model ID 三件套。以 Claude Code 為例配置里要有ANTHROPIC_BASE_URL指向https://taotoken.net/apiANTHROPIC_API_KEY填你的 Key模型名按工具要求填。三個(gè)字段缺一個(gè)都會(huì)回退到 OAuth 或報(bào)鑒權(quán)失敗。KILL 語(yǔ)句執(zhí)行報(bào) ORA-00031。這個(gè)不是通道問(wèn)題是數(shù)據(jù)庫(kù)層面的session marked for kill。意思是會(huì)話已經(jīng)被標(biāo)記為 kill但還沒(méi)釋放。修法不要重復(fù)執(zhí)行 KILL查v$session確認(rèn)statusKILLED等 PMON 回收。如果長(zhǎng)時(shí)間不回收查v$transaction看回滾進(jìn)度。ORA-00030user session ID does not exist。說(shuō)明你拼的 SID 或 SERIAL# 已經(jīng)失效會(huì)話在你查詢(xún)之后、執(zhí)行之前自己斷開(kāi)了。修法在匿名塊里加異常捕獲像第 3 節(jié)那樣WHEN OTHERS THEN記錄失敗即可不影響其他會(huì)話。ORA-00026missing or invalid session ID。拼字符串時(shí)引號(hào)或逗號(hào)錯(cuò)了。檢查alter system kill session || sid || , || serial# || 的引號(hào)層數(shù)建議直接用第 3 節(jié)查詢(xún)里生成的kill_stmt列不要手拼。把這些報(bào)錯(cuò)對(duì)照表整理一下方便你排查報(bào)錯(cuò)出現(xiàn)位置根因修法401API 調(diào)用Key/URL/Model 不匹配重生成 Key核對(duì)三件套local proxy failed調(diào)用鏈路本地代理端口失效清空代理變量直連reading choices結(jié)果解析返回體結(jié)構(gòu)不符打印返回體改字段路徑OAuth工具鑒權(quán)未顯式配 Key填全 Base URLKeyModelORA-00031數(shù)據(jù)庫(kù)會(huì)話已標(biāo)記未釋放等待 PMON勿重復(fù)殺ORA-00030數(shù)據(jù)庫(kù)SID 已失效異常捕獲跳過(guò)ORA-00026數(shù)據(jù)庫(kù)拼接語(yǔ)法錯(cuò)用查詢(xún)生成的 kill_stmt6. 把清理腳本沉淀成可復(fù)用工具接入文檔與長(zhǎng)期編碼方案走到這一步你已經(jīng)能在 plsql Developer 里完成一次完整的批量 KILL查會(huì)話、拼語(yǔ)句、執(zhí)行、驗(yàn)證、排錯(cuò)。但如果每周都要做一次每次都手敲匿名塊就太累了。更好的做法是把這套邏輯沉淀成可復(fù)用的腳本或工具讓下次清理變成「改一個(gè)閾值、跑一次」的事。沉淀的第一步是參數(shù)化。把v_minutes、排除賬號(hào)列表、是否加immediate抽成變量放在腳本頭部。這樣不同庫(kù)、不同場(chǎng)景只需要改這幾個(gè)值。第二步是日志化把每次 KILL 的 SID、SERIAL#、用戶(hù)名、執(zhí)行結(jié)果寫(xiě)進(jìn)一張日志表方便事后審計(jì)。建表語(yǔ)句可以這樣CREATE TABLE dba_kill_log ( kill_time DATE DEFAULT SYSDATE, sid NUMBER, serial_num NUMBER, username VARCHAR2(30), kill_sql VARCHAR2(200), result VARCHAR2(200) );然后在匿名塊的異常處理里插入日志成功和失敗都記。這樣下次業(yè)務(wù)方問(wèn)「昨天殺了哪些會(huì)話」你直接查表就行。第三步是通道復(fù)用。如果你希望這套腳本能跨環(huán)境調(diào)用或者以后接進(jìn)自動(dòng)化巡檢平臺(tái)就把 TaoToken 的 Base URL 和 Key 作為統(tǒng)一鑒權(quán)入口。腳本里不寫(xiě)死數(shù)據(jù)庫(kù)密碼只引用通道配置。需要模型輔助審查 KILL 語(yǔ)句時(shí)走h(yuǎn)ttps://taotoken.net/api發(fā)請(qǐng)求需要長(zhǎng)期跑編碼任務(wù)、把清理邏輯做成 Agent 時(shí)可以了解 Coding Plan 的用法。接入細(xì)節(jié)和字段說(shuō)明在接入文檔里有完整示例建議對(duì)照著把settings.json或auth.json的字段名核對(duì)一遍避免大小寫(xiě)寫(xiě)錯(cuò)導(dǎo)致鑒權(quán)失敗。如果你只是想先驗(yàn)證模型能不能幫你審查 KILL 語(yǔ)句可以直接在模型對(duì)話里貼一段會(huì)話列表讓它判斷過(guò)濾條件是否合理。這一步不需要寫(xiě)代碼適合快速試水。等你確認(rèn)模型輸出靠譜再把它接進(jìn)腳本。最后給一個(gè)實(shí)用技巧把第 3 節(jié)的查詢(xún)和匿名塊保存成 plsql Developer 的Snippets或.sql文件命名成kill_blocked_sessions.sql放在版本控制里。每次用之前先跑查詢(xún)看結(jié)果確認(rèn)無(wú)誤再跑匿名塊。執(zhí)行后一定跑第 4 節(jié)的驗(yàn)證查詢(xún)確認(rèn)blocked_sessions歸零。整套流程跑順之后一次清理從原來(lái)的十幾分鐘縮短到兩三分鐘而且有日志可查、有驗(yàn)證兜底比手點(diǎn)右鍵穩(wěn)得多。