【正文】 查看過程若無報錯，退出當前登錄。ALTER TABLE 表名 DROP CONSTRAINT 約束名 KEEP INDEX。b) 執(zhí)行增加或刪除的命令。g) 約束名與所依賴索引名一致。f) 對現(xiàn)有表新增約束，如果使用validate這個參數(shù)，會導(dǎo)致該表上連查詢在內(nèi)的所有操作都被鎖住，風險非常大；如果使用novalidate參數(shù)，這個參數(shù)會導(dǎo)致數(shù)據(jù)字典不一致（及導(dǎo)致sqlldr的時候會導(dǎo)入重復(fù)數(shù)據(jù)）。對于數(shù)據(jù)量和訪問量較大的表，變更時間點要謹慎選擇.d) 檢查字段上是否已經(jīng)有了約束。 b) 檢查唯一鍵上是否有重復(fù)數(shù)據(jù)，如有，需和開發(fā)討論如何處理。四、 操作流程1. 準備工作a) 檢查唯一建字段上是否存在index。l 在高峰期創(chuàng)建,導(dǎo)致大量的library cache lock/pin的等待l 有同步的應(yīng)用，先要在源端加，后在目標端加。二、 適用范圍l 項目發(fā)布新建表的增刪唯一約束l 對于舊表的增刪唯一約束三、 風險評估l 對現(xiàn)有表新增唯一約束的操作，會堵塞包括查詢在內(nèi)的所有操作，風險很大，請謹慎使用，盡量在新建表時和開發(fā)討論后增加。d) 標準賦權(quán)腳本：GRANT SELECT ON seq_tablename to username。為了盡量縮短sequence不可用時間，這兩個語句一起放在SecureCRT的chartWindow中一起執(zhí)行。b) 標準重建腳本：DROP SEQUENCE seq_tablename 。2. 執(zhí)行過程 a) 標準新建腳本：CREATE SEQUENCE seq_tablename START WITH 1 CACHE 100。以雙庫同步為例，A庫起始值設(shè)為1，B庫起始值設(shè)為2億，步長均設(shè)為1。以雙庫同步為例，起始值分別設(shè)為1和2，步長均設(shè)為2。d) 刪除、重建的操作，事先檢查是否有其他schema擁有對于該sequence的訪問權(quán)限：SELECT grantee, owner, table_name, privilegeFROM dba_tab_privsWHERE table_name = upper(’重建的對象名‘)。對于刪除、重建的操作必須明確告訴他們其間會有短暫的無法訪問，如果是高并發(fā)的應(yīng)用則選擇在系統(tǒng)訪問量最低的時候執(zhí)行，規(guī)避風險。四、 操作流程1. 準備工作a) 默認使用變更系統(tǒng)生成的sequence名稱，如果要修改，必須跟開發(fā)人員溝通一致。l Sequence的cache設(shè)置不合理，設(shè)置過小會導(dǎo)致大量的系統(tǒng)相關(guān)等待，反之則導(dǎo)致sequence生成值斷層過多浪費嚴重。l 刪除、重建sequence的過程中，應(yīng)用無法訪問sequence，高并發(fā)的應(yīng)用可能會產(chǎn)生故障。三、 風險評估l Sequence命名與應(yīng)用程序中不一致，導(dǎo)致應(yīng)用無法正常訪問sequence。l 以刪除、重建的方式修改sequence的起始值。03創(chuàng)建、刪除、修改sequence一、 目的明確定義對于sequence對象的操作風險及步驟。五、 核心對象風險l 考慮到對erosa和otter的影響，嚴禁數(shù)據(jù)訂正更新主鍵值。3. 驗證方案a) 以應(yīng)用驗證為主，數(shù)據(jù)庫輔助做一些count等驗證。c) 檢查undo消耗: undod) 檢查表空間消耗: tbse) 檢查歸檔空間f) 檢查同步延時是否異常。查看訂正進度，使用如下腳本：select client_info from v$session where client_info is not null。2. 執(zhí)行過程 a) 如果需要，按照備份腳本備份數(shù)據(jù)。vi. 備份表：備份表統(tǒng)一命名為 table_name_bak_mmdd_operator，最后的operator為操作DBA的姓名每個字的首字母，如果超長了，則將原表名縮減。不得將刪除字段作為回退手段。iii. 現(xiàn)有表刪除數(shù)據(jù)：新建備份表記錄下刪除數(shù)據(jù)的完整記錄，回退時直接從備份表中取出數(shù)據(jù)insert到原表。i) 備份要求：i. 新建表初始化：無需備份，回退時直接truncate即可。g) 測試階段在測試庫執(zhí)行訂正腳本，由開發(fā)接口人和測試人員驗證訂正的正確性，應(yīng)用DBA協(xié)助驗證。–n為變量，累加，表示當前訂正的總記錄數(shù)。vii. 腳本中加入“進度報告”，即調(diào)用如下包（但是對于trigger中判斷client_info的不允許這樣處理。超過一萬筆的訂正必須分段提交。iv. 訂正腳本要求可斷點續(xù)跑，可反復(fù)執(zhí)行。ii. 開發(fā)接口人提供主鍵及更新字段新值列表，由DBA導(dǎo)入數(shù)據(jù)庫，寫SQL腳本關(guān)聯(lián)原表批量訂正。）d) 注意規(guī)劃訂正速度，以防undo消耗殆盡。c) 根據(jù)數(shù)據(jù)量評估對數(shù)據(jù)同步的影響，決定是否屏蔽同步。四、 操作流程1. 準備工作a) 需求分析階段確認項目涉及的數(shù)據(jù)訂正范圍和數(shù)據(jù)量。l 同步風險：各類同步架構(gòu)下，數(shù)據(jù)訂正可能導(dǎo)致同步堆積和同步延時，影響正常同步業(yè)務(wù)，所以有些大規(guī)模訂正必須要正確屏蔽同步，并在多個庫分別執(zhí)行相同的訂正腳本。l 溝通風險：在業(yè)務(wù)方開發(fā)接口人DBA三方的溝通交流過程中，信息傳遞錯誤或者不及時，導(dǎo)致最終訂正的數(shù)據(jù)沒有達到預(yù)期的目的。l 數(shù)據(jù)庫風險：訂正本身業(yè)務(wù)正確，應(yīng)用程序也可以兼容，但是訂正速度過快、訂正并發(fā)壓力過大，導(dǎo)致數(shù)據(jù)庫無法正常提供服務(wù)。二、 適用范圍l 新建表數(shù)據(jù)初始化l 現(xiàn)有表新增數(shù)據(jù)l 現(xiàn)有表刪除數(shù)據(jù)l 現(xiàn)有表上新增字段初始化l 現(xiàn)有表上現(xiàn)有字段值修改三、 風險評估l 業(yè)務(wù)風險：訂正本身所包含的業(yè)務(wù)不正確，導(dǎo)致給客戶給公司帶來損失。d) 同步庫若建表，也需要執(zhí)行 a) 和 b) 兩個步驟。3. 驗證方案a) 常規(guī)檢查：dbcheckb) 檢查表定義是否與測試庫一致：exec (’user‘,’TABLE_NAME‘)。c) 查看過程若無報錯，退出當前登錄。b) 執(zhí)行建表腳本。2. 執(zhí)行過程 a) 用應(yīng)用賬戶登錄數(shù)據(jù)庫，SHOW USER檢查是否連接到正確的schema。d) 以目前的認知，僅建表操作本身不會對數(shù)據(jù)庫造成任何風險，故操作的時間點可以放寬：在變更時間窗口內(nèi)，均可以執(zhí)行建表操作。如小需求沒有發(fā)布計劃評審，則必須在提交測試時（即表結(jié)構(gòu)凍結(jié)時）即開始與開發(fā)接口人確定建表時間點。b) 準備發(fā)布腳本時，檢查tablespace定義，檢查tablespace剩余空間，參考表空間自身負荷及新表的預(yù)期負荷，為每個新建的表選擇合適的表空間，并在建表語句中添加tablespace的配置。四、 操作流程1. 準備工作a) 在項目需求分析階段，跟數(shù)據(jù)庫設(shè)計人員一起明確新表所存放的數(shù)據(jù)庫。l 所建的表定義（表名、字段名、字段定義、字段個數(shù)、字段順序）跟測試環(huán)境不一致，導(dǎo)致應(yīng)用訪問錯誤。l 腳本末尾缺少分號，導(dǎo)致該表沒有被創(chuàng)建上，而執(zhí)行DDL的過程又不會報錯。l 忽略了TABLESPACE參數(shù)，導(dǎo)致表建到了默認表空間，導(dǎo)致后續(xù)空間增長和維護困難。01建表一、 目的明確建表操作的風險及標準流程，最大限度避免建表操作帶來的故障。二、 適用范圍l 項目預(yù)發(fā)布新建表l 項目正式發(fā)布新建表l 不包含數(shù)據(jù)訂正所建臨時表l 不包含導(dǎo)數(shù)據(jù)所建的中間表三、 風險評估l 登錄到錯誤的schema下，導(dǎo)致表建到錯誤的schema里，而應(yīng)用無法訪問。l 對于未來增量較快的表選擇了一個空間規(guī)劃不足的表空間，導(dǎo)致后續(xù)空間增長和維護困難。l 其他原因漏建了表，導(dǎo)致應(yīng)用訪問錯誤。l 同步庫沒有及時創(chuàng)建相應(yīng)的表，或者沒有更新同步配置，導(dǎo)致同步及應(yīng)用出問題。具體設(shè)計原則本文不繁述。c) 定發(fā)布計劃時，跟開發(fā)接口人一起商定好建表操作的時間點。如果發(fā)生計劃外的發(fā)布建表需求，則要追究項目跟進的應(yīng)用DBA溝通不力的責任。e) 建表操作屬于預(yù)授權(quán)變更，在做之前必須在ITIL中提交相應(yīng)的變更申請。嚴禁使用sys、system等用戶建表。若一次建表個數(shù)超過三個以上，要求將腳本事先保存為文本文件，上傳至數(shù)據(jù)庫服務(wù)器，執(zhí)行時使用 。若有報錯，找出報錯的地方，修改確認再執(zhí)行，直至全部執(zhí)行通過，最后退出當前登錄。c) 立即聯(lián)系開發(fā)接口人進行應(yīng)用測試，【建表】變更是否成功以應(yīng)用測試結(jié)果為準。02數(shù)據(jù)訂正一、 目的明確【數(shù)據(jù)訂正】操作的種類、風險，并根據(jù)各種類型的數(shù)據(jù)訂正制定完善的步驟和回退方案，最大限度減少此類操作帶來的故障。l 程序風險：訂正本身業(yè)務(wù)正確，但是應(yīng)用程序無法兼容訂正的數(shù)據(jù)，導(dǎo)致應(yīng)用出錯。通常會造成表空間耗盡、undo消耗過快、archive增長過快、備庫恢復(fù)壓力大等問題。l 回滾風險：主要是因為業(yè)務(wù)方的原因，訂正完成一段時間后要求回退，若在訂正前沒有備份原始數(shù)據(jù)，則可能導(dǎo)致無法順利回退或者回退難度極大，給客戶給公司帶來損失。l 緩存：有些表在應(yīng)用層面做了緩存，制定訂正計劃的時候要考慮到訂正后是否需要更新緩存。b) 跟開發(fā)人員確定訂正后是否涉及到對緩存的刷新和訂正。（應(yīng)用DBA必須熟悉同步采用的技術(shù)、正常情況下的同步量和延時、可以容忍的同步延時、屏蔽同步的具體方法。e) 訂正腳本：i. 開發(fā)接口人直接提供可執(zhí)行的SQL腳本，DBA只負責拷貝執(zhí)行。iii. 開發(fā)接口人提供訂正邏輯，由DBA翻譯為批量提交SQL腳本。v. 嚴禁僅用一個事務(wù)來處理大規(guī)模訂正（影響的記錄數(shù)超過1萬筆）。vi. 確認訂正腳本的執(zhí)行計劃正確。）：(n || ‘ rows mit.’)。f) 開發(fā)階段跟開發(fā)接口人確認數(shù)據(jù)訂正邏輯，完成訂正腳本，并跟開發(fā)接口人確認腳本是否正確，同時按照需求準備備份腳本。h) 發(fā)布前確定訂正速度和并發(fā)度，確定訂正時間段，預(yù)估訂正總時長，若涉及量較大，需要跨天做訂正，則應(yīng)規(guī)劃好每日訂正的數(shù)據(jù)量和時間段。ii. 現(xiàn)有表新增數(shù)據(jù)：新建備份表記錄下新增記錄的主鍵，或者在新增記錄中特定字段標識區(qū)分出訂正所新增的數(shù)據(jù)，回退時定向delete這些記錄。iv. 現(xiàn)有表上新增字段初始化：無需備份，回退時將該字段update為NULL或者開發(fā)接口人要求的值。v. 現(xiàn)有表上現(xiàn)有字段值修改：新建備份表記錄下所改動記錄的主鍵及所改動字段的原始值，回退時將改動過的字段按照主鍵更新到原表（若應(yīng)用程序在回滾前已經(jīng)修改了記錄，則要根據(jù)具體業(yè)務(wù)具體分析回滾方案）。創(chuàng)建人有責任定期刪除創(chuàng)建時間超過一個月以上的備份表。b) 執(zhí)行訂正腳本。–這個腳本必須配合前面描述的“進度報告”腳本執(zhí)行。g) 如果需要刷新應(yīng)用緩存，在訂正結(jié)束后通知應(yīng)用刷新緩存。以應(yīng)用驗證通過為操作成功標準。六、 回退方案按照備份時所做的各種不同的回退方案進行回退，回退之后也要要求應(yīng)用做驗證。二、 適用范圍l 項目發(fā)布創(chuàng)建新sequence。l 在線修改sequence的cache值。l 雙向同步的庫，多庫創(chuàng)建同名sequence，起始值和步長值設(shè)置不合理，導(dǎo)致生成的值在表中對應(yīng)主鍵值同步產(chǎn)生沖突。l 刪除、重建sequence之后沒有對sequence的權(quán)限進行恢復(fù)，導(dǎo)致原本訪問該sequence的其他schema無法正常訪問。l Java程序的int16數(shù)據(jù)類型只能容納最大21億，所以sequence不能超過這個值，如果有可能超過，需要跟開發(fā)確認。b) 與開發(fā)人員、項目發(fā)布負責人溝通變更時間點。c) 根據(jù)并發(fā)數(shù)確定cache值，默認為100，如遇特殊需求，酌情調(diào)整。e) 全面考慮同步的風險，確定同步環(huán)節(jié)中各個數(shù)據(jù)庫的同名sequence起始值及步長，保證不會發(fā)生沖突，通常有如下兩種做法：i. 起始值相差不大，步長值等于數(shù)據(jù)庫個數(shù)。ii. 起始值相距較大，步長值相同。相差的值可以根據(jù)增長預(yù)期進行調(diào)整。命名規(guī)范： seq_tablename默認不指定recycle和max value。CREATE SEQUENCE seq_tablename START WITH 1 CACHE 100。c) 標準修改cache腳本：ALTER SEQUENCE seq_tablename CACHE 200。3. 驗證方案a) dbcheck 檢查是否有失效對象b) 通知應(yīng)用驗證是否可以正常訪問sequence五、 核心對象風險高并發(fā)對象重建時短暫不可訪問；04_增加、刪除唯一約束一、 目的明確增刪唯一約束操作的風險及標準流程，最大限度避免增刪唯一約束操作帶來的故障。l 沒有指定index,系統(tǒng)自動創(chuàng)建了index，刪除約束時，自動創(chuàng)建的index同時刪除了。l 表里有重復(fù)的數(shù)據(jù)，導(dǎo)致操作失敗。沒有的話,需首先創(chuàng)建index( 步驟詳見增加index手冊)。c) 根據(jù)應(yīng)用的需求和數(shù)據(jù)庫的負載情況，確定操作的時間點。e) 增加和刪除唯一約束屬于標準變更，需要開發(fā)在ITIL中提交事件單，應(yīng)用dba提交變更單，有技術(shù)經(jīng)理審批后執(zhí)行。兩者相比，故通常情況下用validate的風險更大，默認必須使用novalidate參數(shù)。2. 執(zhí)行過程 a) 用應(yīng)用賬戶登錄數(shù)據(jù)庫，SHOW USER檢查是否連接到正確的schema。命令模板如下：ALTER TABLE 表名 ADD CONSTRAINT 表名_uk unique (字段名) USING INDEX 索引名 NOVALIDATE。如有otter同步，要注意執(zhí)行順序：先在源數(shù)據(jù)庫端加后在目標端增加。若有報錯，找出報錯的地方，修改確認再執(zhí)行，直至全部執(zhí)行通過，最后退出當前登錄。c) 檢查約束是否加上或刪除：select* fromdba_cons_columns wheretable_name=upper(‘table_name’)五、 核心對象風險1. 核心表訪問量大，數(shù)據(jù)量大。執(zhí)行時間要訂在核心表訪問的低峰期。2. 回退時需得到開發(fā)的確認，并確認回退的時間點。二、 適用范圍l 所有在使用的表