1、阿里巴巴數據庫標準操作手冊01-建表一、 目的明確建表操作的風險及標準流程，最大限度避免建表操作帶來的故障。二、 適用范圍l 項目預發布新建表l 項目正式發布新建表l 不包含數據訂正所建臨時表l 不包含導數據所建的中間表三、 風險評估l 登錄到錯誤的schema下，導致表建到錯誤的schema里，而應用無法訪問。l 忽略了tablespace參數，導致表建到了默認表空間，導致后續空間增長和維護困難。l 對于未來增量較快的表選擇了一個空間規劃不足的表空間，導致后續空間增長和維護困難。l 腳本末尾缺少分號，導致該表沒有被創建上，而執行ddl的過程又不會報錯。l 其他原因漏建了表，導致應用訪問錯誤。

2、l 所建的表定義（表名、字段名、字段定義、字段個數、字段順序）跟測試環境不一致，導致應用訪問錯誤。l 同步庫沒有及時創建相應的表，或者沒有更新同步配置，導致同步及應用出問題。四、 操作流程1. 準備工作a) 在項目需求分析階段，跟數據庫設計人員一起明確新表所存放的數據庫。具體設計原則本文不繁述。b) 準備發布腳本時，檢查tablespace定義，檢查tablespace剩余空間，參考表空間自身負荷及新表的預期負荷，為每個新建的表選擇合適的表空間，并在建表語句中添加tablespace的配置。c) 定發布計劃時，跟開發接口人一起商定好建表操作的時間點。如小需求沒有發布計劃評審，則必須在提交測試時

3、（即表結構凍結時）即開始與開發接口人確定建表時間點。如果發生計劃外的發布建表需求，則要追究項目跟進的應用dba溝通不力的責任。d) 以目前的認知，僅建表操作本身不會對數據庫造成任何風險，故操作的時間點可以放寬：在變更時間窗口內，均可以執行建表操作。e) 建表操作屬于預授權變更，在做之前必須在itil中提交相應的變更申請。2. 執行過程 a) 用應用賬戶登錄數據庫，show user檢查是否連接到正確的schema。嚴禁使用sys、system等用戶建表。b) 執行建表腳本。若一次建表個數超過三個以上，要求將腳本事先保存為文本文件，上傳至數據庫服務器，執行時使用 create_table_ddl

4、.sql的方式直接執行。c) 查看過程若無報錯，退出當前登錄。若有報錯，找出報錯的地方，修改確認再執行，直至全部執行通過，最后退出當前登錄。3. 驗證方案a) 常規檢查：dbcheckb) 檢查表定義是否與測試庫一致：exec pkg_check.compareobject(user,table_name);c) 立即聯系開發接口人進行應用測試，【建表】變更是否成功以應用測試結果為準。d) 同步庫若建表，也需要執行 a) 和 b) 兩個步驟。02-數據訂正一、 目的明確【數據訂正】操作的種類、風險，并根據各種類型的數據訂正制定完善的步驟和回退方案，最大限度減少此類操作帶來的故障。二、 適用范圍

5、l 新建表數據初始化l 現有表新增數據l 現有表刪除數據l 現有表上新增字段初始化l 現有表上現有字段值修改三、 風險評估l 業務風險：訂正本身所包含的業務不正確，導致給客戶給公司帶來損失。l 程序風險：訂正本身業務正確，但是應用程序無法兼容訂正的數據，導致應用出錯。l 數據庫風險：訂正本身業務正確，應用程序也可以兼容，但是訂正速度過快、訂正并發壓力過大，導致數據庫無法正常提供服務。通常會造成表空間耗盡、undo消耗過快、archive增長過快、備庫恢復壓力大等問題。l 溝通風險：在業務方-開發接口人-dba三方的溝通交流過程中，信息傳遞錯誤或者不及時，導致最終訂正的數據沒有達到預期的目的。l

6、 回滾風險：主要是因為業務方的原因，訂正完成一段時間后要求回退，若在訂正前沒有備份原始數據，則可能導致無法順利回退或者回退難度極大，給客戶給公司帶來損失。l 同步風險：各類同步架構下，數據訂正可能導致同步堆積和同步延時，影響正常同步業務，所以有些大規模訂正必須要正確屏蔽同步，并在多個庫分別執行相同的訂正腳本。l 緩存：有些表在應用層面做了緩存，制定訂正計劃的時候要考慮到訂正后是否需要更新緩存。四、 操作流程1. 準備工作a) 需求分析階段確認項目涉及的數據訂正范圍和數據量。b) 跟開發人員確定訂正后是否涉及到對緩存的刷新和訂正。c) 根據數據量評估對數據同步的影響，決定是否屏蔽同步。（應用db

