警惕Oracle DB操作高压线
生活随笔
收集整理的這篇文章主要介紹了
警惕Oracle DB操作高压线
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
在日常的數據庫技術支持工作中，會發現相當部分的數據庫事故和人為操作不當有直接的關系。每次的新員工培訓，也會用真實案例來說明和強調正確操作習慣的重要性。在強調職業化，推行可服務性的大環境下，了解數據庫操作的高壓線，掌握維護規則繞開雷區，就顯得格外刻不容緩。為此我特別總結過去一兩年中的突出數據庫案例，羅列出常見的違規操作，希望借此能夠盡可能的減少人為事故，從而提高用戶對職業化服務的滿意度。哲人說，不要被同一塊石頭絆倒兩次，那么希望通過這篇文章能夠避免同樣人為事故的再次發生。
? ? 高壓線一：不要隨意刪除/opt/oracle目錄下的任何文件。
? ? 咋看這個標題，看官們第一反應可能是我怎么會去刪除數據庫文件呢？實際上最近三個月，產品線已經發生過幾次數據庫日志文件部分或者全部被刪，導致數據庫宕機的嚴重事故。究其表面原因，是小局點數據庫文件建立在本地磁盤，日志文件的后綴又是.log，因此被維護工程師當成無用的垃圾日志刪除。深究其實質原因，是維護工程師對數據庫缺乏基本常識，不了解什么是數據庫文件，從而碰了數據庫操作的高壓線。
? ? 典型案例: 某地系統數據庫意外刪除所有log file文件
? ? 辦事處工程師到現場解決性能問題，發現Rootvg快滿了，決定清除日志文件。工程師使用find name *log，盡管800工程師在支持電話中警告不能刪除數據庫文件，現場工程師還是刪除了數據庫的所有在線重做日志文件（文件后綴為.log）。
? ? 數據庫在刪除文件數分鐘后宕機，重新啟動數據庫報錯：
QUOTE:
ORA-313 signalled during: alter database open...
Sat Apr 2 02:20:49 2005
Errors in file /usr/oracle/admin/ora7/udump/ora_27520.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00449: background process "LGWR" unexpectedly terminated with error 313
ORA-00313: open failed for members of log group of thread
ORA-01092: ORACLE instance terminated. Disconnection forced
問題處理過程：
? ? 刪除了數據庫的所有在線重做日志文件是很嚴重的事故，而且現場沒有任何數據庫備份，如果不能恢復后果不堪設想。在經歷10個小時的緊急恢復后，數據庫終于正常運行。
? ? 總結：
? ? 本案例中的數據庫歷經緊急恢復得以正常運行，而另一個地方就沒有這么幸運，最終是重建庫然后導入歷史數據。最近已有數起刪除日志文件導致的人為事故，尤以舉例的事故最為嚴重，刪除了所有的日志文件，希望工程師尤其是新員工引以為戒。
? ? 刪除數據庫文件是非常嚴重的人為事故，數據庫文件的缺失將直接導致數據庫宕機和數據的丟失。那么如何避免刪除數據庫文件呢？我們需要了解數據庫的組織結構，以Oracle來舉例，每一個ORACLE數據庫是由三種類型的文件組成：數據文件、日志文件、控制文件，缺一不可。另外參數文件、密碼文件、歸檔日志文件也是重要的數據庫文件。如果不使用裸設備，這些文件通常存放在oracle用戶軟件目錄/opt/oracle中。如果不清楚文件的作用和來源，就不要隨意動/opt/oracle目錄下的任何文件。
? ? 高壓線二：不能移除表空間的任何數據文件
? ? 一個常見的錯誤頻繁出現在新員工中直接刪除表空間的物理數據文件，這個錯誤多半發生在測試環境或者是新開局。通常的情況是，工程師發現表空間的數據文件建錯路徑或者無用文件，就手工刪除數據文件，導致數據庫宕機或者無法啟動。
? ? 典型案例：用rm命令物理刪除表空間的數據文件
? ? 某地工程師為表空間增加數據文件，后發現文件路徑給錯，直接用rm命令物理刪除了此文件。10分鐘后數據庫dbw0后臺進程寫文件失敗，數據庫宕機。嘗試重新啟動數據庫失敗，錯誤為：
QUOTE:
ORA-01110: data file 446: "/ICTdata10/oradata/ICT/data/ict_restored_data081.dbf"
ORA-01115: IO error reading block from file 446 (block # 1)
ORA-27063: skgfospo: number of bytes read/written is incorrect
SVR4 Error: 6: No such device or address
問題處理過程：
? ? 1. 使用下述命令脫機刪除已經丟失的數據文件：
QUOTE:
ALTER DATABASE DATAFILE /ICTdata10/oradata/ICT/data/ict_restored_data080.dbf OFFLINE DROP;
2.啟動數據庫：alter database open;
? ? 3.刪除或者重建表空間
? ? 總結：
? ? Oracle的原則是一旦一個數據文件被加入到表空間中，那么除非這個表空間被刪除，否則不能夠將任何數據文件從表空間移除。ALTER DATABASE DATAFILE OFFLINE DROP命令并不是允許移除數據文件，它只是說明有立刻刪除這個數據文件所在表空間的意圖。因此啟動數據庫后，必須馬上刪除或者重建表空間，否則會繼續在alert_SID.log中發現上述報錯。
? ? 高壓線三：數據庫軟件所在目錄不能滿
? ? /opt/oracle通常是數據庫軟件所在目錄，也有局點用/home/oracle。這個目錄塞滿的后果如同root用戶根目錄塞滿，維護工程師需要時刻留意/opt/oracle有可用空間。開局指導書一般要求安裝前/opt/oracle有6G，甚至12G的空間，就是為這個目錄留有足夠多的空間，避免影響Oracle程序的正常運行，引發災難性后果。
? ? 典型案例：一節點/opt/oracle滿導致RAC另一節點宕機某地發生RAC的一個節點oracle1宕機事故，alert_SID.log報錯如下：
QUOTE:
? ? Thu Nov 11 12:54:57 2004
? ? Errors in file /home/oracle/app/oracle/admin/ora8/bdump/pmon_21062_ora8.trc:
? ? ORA-00482: LMD* process terminated with error
? ? Thu Nov 11 12:54:57 2004
? ? PMON: terminating instance due to error 482
? ? Instance terminated by PMON, pid = 21062
問題處理過程：
? ? LMD* process 是服務于RAC環境的后臺進程，ORA-00482的錯誤表明DLM （Distributed Lock Manager）重新配置沒有在規定的等待時間內完成，導致instance crash。該節點宕機由對方節點引起的，任何異常比如網絡斷開等都有可能，這種異常通稱是由Hardware-/OS-issue引起的。
? ? 據現場反饋，事故發生前有剛進行過IBM巡檢，IBM工程師發現用戶將數據庫備份到ORACLE_HOME造成目錄滿的問題，但沒有整改。因此這次事故中oracle2的ORACLE_HOME滿和oracle1宕機有直接關聯，甚至是直接原因。因此，我們給出exp壓縮和磁帶的備份方法，并告知注意備份不要保存在ORACLE_HOME目錄，以免影響ORACLE的正常運行。
? ? 盡管問題已經定位，但事情并沒有就此結束。由于沒有及時整改，10天之后工程師反饋由于備份保存在ORACLE_HOME目錄造成目錄滿，RAC中的一臺再次意外宕機。
? ? 總結：
? ? 小型機上根目錄滿會造成各種各樣的異常，比如：TELNET失敗，執行命令HANG住或者失敗，甚至宕機的嚴重后果。對于數據庫也是如此，如果數據庫軟件所在目錄滿，也將擾亂Oracle程序的正常運行，造成嚴重后果?，F場工程師需要經常使用df –k觀察各目錄的空間使用情況。
? ? 此外，在備份指導書中，明確要求備份不要保存在數據庫軟件所在目錄，而是單獨為備份文件劃分專用的備份目錄。在執行exp備份命令時file參數使用全路徑，也能夠避免上述問題。
? ? 高壓線四：正確使用圖形工具和第三方工具
? ? Oracle的圖形化工具：企業管理器，DBA Studio等，第三方工具：PL/SQL Developer, TOAD等，因其圖形化界面，功能強大，使用方便而廣泛流行。但是，這些工具就像“雙刃劍”，一方面不用記憶繁瑣的命令和數據庫對象，加快維護效率，另一方面由于操作簡單，如果使用不當則破壞力強大，造成人為事故。
? ? 典型案例：某地因設置數據庫停頓模式造成應用中斷
? ? 某地數據庫突然在業務高峰無法使用，總是得到ora-00020 maximum number of processes (%s) exceeded "。此時連接到oracle的用戶已經達到了150（達到參數上限），而數據庫平常的連接一般不超過100。現場嘗試停止部分應用，減少連接數等措施，均無效。
? ? 問題處理過程：
? ? 檢查alert_web.log文件，發現當天有人執行：
QUOTE:
? ?ALTER SYSTEM SET resource_manager_plan=SYSTEM_PLAN SCOPE=MEMORY;
? ? ALTER SYSTEM SET resource_manager_plan=INTERNAL_QUIESCE SCOPE=MEMORY SID=*;
懷疑是有人使用oracle的資源管理器（resource manager)將數據庫置為停頓模式（QUIESCED),導致數據庫無法訪問。
? ? 遠程緊急嘗試各種方法連接數據庫，執行ALTER SYSTEM SET resource_manager_plan="" SCOPE=MEMORY;
? ? 取消系統當前的資源管理計劃。數據庫在幾分鐘內恢復正常，業務恢復。經過仔細檢查，發現SYS用戶下還有兩個定時job，是這兩個job發出了利用資源計劃將數據庫設為停頓的命令。為消除隱患，現場將這兩個定時任務刪除。
? ? 總結：
? ? 停頓是一個9i的新特征，使得DBA可以完成一些數據庫處于受限模式才能完成的一些操作。當使用oracle的資源管理器向數據庫發出停頓命令后，因為當前數據庫還有大量活動事務，故數據庫一直處于要想停頓，但還要等待活動的運行事務完成，此時數據庫可能會啟動很多垃圾連接來阻止新用戶登陸，造成業務中斷數個小時。這是一個典型的使用圖形工具發出錯誤指令，造成嚴重后果的案例。
? ? 典型案例：某地因SELECT FOR UPDATE造成同步中斷
? ? 某地割接后第二天中午12點突然發現一個子節點的同步異常，刷新組的job中斷近一個小時。發現日志中報錯：
QUOTE:
? ? ORA-12012: error on auto execute of job 23
? ? ORA-12008: error in materialized view refresh path
? ? ORA-02049: timeout: distributed transaction waiting for lock
? ? ORA-06512: at "SYS.DBMS_SNAPSHOT", line 803
? ? ORA-06512: at "SYS.DBMS_SNAPSHOT", line 860
? ? ORA-06512: at "SYS.DBMS_IREFRESH", line 683
? ? ORA-06512: at "SYS.DBMS_REFRESH", line 195
? ? ORA-06512: at line 1
維護人員嘗試重新運行job但不成功，再次得到ORA-02049錯誤。因此重啟數據庫，又殺掉數據庫中的一個一直存在的本地連接。此后job運行成功，同步恢復。
? ? 問題原因分析：
? ? 維護人員反饋曾將在主節點PL/SQL Developer下執行的更新語句直接拷貝到同步節點執行，語句如下：
QUOTE:
Select * from t_userinfo where phonenumber=’***’ for update;
發生問題的數據庫是一個僅存放只讀快照的數據庫，也就是說這個庫是不應該有任何DML操作的。ORA-02049表明同步寫數據失敗，問題原因是此語句對同步節點的只讀快照加鎖，直接修改/加鎖了同步節點的物化視圖，造成同步寫失敗，導致應用失常用戶投訴。
? ? 總結：
? ? 如果使用PL/SQL Developer直接修改記錄，那么會自動生成SELECT FOR UPDATE的語句。一個普通的SELECT操作不會對正處理的行執行任何鎖定設置，但加上FOR UPDATE會在相關數據行上加互斥鎖，直到整個事務被提交才釋放。工程師拷貝執行了錯誤的語句，而且沒有關閉命令窗口，事務一直沒有提交或者回滾，造成此次事故。
? ? 最近已經發生數起使用PL/SQL Developer更新用戶表或者系統表，沒有關閉命令窗口，事務一直沒有提交或者回滾，造成鎖等待影響數據庫正常運行的事故。
? ? 結語
? ? 紅燈停，綠燈行。只有遵守交通規則，才能避免安全事故。硬盤壞、數據庫BUG造成數據庫事故的是小概率事件。更多數據庫事故是人為原因，該調的參數沒有調，該日常巡檢觀察的沒有檢查，該注意的事項沒有規避等等。近一兩年發布的各種安裝、維護、巡檢、備份等系列指導書，專門歸納常見熱點問題的數據庫FAQ，以及收錄產品線原創好文的主機空間，涵蓋了數據庫日常維護的方方面面，包括知識點、操作命令，維護經驗和注意事項等等內容，希望工程師能夠好好的使用這些資料，提高維護技能。只要我們掌握維護規則，避開數據庫操作的高壓線，就能夠有效的減少外購件的人為事故。
? ? 高壓線一：不要隨意刪除/opt/oracle目錄下的任何文件。
? ? 咋看這個標題，看官們第一反應可能是我怎么會去刪除數據庫文件呢？實際上最近三個月，產品線已經發生過幾次數據庫日志文件部分或者全部被刪，導致數據庫宕機的嚴重事故。究其表面原因，是小局點數據庫文件建立在本地磁盤，日志文件的后綴又是.log，因此被維護工程師當成無用的垃圾日志刪除。深究其實質原因，是維護工程師對數據庫缺乏基本常識，不了解什么是數據庫文件，從而碰了數據庫操作的高壓線。
? ? 典型案例: 某地系統數據庫意外刪除所有log file文件
? ? 辦事處工程師到現場解決性能問題，發現Rootvg快滿了，決定清除日志文件。工程師使用find name *log，盡管800工程師在支持電話中警告不能刪除數據庫文件，現場工程師還是刪除了數據庫的所有在線重做日志文件（文件后綴為.log）。
? ? 數據庫在刪除文件數分鐘后宕機，重新啟動數據庫報錯：
QUOTE:
ORA-313 signalled during: alter database open...
Sat Apr 2 02:20:49 2005
Errors in file /usr/oracle/admin/ora7/udump/ora_27520.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00449: background process "LGWR" unexpectedly terminated with error 313
ORA-00313: open failed for members of log group of thread
ORA-01092: ORACLE instance terminated. Disconnection forced
問題處理過程：
? ? 刪除了數據庫的所有在線重做日志文件是很嚴重的事故，而且現場沒有任何數據庫備份，如果不能恢復后果不堪設想。在經歷10個小時的緊急恢復后，數據庫終于正常運行。
? ? 總結：
? ? 本案例中的數據庫歷經緊急恢復得以正常運行，而另一個地方就沒有這么幸運，最終是重建庫然后導入歷史數據。最近已有數起刪除日志文件導致的人為事故，尤以舉例的事故最為嚴重，刪除了所有的日志文件，希望工程師尤其是新員工引以為戒。
? ? 刪除數據庫文件是非常嚴重的人為事故，數據庫文件的缺失將直接導致數據庫宕機和數據的丟失。那么如何避免刪除數據庫文件呢？我們需要了解數據庫的組織結構，以Oracle來舉例，每一個ORACLE數據庫是由三種類型的文件組成：數據文件、日志文件、控制文件，缺一不可。另外參數文件、密碼文件、歸檔日志文件也是重要的數據庫文件。如果不使用裸設備，這些文件通常存放在oracle用戶軟件目錄/opt/oracle中。如果不清楚文件的作用和來源，就不要隨意動/opt/oracle目錄下的任何文件。
? ? 高壓線二：不能移除表空間的任何數據文件
? ? 一個常見的錯誤頻繁出現在新員工中直接刪除表空間的物理數據文件，這個錯誤多半發生在測試環境或者是新開局。通常的情況是，工程師發現表空間的數據文件建錯路徑或者無用文件，就手工刪除數據文件，導致數據庫宕機或者無法啟動。
? ? 典型案例：用rm命令物理刪除表空間的數據文件
? ? 某地工程師為表空間增加數據文件，后發現文件路徑給錯，直接用rm命令物理刪除了此文件。10分鐘后數據庫dbw0后臺進程寫文件失敗，數據庫宕機。嘗試重新啟動數據庫失敗，錯誤為：
QUOTE:
ORA-01110: data file 446: "/ICTdata10/oradata/ICT/data/ict_restored_data081.dbf"
ORA-01115: IO error reading block from file 446 (block # 1)
ORA-27063: skgfospo: number of bytes read/written is incorrect
SVR4 Error: 6: No such device or address
問題處理過程：
? ? 1. 使用下述命令脫機刪除已經丟失的數據文件：
QUOTE:
ALTER DATABASE DATAFILE /ICTdata10/oradata/ICT/data/ict_restored_data080.dbf OFFLINE DROP;
2.啟動數據庫：alter database open;
? ? 3.刪除或者重建表空間
? ? 總結：
? ? Oracle的原則是一旦一個數據文件被加入到表空間中，那么除非這個表空間被刪除，否則不能夠將任何數據文件從表空間移除。ALTER DATABASE DATAFILE OFFLINE DROP命令并不是允許移除數據文件，它只是說明有立刻刪除這個數據文件所在表空間的意圖。因此啟動數據庫后，必須馬上刪除或者重建表空間，否則會繼續在alert_SID.log中發現上述報錯。
? ? 高壓線三：數據庫軟件所在目錄不能滿
? ? /opt/oracle通常是數據庫軟件所在目錄，也有局點用/home/oracle。這個目錄塞滿的后果如同root用戶根目錄塞滿，維護工程師需要時刻留意/opt/oracle有可用空間。開局指導書一般要求安裝前/opt/oracle有6G，甚至12G的空間，就是為這個目錄留有足夠多的空間，避免影響Oracle程序的正常運行，引發災難性后果。
? ? 典型案例：一節點/opt/oracle滿導致RAC另一節點宕機某地發生RAC的一個節點oracle1宕機事故，alert_SID.log報錯如下：
QUOTE:
? ? Thu Nov 11 12:54:57 2004
? ? Errors in file /home/oracle/app/oracle/admin/ora8/bdump/pmon_21062_ora8.trc:
? ? ORA-00482: LMD* process terminated with error
? ? Thu Nov 11 12:54:57 2004
? ? PMON: terminating instance due to error 482
? ? Instance terminated by PMON, pid = 21062
問題處理過程：
? ? LMD* process 是服務于RAC環境的后臺進程，ORA-00482的錯誤表明DLM （Distributed Lock Manager）重新配置沒有在規定的等待時間內完成，導致instance crash。該節點宕機由對方節點引起的，任何異常比如網絡斷開等都有可能，這種異常通稱是由Hardware-/OS-issue引起的。
? ? 據現場反饋，事故發生前有剛進行過IBM巡檢，IBM工程師發現用戶將數據庫備份到ORACLE_HOME造成目錄滿的問題，但沒有整改。因此這次事故中oracle2的ORACLE_HOME滿和oracle1宕機有直接關聯，甚至是直接原因。因此，我們給出exp壓縮和磁帶的備份方法，并告知注意備份不要保存在ORACLE_HOME目錄，以免影響ORACLE的正常運行。
? ? 盡管問題已經定位，但事情并沒有就此結束。由于沒有及時整改，10天之后工程師反饋由于備份保存在ORACLE_HOME目錄造成目錄滿，RAC中的一臺再次意外宕機。
? ? 總結：
? ? 小型機上根目錄滿會造成各種各樣的異常，比如：TELNET失敗，執行命令HANG住或者失敗，甚至宕機的嚴重后果。對于數據庫也是如此，如果數據庫軟件所在目錄滿，也將擾亂Oracle程序的正常運行，造成嚴重后果?，F場工程師需要經常使用df –k觀察各目錄的空間使用情況。
? ? 此外，在備份指導書中，明確要求備份不要保存在數據庫軟件所在目錄，而是單獨為備份文件劃分專用的備份目錄。在執行exp備份命令時file參數使用全路徑，也能夠避免上述問題。
? ? 高壓線四：正確使用圖形工具和第三方工具
? ? Oracle的圖形化工具：企業管理器，DBA Studio等，第三方工具：PL/SQL Developer, TOAD等，因其圖形化界面，功能強大，使用方便而廣泛流行。但是，這些工具就像“雙刃劍”，一方面不用記憶繁瑣的命令和數據庫對象，加快維護效率，另一方面由于操作簡單，如果使用不當則破壞力強大，造成人為事故。
? ? 典型案例：某地因設置數據庫停頓模式造成應用中斷
? ? 某地數據庫突然在業務高峰無法使用，總是得到ora-00020 maximum number of processes (%s) exceeded "。此時連接到oracle的用戶已經達到了150（達到參數上限），而數據庫平常的連接一般不超過100。現場嘗試停止部分應用，減少連接數等措施，均無效。
? ? 問題處理過程：
? ? 檢查alert_web.log文件，發現當天有人執行：
QUOTE:
? ?ALTER SYSTEM SET resource_manager_plan=SYSTEM_PLAN SCOPE=MEMORY;
? ? ALTER SYSTEM SET resource_manager_plan=INTERNAL_QUIESCE SCOPE=MEMORY SID=*;
懷疑是有人使用oracle的資源管理器（resource manager)將數據庫置為停頓模式（QUIESCED),導致數據庫無法訪問。
? ? 遠程緊急嘗試各種方法連接數據庫，執行ALTER SYSTEM SET resource_manager_plan="" SCOPE=MEMORY;
? ? 取消系統當前的資源管理計劃。數據庫在幾分鐘內恢復正常，業務恢復。經過仔細檢查，發現SYS用戶下還有兩個定時job，是這兩個job發出了利用資源計劃將數據庫設為停頓的命令。為消除隱患，現場將這兩個定時任務刪除。
? ? 總結：
? ? 停頓是一個9i的新特征，使得DBA可以完成一些數據庫處于受限模式才能完成的一些操作。當使用oracle的資源管理器向數據庫發出停頓命令后，因為當前數據庫還有大量活動事務，故數據庫一直處于要想停頓，但還要等待活動的運行事務完成，此時數據庫可能會啟動很多垃圾連接來阻止新用戶登陸，造成業務中斷數個小時。這是一個典型的使用圖形工具發出錯誤指令，造成嚴重后果的案例。
? ? 典型案例：某地因SELECT FOR UPDATE造成同步中斷
? ? 某地割接后第二天中午12點突然發現一個子節點的同步異常，刷新組的job中斷近一個小時。發現日志中報錯：
QUOTE:
? ? ORA-12012: error on auto execute of job 23
? ? ORA-12008: error in materialized view refresh path
? ? ORA-02049: timeout: distributed transaction waiting for lock
? ? ORA-06512: at "SYS.DBMS_SNAPSHOT", line 803
? ? ORA-06512: at "SYS.DBMS_SNAPSHOT", line 860
? ? ORA-06512: at "SYS.DBMS_IREFRESH", line 683
? ? ORA-06512: at "SYS.DBMS_REFRESH", line 195
? ? ORA-06512: at line 1
維護人員嘗試重新運行job但不成功，再次得到ORA-02049錯誤。因此重啟數據庫，又殺掉數據庫中的一個一直存在的本地連接。此后job運行成功，同步恢復。
? ? 問題原因分析：
? ? 維護人員反饋曾將在主節點PL/SQL Developer下執行的更新語句直接拷貝到同步節點執行，語句如下：
QUOTE:
Select * from t_userinfo where phonenumber=’***’ for update;
發生問題的數據庫是一個僅存放只讀快照的數據庫，也就是說這個庫是不應該有任何DML操作的。ORA-02049表明同步寫數據失敗，問題原因是此語句對同步節點的只讀快照加鎖，直接修改/加鎖了同步節點的物化視圖，造成同步寫失敗，導致應用失常用戶投訴。
? ? 總結：
? ? 如果使用PL/SQL Developer直接修改記錄，那么會自動生成SELECT FOR UPDATE的語句。一個普通的SELECT操作不會對正處理的行執行任何鎖定設置，但加上FOR UPDATE會在相關數據行上加互斥鎖，直到整個事務被提交才釋放。工程師拷貝執行了錯誤的語句，而且沒有關閉命令窗口，事務一直沒有提交或者回滾，造成此次事故。
? ? 最近已經發生數起使用PL/SQL Developer更新用戶表或者系統表，沒有關閉命令窗口，事務一直沒有提交或者回滾，造成鎖等待影響數據庫正常運行的事故。
? ? 結語
? ? 紅燈停，綠燈行。只有遵守交通規則，才能避免安全事故。硬盤壞、數據庫BUG造成數據庫事故的是小概率事件。更多數據庫事故是人為原因，該調的參數沒有調，該日常巡檢觀察的沒有檢查，該注意的事項沒有規避等等。近一兩年發布的各種安裝、維護、巡檢、備份等系列指導書，專門歸納常見熱點問題的數據庫FAQ，以及收錄產品線原創好文的主機空間，涵蓋了數據庫日常維護的方方面面，包括知識點、操作命令，維護經驗和注意事項等等內容，希望工程師能夠好好的使用這些資料，提高維護技能。只要我們掌握維護規則，避開數據庫操作的高壓線，就能夠有效的減少外購件的人為事故。
總結
以上是生活随笔為你收集整理的警惕Oracle DB操作高压线的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： MySQL数据库面试题（2022年最新版
- 下一篇： java实现modbus rtu协议与