7、a必須熟悉同步采用的技術、正常情況下的同步量和延時、可以容忍的同步延時、屏蔽同步的具體方法。）d) 注意規劃訂正速度，以防undo消耗殆盡。e) 訂正腳本：i. 開發接口人直接提供可執行的sql腳本，dba只負責拷貝執行。ii. 開發接口人提供主鍵及更新字段新值列表，由dba導入數據庫，寫sql腳本關聯原表批量訂正。iii. 開發接口人提供訂正邏輯，由dba翻譯為批量提交sql腳本。iv. 訂正腳本要求可斷點續跑，可反復執行。v. 嚴禁僅用一個事務來處理大規模訂正（影響的記錄數超過1萬筆）。超過一萬筆的訂正必須分段提交。vi. 確認訂正腳本的執行計劃正確。vii. 腳本中加入“進度報告”，即調

8、用如下包（但是對于trigger中判斷client_info的不允許這樣處理。）：dbms_application_info.set_client_info(n | rows commit.);n為變量，累加，表示當前訂正的總記錄數。f) 開發階段跟開發接口人確認數據訂正邏輯，完成訂正腳本，并跟開發接口人確認腳本是否正確，同時按照需求準備備份腳本。g) 測試階段在測試庫執行訂正腳本，由開發接口人和測試人員驗證訂正的正確性，應用dba協助驗證。h) 發布前確定訂正速度和并發度，確定訂正時間段，預估訂正總時長，若涉及量較大，需要跨天做訂正，則應規劃好每日訂正的數據量和時間段。i) 備份要求：i.

9、新建表初始化：無需備份，回退時直接truncate即可。ii. 現有表新增數據：新建備份表記錄下新增記錄的主鍵，或者在新增記錄中特定字段標識區分出訂正所新增的數據，回退時定向delete這些記錄。iii. 現有表刪除數據：新建備份表記錄下刪除數據的完整記錄，回退時直接從備份表中取出數據insert到原表。iv. 現有表上新增字段初始化：無需備份，回退時將該字段update為null或者開發接口人要求的值。不得將刪除字段作為回退手段。v. 現有表上現有字段值修改：新建備份表記錄下所改動記錄的主鍵及所改動字段的原始值，回退時將改動過的字段按照主鍵更新到原表（若應用程序在回滾前已經修改了記錄，則要根

10、據具體業務具體分析回滾方案）。vi. 備份表：備份表統一命名為 table_name_bak_mmdd_operator，最后的operator為操作dba的姓名每個字的首字母，如果超長了，則將原表名縮減。創建人有責任定期刪除創建時間超過一個月以上的備份表。2. 執行過程 a) 如果需要，按照備份腳本備份數據。b) 執行訂正腳本。查看訂正進度，使用如下腳本：select client_info from v$session where client_info is not null;這個腳本必須配合前面描述的“進度報告”腳本執行。c) 檢查undo消耗: undod) 檢查表空間消耗: tbs

11、e) 檢查歸檔空間f) 檢查同步延時是否異常。g) 如果需要刷新應用緩存，在訂正結束后通知應用刷新緩存。3. 驗證方案a) 以應用驗證為主，數據庫輔助做一些count等驗證。以應用驗證通過為操作成功標準。五、 核心對象風險l 考慮到對erosa和otter的影響，嚴禁數據訂正更新主鍵值。六、 回退方案按照備份時所做的各種不同的回退方案進行回退，回退之后也要要求應用做驗證。03-創建、刪除、修改sequence一、 目的明確定義對于sequence對象的操作風險及步驟。二、 適用范圍l 項目發布創建新sequence。l 以刪除、重建的方式修改sequence的起始值。l 在線修改sequenc

12、e的cache值。三、 風險評估l sequence命名與應用程序中不一致，導致應用無法正常訪問sequence。l 雙向同步的庫，多庫創建同名sequence，起始值和步長值設置不合理，導致生成的值在表中對應主鍵值同步產生沖突。l 刪除、重建sequence的過程中，應用無法訪問sequence，高并發的應用可能會產生故障。l 刪除、重建sequence之后沒有對sequence的權限進行恢復，導致原本訪問該sequence的其他schema無法正常訪問。l sequence的cache設置不合理，設置過小會導致大量的系統相關等待，反之則導致sequence生成值斷層過多浪費嚴重。l jav

13、a程序的int16數據類型只能容納最大21億，所以sequence不能超過這個值，如果有可能超過，需要跟開發確認。四、 操作流程1. 準備工作a) 默認使用變更系統生成的sequence名稱，如果要修改，必須跟開發人員溝通一致。b) 與開發人員、項目發布負責人溝通變更時間點。對于刪除、重建的操作必須明確告訴他們其間會有短暫的無法訪問，如果是高并發的應用則選擇在系統訪問量最低的時候執行，規避風險。c) 根據并發數確定cache值，默認為100，如遇特殊需求，酌情調整。d) 刪除、重建的操作，事先檢查是否有其他schema擁有對于該sequence的訪問權限：select grantee, own

14、er, table_name, privilegefrom dba_tab_privswhere table_name = upper(重建的對象名);e) 全面考慮同步的風險，確定同步環節中各個數據庫的同名sequence起始值及步長，保證不會發生沖突，通常有如下兩種做法：i. 起始值相差不大，步長值等于數據庫個數。以雙庫同步為例，起始值分別設為1和2，步長均設為2。ii. 起始值相距較大，步長值相同。以雙庫同步為例，a庫起始值設為1，b庫起始值設為2億，步長均設為1。相差的值可以根據增長預期進行調整。2. 執行過程 a) 標準新建腳本：create sequence seq_tablena

15、me start with 1 cache 100;命名規范： seq_tablename默認不指定recycle和max value。b) 標準重建腳本：drop sequence seq_tablename ;create sequence seq_tablename start with 1 cache 100;為了盡量縮短sequence不可用時間，這兩個語句一起放在securecrt的chartwindow中一起執行。c) 標準修改cache腳本：alter sequence seq_tablename cache 200;d) 標準賦權腳本：grant select on seq_

16、tablename to username;3. 驗證方案a) dbcheck 檢查是否有失效對象b) 通知應用驗證是否可以正常訪問sequence五、 核心對象風險高并發對象重建時短暫不可訪問；04_增加、刪除唯一約束一、 目的明確增刪唯一約束操作的風險及標準流程，最大限度避免增刪唯一約束操作帶來的故障。二、 適用范圍l 項目發布新建表的增刪唯一約束l 對于舊表的增刪唯一約束三、 風險評估l 對現有表新增唯一約束的操作，會堵塞包括查詢在內的所有操作，風險很大，請謹慎使用，盡量在新建表時和開發討論后增加。l 沒有指定index,系統自動創建了index，刪除約束時，自動創建的index同時刪除

17、了。l 在高峰期創建,導致大量的library cache lock/pin的等待l 有同步的應用，先要在源端加，后在目標端加。l 表里有重復的數據，導致操作失敗。四、 操作流程1. 準備工作a) 檢查唯一建字段上是否存在index。沒有的話,需首先創建index( 步驟詳見增加index手冊)。 b) 檢查唯一鍵上是否有重復數據，如有，需和開發討論如何處理。c) 根據應用的需求和數據庫的負載情況，確定操作的時間點。對于數據量和訪問量較大的表，變更時間點要謹慎選擇.d) 檢查字段上是否已經有了約束。e) 增加和刪除唯一約束屬于標準變更，需要開發在itil中提交事件單，應用dba提交變更單，有技

18、術經理審批后執行。f) 對現有表新增約束，如果使用validate這個參數，會導致該表上連查詢在內的所有操作都被鎖住，風險非常大；如果使用novalidate參數，這個參數會導致數據字典不一致（及導致sqlldr的時候會導入重復數據）。兩者相比，故通常情況下用validate的風險更大，默認必須使用novalidate參數。g) 約束名與所依賴索引名一致。2. 執行過程 a) 用應用賬戶登錄數據庫，show user檢查是否連接到正確的schema。b) 執行增加或刪除的命令。命令模板如下：alter table 表名 add constraint 表名_uk unique (字段名) usi

19、ng index 索引名 novalidate;alter table 表名 drop constraint 約束名 keep index;如有otter同步，要注意執行順序：先在源數據庫端加后在目標端增加。c) 查看過程若無報錯，退出當前登錄。若有報錯，找出報錯的地方，修改確認再執行，直至全部執行通過，最后退出當前登錄。3. 驗證方案a) 常規檢查：dbcheckb) 檢查表定義是否與測試庫一致：exec pkg_check.compareobject(user,table_name);c) 檢查約束是否加上或刪除：select* fromdba_cons_columns wheretabl

20、e_name=upper(table_name)五、 核心對象風險1. 核心表訪問量大，數據量大。增加唯一約束時會短暫出現library cache pin/lock。執行時間要訂在核心表訪問的低峰期。六、 回退方案1. 執行前需準備好回退的腳本。2. 回退時需得到開發的確認，并確認回退的時間點。05-加字段一、 目的闡述表變更的風險及其步驟，降低對應用的影響和避免故障。二、 適用范圍l 所有在使用的表的加字段三、 風險評估l 新增字段的類型、長度（精度）是否合適解決方法：跟應用明確加字段和改字段的風險，確認新增字段類型正確、長度（精度）合適。以及跟應用明確老數據是否要訂正？如何訂正？新增列是

21、否非空？是否有默認值等等。l 新增字段的非空屬性、默認值以及老數據問題。新增字段如果是not null的，則一定要有默認值，否則老應用的insert代碼可能報錯。表如果存在老數據，帶上默認值的時候會導致oracle去訂正老的數據行的新增列。如果老數據非常多，表的并發訪問高，很有可能導致大面積的阻塞等待以及產生大事務，甚至有可能導致undo耗盡。倘若回滾，還會因為回滾產生的并發會話導致load飆升。解決方法：先不帶not null不帶默認值加上列，再更改列默認值，再批量訂正老數據，然后再加上not null屬性。如果是大表，并且并發訪問很高的表，則新增列不允許為not null，以簡化后面變更步

22、驟，降低風險！l 新增字段導致依賴對象失效、sql游標失效問題。表的dml并發很高的時候，如果表上面還有依賴對象，新增字段會導致依賴對象失效。默認其他dml會話會嘗試去自動編譯這個依賴對象，此時很可能會出現大面積的library cache pin。應用會話的連接時間會加長，進而導致出現后續應用報不能取得連接池錯誤。應用服務器load由此飆升。表新增字段也會導致跟該表有關的sql的游標失效，如果sql的并發很高（查詢sql或者dml sql），失效后sql會重新解析，此時也可能會出現大量的library cache pin & library cache lock。解決方法：選擇在業務

23、低峰期發布，同時在數據庫級別開啟trigger禁用客戶端程序自動編譯功能，字段加完后再禁用該trigger。l 表的依賴對象是否要相應調整。表上面的依賴對象如果有存儲過程或觸發器等，邏輯是否需要相應調整。l 是否涉及到同步。同步中的表需要兩地都要變更。涉及到erosa的要更新一下數據字典。erosa需要重啟一下。l 是否要通知其他關聯的部門。如dw, asc或crm等等。有些表很多部門都用，需要溝通約定時間一起變更。如果有同步方案，同步方案的變更也要考慮。四、 操作流程1. 準備工作a) 該表的數據量以及大小，以及數據變更量（按日/時/分/秒等）b) 該表的并發訪問數，以及頻率最高的幾種sql

24、的訪問方式2. 執行過程以表t1 加字段 col2為例。t1的數據量非常大，訪問頻率很高。a) 在sysdba下開啟trigger禁用客戶端自動編譯功能。（可選）alter trigger sys.ddl_trigger_for_database enable;b) 變更字段以下加字段同編譯失效對象連著執行。編譯時先編譯trigger再編譯存儲過程或package等conn zzzzzz/aaaalter table t1 add col2 varchar2(20);alter trigger trg_t1_search compile;conn retl/rrralter trigger t

25、rg_t1_sync compile;conn bopsretl/bbbalter trigger trg_t1_sync compile;conn zzzzzz/aaaalter procedure sp_test compile;后面3個trigger的編譯可以開三個窗口同時進行。另開一個窗口，在admin用戶下查看當前失效對象dbcheckc) 老數據訂正如果需要默認值，加上默認值alter table t1 modify col2 default y;數據訂正存儲過程create or replace procedure sp_dml0214ascursor c1 is select

26、rowed rid, id, col2 from t1 where col2 is null;v_cnt number := 0;beginfor rec_c1 in c1 loopv_cnt := v_cnt + 1;update t1 set col2=y where rowed = rec_c1.rid and id=rec_c1.id;if mod(v_cnt,500)=0 thencommit;dbms_application_info.set_client_info(sp_dml0214 | v_cnt | rows!);end if;end loop;commit;dbms_ap

27、plication_info.set_client_info(sp_dml0214 | v_cnt | rows!);end;/exec sp_dml0214;另開一個窗口，查看訂正進度col machine for a19col status for a12col client_info for a50select sid,serial#,status,machine,client_info,sql_hash_value from v$session where client_info is not null;d) 訂正完后加上not null屬性alter table t1 add col

28、2 not null;e) (國際站 可選)中美都變更，erosa重啟更新erosa數據字典./getdict.sh erosa重啟./erctl stop./erctl start3. 驗證方案a) 驗證sys下的trigger已經禁用select owner,trigger_name,status from dba_triggers where owner in (sys) and trigger_name= ddl_trigger_for_database enable;b) 驗證結構正確desc zzzzzz.t1c) 驗證無失效依賴對象dbcheck 五、 核心對象風險核心對象風險指

29、的是業務上重要的表，并且數據量很大或表大小很大或并發訪問數很高時，變更的潛在風險。前面已經闡述。六、 回退方案1. 大表的新增字段不允許回滾。因為回滾即刪掉字段，會導致鎖表，持續時間很長進而導致一序列的嚴重問題。2. 普通表的新增字段如果是發布失敗，后續還會有二次發布，也不考慮回滾。或者只是將not null屬性拿掉，下次發布再加上。3. 普通表如果應用有足夠的理由要求回滾，則回滾。06-加not null字段一、 目的闡述表變更的風險及其步驟，降低對應用的影響和避免故障。二、 適用范圍l 所有在使用的表的加not null字段，但核心表（并發訪問高的大表不允許加not null）。三、 風險

30、評估l 新增字段的類型、長度（精度）是否合適解決方法：跟應用明確加字段和改字段的風險，確認新增字段類型正確、長度（精度）合適。是否有默認值？以及跟應用明確老數據是否要訂正？如何訂正？l 新增字段的非空屬性、默認值以及老數據問題。新增字段是not null的，則一定要有默認值，否則老應用的insert代碼可能報錯。表如果存在老數據，帶上默認值的時候會導致oracle去訂正老的數據行的新增列。如果老數據非常多，表的并發訪問高，很有可能導致大面積的阻塞等待以及產生大事務，甚至有可能導致undo耗盡。倘若回滾，還會因為回滾產生的并發會話導致load飆升。解決方法：先不帶not null不帶默認值加上列

31、，再更改列默認值，再批量訂正老數據，然后再加上not null屬性。如果是大表，并且并發訪問很高的表，則新增列不允許為not null，以簡化后面變更步驟，降低風險！l 新增字段導致依賴對象失效、sql游標失效問題。表的dml并發很高的時候，如果表上面還有依賴對象，新增字段會導致依賴對象失效。默認訪問這些依賴對象的會話（如dml會話，或者應用調存儲過程等）會嘗試去自動編譯這個依賴對象（9i所有會話都會嘗試去編譯，10g以后只有一個會話去主動編譯，其他等待），此時很可能會出現大面積的library cache pin。應用會話的連接時間會加長，進而導致出現后續應用報不能取得連接池錯誤。應用服務器

32、load由此飆升。表新增字段也會導致跟該表有關的sql的游標失效，如果sql的并發很高（查詢sql或者dml sql），失效后sql會重新解析，此時也可能會出現大量的library cache pin & library cache lock。解決方法：選擇在業務低峰期發布，同時在數據庫級別開啟trigger禁用客戶端程序自動編譯功能，字段加完后再禁用該trigger。l 表的依賴對象是否要相應調整。表上面的依賴對象如果有存儲過程或觸發器等，邏輯是否需要相應調整。l 是否涉及到同步。同步中的表需要兩地都要變更。涉及到erosa的要更新一下數據字典。erosa需要重啟一下。l 是否要通知

33、其他關聯的部門。如dw, asc或crm等等。有些表很多部門都用，需要溝通約定時間一起變更。如果有同步方案，同步方案的變更也要考慮。l 表結構變更后應用需要重啟。應用端緩存的表結構跟實際結構有沖突報錯。四、 操作流程1. 準備工作a) 該表的數據量以及大小，以及數據變更量（按日/時/分/秒等）b) 該表的并發訪問數，以及頻率最高的幾種sql的訪問方式2. 執行過程以表t1 加字段 col2為例。t1的數據量非常大，訪問頻率很高。a) 在sysdba下開啟trigger禁用客戶端自動編譯功能。（可選）alter trigger sys.ddl_trigger_for_database enabl

34、e;b) 變更字段以下加字段同編譯失效對象連著執行。編譯時先編譯trigger再編譯存儲過程或package等conn zzzzzz/aaaalter table t1 add col2 varchar2(20);如果需要默認值，加上默認值alter table t1 modify col2 default y;alter trigger trg_t1_search compile;conn retl/rrralter trigger trg_t1_sync compile;conn bopsretl/bbbalter trigger trg_t1_sync compile;conn zzzz

35、zz/aaaalter procedure sp_test compile;另開一個窗口，在admin用戶下查看當前失效對象dbcheckc) 禁用ddl triggeralter trigger sys.ddl_trigger_for_database disable;d) 老數據訂正數據訂正存儲過程create or replace procedure sp_dml0214ascursor c1 is select rowed rid, id, col2 from t1 where col2 is null;v_cnt number := 0;beginfor rec_c1 in c1 l

36、oopv_cnt := v_cnt + 1;update t1 set col2=y where rowid = rec_c1.rid and id=rec_c1.id;if mod(v_cnt,500)=0 thencommit;end if;end loop;commit;end;/exec sp_dml0214;另開一個窗口，用sqlinfo腳本查看訂正進度e) 訂正完后加上not null屬性(核心表不要做了)，風險和步驟詳情參見文檔：4.增加、刪除唯一約束alter table t1 modify col2 not null;f) 表涉及到同步后，再多個節點變更，erosa是否重啟取

37、決于erosa版本。更新erosa數據字典./getdict.sh erosa重啟./erctl stop./erctl start3. 驗證方案a) 驗證sys下的trigger已經禁用select owner,trigger_name,status from dba_triggers where owner in (sys) and trigger_name=upper( ddl_trigger_for_database);b) 驗證結構正確desc zzzzzz.t1c) 驗證無失效依賴對象dbcheck d) 跟測試庫比對。五、 核心對象風險核心對象風險指的是業務上重要的表，并且數據量

38、很大或表大小很大或并發訪問數很高時，變更的潛在風險。前面已經闡述。六、 回退方案1. 大表的新增字段不允許回滾。因為回滾即刪掉字段，會導致鎖表，持續時間很長進而導致一序列的嚴重問題。2. 普通表的新增字段如果是發布失敗，后續還會有二次發布，也不考慮回滾。或者只是將not null屬性拿掉，下次發布再加上。3. 普通表如果應用有足夠的理由要求回滾，則回滾07-賦權一、 目的明確常用賦權操作標準流程，以及賦權過程中可能產生的風險，最大限度避免賦權操作帶來的系統故障。二、 適用范圍l 對數據庫對象的授權操作，數據庫對象包括表、存儲過程、同義詞、視圖和序列等。授權類型包括查詢、增刪改、執行。l 對數據

39、庫用戶的系統授權操作。三、 風險評估l 對數據庫用戶進行系統授權時，需要根據實際情況進行，避免因對用戶授予過高的系統權限或角色，進而使該用戶存在誤操作引發數據庫或應用故障的風險。l 對于存儲機密數據的表的授權，需要慎重。以免泄露機密數據。l 對于涉及同步的數據庫，需要分別在同步的兩端數據庫執行相同的授權操作。l 10g之前版本，grant操作需要獲得exclusive級別的library cache lock/pin。其風險主要針對于procedure、function等，對table基本無影響。若procedure正在執行時，對其本身或者其依賴的procedure、function進行授權，

40、將阻塞其他要執行此procedure或其依賴procedure、function的會話，直到授權前正在執行的procedure結束。l 對數據庫對象授權時，不會引起依賴對象失效，但會導致library cache中與授權對象有依賴關系的游標失效，進而產生硬解析。如果對象的依賴游標過多，或執行頻率較高，可能會對系統造成較大的沖擊，造成cpu繁忙，latch爭用嚴重，最常引起的latch爭用有 shared pool、library cache還會有library cache pin、cursor pin s:wait x等爭用出現。如果爭用比較嚴重，甚至可能導致數據庫crash。為避免此類情況出

41、現，對于新建對象，應盡可能的先把權限授予給可能會使用到的用戶；對于在使用的對象，應充分評估對象依賴游標的個數和執行次數，選擇執行低峰進行操作。l 對于grant any table，或者grant dba/ exp_full_database等涉及大量對象的系統授權操作，應該作為重大變更對待，此類操作的風險極大，務必在業務低峰期進行操作。四、 操作流程1. 準備工作a) 確認此次授權是否屬于正常的業務需要。b) 若賦予的為系統權限，禁止使用with admin option選項。c) 若賦予的為對象權限，請確認此對象在數據庫中緩存的游標個數，以及每個游標在不同時段的執行頻率，根據具體的情況選擇

42、合適的變更時間窗口進行授權。d) 準備授權腳本。e) 新建對象的授權需要走事件流程。f) 在用對象的授權或涉及大量對象的系統授權需要走一般變更或重大變更流程。2. 執行過程a) 以賦權對象所在的用戶登錄數據庫，show user檢查是否連接到正確的schema。b) 如果被依賴對象的執行頻率很高，需要打開ddl trigger.c) 執行賦權腳本。d) 查看過程若無報錯，退出當前登錄。3. 驗證方案,以下列舉兩種驗證方式：使用被賦權用戶登錄：i. 驗證對象權限：select owner,grantee,table_name,privilege from user_tab_privswhere

43、grantee=&user_nameand table_name=&object_name;ii. 驗證系統權限：select username,privilege from user_sys_privs;五、 核心對象風險核心對象上的依賴sql往往較多，而且執行頻率較高，授權操作會導致對象依賴的游標失效，進而導致硬解析風暴。應該盡量選擇業務低峰期來進行核心表的賦權操作。六、 回退方案我們遭遇的授權操作的最大風險第一是導致的硬解析風暴，第二是授權操作涉及數據字典的修改，甚至可能會導致row cache lock的出現。對于硬解析風暴的風險，回退的方案不是revoke對象的權限，

44、而是等待硬解析風暴過去。對于賦權操作引發的問題，要根據具體的情況而定。提前把方案一定要整理好，慎重選擇變更的時間，避免出現問題。08-修改字段長度一、 目的闡述表變更的風險及其步驟，降低對應用的影響和避免故障。二、 適用范圍l 所有在使用的表修改字段長度，具體是number型和varchar2型，只允許范圍擴大。三、 風險評估l 相關表的長度是否一并修改當該表某個字段長度加長后，可能有關聯的表的數據來自于該表，那么那個關聯的表的相應字段也應該加長。這點由應用去評估。該表上如果有物化視圖，則物化視圖的基表的對應的字段長度也要加長。該表上如果有存儲過程、觸發器、package，里面的代碼中跟該字段

45、有關的變量如果聲明的是具體的長度，則也要加長。正確的聲明方式是col%type。l 修改字段導致依賴對象失效、sql游標失效問題。表的dml并發很高的時候，如果表上面還有依賴對象，修改字段長度會導致依賴對象失效。默認其他dml會話會嘗試去自動編譯這個依賴對象，此時很可能會出現大面積的library cache pin。應用會話的連接時間會加長，進而導致出現后續應用報不能取得連接池錯誤。應用服務器load由此飆升。表修改字段長度也會導致跟該表有關的sql的游標失效，如果sql的并發很高（查詢sql或者dml sql），失效后sql會重新解析，此時也可能會出現大量的library cache pi

46、n & library cache lock。解決方法：選擇在業務低峰期發布，同時在數據庫級別開啟trigger禁用客戶端程序自動編譯功能，字段加完后再禁用該trigger。l 表的依賴對象是否要相應調整。表上面的依賴對象如果有存儲過程或觸發器等，邏輯是否需要相應調整。l 是否涉及到同步。同步中的表需要兩地都要變更。涉及到erosa的要更新一下數據字典。erosa是否需要重啟取決于erosa版本。l 是否要通知其他關聯的部門。如dw, asc或crm等等。有些表很多部門都用，需要溝通約定時間一起變更。如果有同步方案，同步方案的變更也要考慮。四、 操作流程1. 準備工作a) 該表的數據量

47、以及大小，以及數據變更量（按日/時/分/秒等）b) 該表的并發訪問數，以及頻率最高的幾種sql的訪問方式2. 執行過程 以表t1 加字段 col2為例。t1的數據量非常大，訪問頻率很高。a) 在sysdba下開啟trigger禁用客戶端自動編譯功能。（可選）alter trigger sys.ddl_trigger_for_database enable;b) 變更字段以下加字段同編譯失效對象連著執行。編譯時先編譯trigger再編譯存儲過程或package等conn zzzzzz/aaaalter table t1 modify col2 varchar2(50);alter trigger

48、 trg_t1_search compile;conn retl/rrralter trigger trg_t1_sync compile;conn bopsretl/bbbalter trigger trg_t1_sync compile;conn zzzzzz/aaaalter procedure sp_test compile;后面3個trigger的編譯可以開三個窗口同時進行。另開一個窗口，在admin用戶下查看當前失效對象dbcheckc) 禁用ddl triggeralter trigger sys.ddl_trigger_for_database disable;d) 涉及到同步

49、的表，各個節點都變更，erosa重啟取決于版本更新erosa數據字典./getdict.sh erosa重啟./erctl stop./erctl start3. 驗證方案a) 驗證sys下的trigger已經禁用select owner,trigger_name,status from dba_triggers where owner in (sys) and trigger_name=upper( ddl_trigger_for_database );b) 驗證結構正確desc alibaba1949.t1c) 驗證無失效依賴對象dbcheck d) 跟測試庫比對結構五、 核心對象風險核心

50、對象風險指的是業務上重要的表，并且數據量很大或表大小很大或并發訪問數很高時，變更的潛在風險。前面已經闡述。09-改動統計信息一、 目的oracle優化器依據對象、系統的統計 信息來產生執行計劃。因此如何收集對象、系統的統計信息尤其重要，本文檔主要介紹收集對象統計信息的操作方法。某些情況下，如執行計劃走錯、表缺少關鍵字 段統計信息，需要我們手工的設置統計信息，因此也會涉及修改對象統計信息的內容。對于執行計劃走錯，通過修改統計信息來修正的情況，要對cbo算法有簡單的了解，知道哪些統計信息涉及到cost計算的過程。可以參考lewis的cbo優化法則來了解cost的計算.本手冊不會涉及這些內容。二、

51、適用范圍l 新建表，表里初始化了大量的數據。 l 對于已經存在的表，表里數據量變化比較大。比如表刪除了大量數據。需要重新收集統計信息。l 由于表上統計信息不準確或缺失導致執行計劃走錯。l 表統計信息過于陳舊，可能導致執行計劃錯誤三、 風險評估l 統計信息的改變會涉及到表上所有sql在下一次硬解析的時候用到，因此影響面廣。在操作的時候，需要確認影響的范圍，不要單純為了某一個sql的執行計劃正確，而導致更多的sql執行計劃走錯。l 請仔細評估好，no_invalidate的設置問題，這個參數設置為true，表上依賴的sql不會立馬失效，即不會立刻采用表上新的統計信息。只有下一次硬解析的時候才會用新

52、的統計信息來生成執行計劃。絕大多數時候，我們這邊采用的參數值是false.代表讓表上依賴的游標立刻失效，在下一次解析的時候，能夠立刻用上表上新的統計信息。l no_invalidate在設置為false會導致在收集統計信息完成后，表上所有的sql重新解析，對于核心表以及一些依賴sql很多的表，要盡量放到業務低峰期去操作，否則可能遭遇硬解析的風暴，導致系統cpu繁忙，latch爭用（shared pool latch ,library cache latch，library cache pin,cursor pin s:wait x）.如果遭遇這種情況，大多數時候，這種爭用會隨著硬解析完成而很快

53、結束，但是也有可能會導致oracle crash。l oracle優化器依賴準確健全的統計信息來產生優秀的執行計劃，雖然收集統計信息理論上是為了讓更精準的、更能反映目前數據的分布的統計信息產生出更優秀的執行計劃，但是無論如何oracle無法保證這一點，有可能執行計劃更優秀或者不變，有可能更糟糕了，相信隨著oracle版本的不斷提升，優化器的bug會越來越少。l oracle的dbms_stats不能單獨收集列的統計信息，要了解到，如果收集了某一列的統計信息，表的統計信息會隨著更新。l 把estimate_percent設置的比較小，可以加快收集統計信息的時間，在不收集直方圖的情況下，設置較小的

54、值一般也不會有任何問題。可是如果表存在直方圖，那么還是建議你根據情況把這個參數設置的大點。l 目前生產環境都關閉了綁定變量窺探的功能，因此對于收集了直方圖的列，需要確認傳入的是文本變量。四、 操作流程幾個重要收集參數的介紹以及使用規范：1. no_invalidate 是否讓表上的游標立即失效：自動定期執行（crontab）設置true，手動收集設置false。2. force 是否對鎖定統計信息的表收集統計信息 ：不指定，統一規范使用默認值false 不收集鎖定表的統計信息，如果需要收集請提單給出原因。3. degree 收集統計信息的并行度 ： 不指定，使用默認值1；如果為了加快收集時間，

55、可以設置高的并行度，需要提單給出理由。4. estimate_percent 采樣百分比：一般設置成 0.5 ，可以讓收集統計信息的時間縮短。這個值是個最小值，如果oracle覺得這個值小，會自動調大。采樣的大小不要超過100m，采樣的時間控制在1分鐘以內。5. method_opt 收集直方圖的方法 ：分以下幾種情況：a) 執行計劃走錯：1. 收集指定列的基本統計信息：for columns a size repeat,b size repeat2. 收集指定列的直方圖：for columns a size auto,b size auto b) 統計信息全為空：收集所有列的基本信息，同時收集個別列的直方圖：for columns size repeat, a size auto,b size autoc) 定時收集統計信息：for all columns size repeat 6. cascade 設置成true，收集索引的統計信息。9i默認值是false,10g默認值是true.7. 如果是分區表，需要指定partname參數。更多參數的說明請參照我寫的dbms_stats包參數介紹。文檔位于：數據庫管理à知識總結-àdbms_st