2.2 命名
2.2.1 語言
命名應該使用英文單詞，避免使用拼音，特別不應該使用拼音簡寫。命名不允許使用中文或者特殊字符。
英文單詞使用用對象本身意義相對或相近的單詞。選擇最簡單或最通用的單詞。不能使用毫不相干的單詞來命名
當一個單詞不能表達對象含義時，用詞組組合，如果組合太長時，採用用簡或縮寫，縮寫要基本能表達原單詞的意義。
當出現對象名重名時，是不同類型對象時，加類型前綴或後綴以示區別。
2.2.2 大小寫
名稱一律大寫，以方便不同數據庫移植，以及避免程序調用問題。
2.2.3 單詞分隔
命名的各單詞之間可以使用下劃線進行分隔。
2.2.4 保留字
命名不允許使用 SQL 保留字。
2.2.5 命名長度
表名、字段名、視圖名長度應限制在 20 個字符內 ( 含前綴 ) 。
2.2.6 字段名稱
同一個字段名在一個數據庫中只能代表一個意思。比如 telephone 在一個表中代表 “ 電話號碼 ” 的意思，在另外一個表中就不能代表 “ 手機號碼 ” 的意思。
不同的表用於相同內容的字段應該採用同樣的名稱，字段類型定義。
2.3 數據類型
2.3.1 字符型
固定長度的字串類型採用 char ，長度不固定的字串類型採用 varchar 。避免在長度不固定的情況下采用 char 類型。如果在數據遷移等出現以上情況，則必須使用 trim() 函數截去字串後的空格。
2.3.2 數字型
數字型字段儘量採用 number 類型。
2.3.3 日期和時間
2.3.3.1 系統時間
由數據庫產生的系統時間首選數據庫的日期型，如 DATE 類型。
2.3.3.2 外部時間
由數據導入或外部應用程序產生的日期時間類型採用 varchar 類型，數據格式採用： YYYYMMDDHH24MISS 。
2.3.3.3 大字段
如無特別需要，避免使用大字段 (blob ， clob ， long ， text ， image 等 ) 。
2.3.3.4 唯一鍵
對於數字型唯一鍵值，儘可能用系列 sequence 產生。
2.4 設計
2.4.1 範式
如無性能上的必須原因，應該使用關係數據庫理論，達到較高的範式，避免數據冗餘 , 但是如果在數據量上與性能上無特別要求，考慮到實現的方便性可以有適當的數據冗餘，但基本上要達到 3NF. 如非確實必要，避免一個字段中存儲多個標誌的做法。如 11101 表示 5 個標誌的一種取值。這往往是增加複雜度，降低性能的地方。
2.4.2 表設計
2.4.2.1 邏輯段設計原則
2.4.2.1.1 Tablespace
每個表在創建時候，必須指定所在的表空間，不要採用默認表空間以防止表建立在系統表空間上導致性能問題。對於事務比較繁忙的數據表，必須存放在該表的專用表空間中。
2.4.2.1.2 Pctused
默認 pctused 導致數據庫物理空間利用率非常低 40% 左右；對於 update 比較少或 update 不導致行增大的表， pctused 可設置在 60—85 之間；對於 update 能夠導致行增大的表， update 設置在 40—70 之間
2.4.2.1.3 Initrans
對於需要並行查詢或者在 RAC 數據庫中需要並行處理的表， initrans 設置爲 2 的倍數，否則，不設該值。
2.4.2.1.4 Storage
2.4.2.1.4.1 Initial
儘量減少表數據段的 extents 數量， initial 的大小盡量接近數據段的大小 64K ， 128K ， … ， 1M ， 2M ， 4M ， 8M ， 16M ， … ，等按 2 的倍數進行圓整。例如表或分區數據段大小爲 28M ，則 initial 取 32M 。
2.4.2.1.4.2 Next
表或分區擴展 extents 的大小，按上述方法進行圓整。當表或分區數據段無法按 Initial 接近值進行圓整的情況下，其大小可以按 Initial+Next 進行圓整。此時，必須設置 Minextents=2 。例如：表或分區數據段大小爲 150M ，則 Initial=128M ； Next=32M ， Minextents=2 。
2.4.2.1.4.3 Minextents
該參數表示表創建時候 Extents 的初始數量，一般取 1—2 。
2.4.2.1.4.4 Pctincrease
表示每個擴展 Extents 的增長率，設置 pctincrease=0 能夠獲得較好的存儲性能。
2.4.2.2 特殊表設計原則
2.4.2.2.1 分區表
對於數據量比較大的表，根據表數據的屬性進行分區，以得到較好的性能。如果表按某些字段進行增長，則採用按字段值範圍進行範圍分區；如果表按某個字段的幾個關鍵值進行分佈，則採用列表分區；對於靜態表，則採用 hash 分區或列表分區；在範圍分區中，如果數據按某關鍵字段均衡分佈，則採用子分區的複合分區方法。
2.4.2.2.2 聚蔟表
如果某幾個靜態表關係比較密切，則可以採用聚蔟表的方法。
2.4.2.3 完整性設計原則
2.4.2.3.1 主鍵約束
關聯表的父表要求有主健，主健字段或組合字段必須滿足非空屬性和唯一性要求。對於數據量比較大的父表，要求指定索引段。
2.4.2.3.2 外鍵關聯
對於關聯兩個表的字段，一般應該分別建立主鍵、外鍵。實際是否建立外鍵，根據對數據完整性的要求決定。爲了提高性能，對於數據量比較大的標要求對外健建立索引。對於有要求級聯刪除屬性的外鍵，必須指定 on delete cascade 。
2.4.2.3.3 NULL 值
對於字段能否 null ，應該在 sql 建表腳本中明確指明，不應使用缺省。由於 NULL 值在參加任何運算中，結果均爲 NULL 。所以在應用程序中必須利用 nvl() 函數把可能爲 NULL 值得字段或變量轉換爲非 NULL 的默認值。例如： NVL （ sale,0 ）。
2.4.2.3.4 Check 條件
對於字段有檢查性約束，要求指定 check 規則。
2.4.2.3.5 觸發器
觸發器是一種特殊的存儲過程，通過數據表的 DML 操作而觸發執行，起作用是爲確保數據的完整性和一致性不被破壞而創建，實現數據的完整約束。
觸發器的 before 或 after 事務屬性的選擇時候，對錶操作的事務屬性必須與應用程序事務屬性保持一致，以避免死鎖發生。在大型導入表中，儘量避免使用觸發器。
2.4.2.4 註釋
表、字段等應該有中文名稱註釋，以及需要說明的內容。
2.4.3 索引設計
對於查詢中需要作爲查詢條件的字段，可以考慮建立索引。最終根據性能的需要決定是否建立索引。對於複合索引，索引字段順序比較關鍵，把查詢頻率比較高的字段排在索引組合的最前面。在分區表中，儘量採用 local 分區索引以方便分區維護。
除非時分區 local 索引，否則在創建索引段時候必須指定指定索引段的 tablespace 、 storage 屬性，具體參考 4.4.2.1 內容。
2.4.4 視圖設計
視圖是虛擬的數據庫表，在使用時要遵循以下原則：
從一個或多個庫表中查詢部分數據項；
爲簡化查詢，將複雜的檢索或字查詢通過視圖實現；
提高數據的安全性，只將需要查看的數據信息顯示給權限有限的人員；
視圖中如果嵌套使用視圖，級數不得超過 3 級；
由於視圖中只能固定條件或沒有條件，所以對於數據量較大或隨時間的推移逐漸增多的庫表，不宜使用視圖；可以採用實體化視圖代替。
除特殊需要，避免類似 Select * from [TableName] 而沒有檢索條件的視圖；
視圖中儘量避免出現數據排序的 SQL 語句。
2.4.5 包設計
存儲過程、函數、外部遊標必須在指定的數據包對象 PACKAGE 中實現。存儲過程、函數的建立如同其它語言形式的編程過程，適合採用模塊化設計方法；當具體算法改變時，只需要修改需要存儲過程即可，不需要修改其它語言的源程序。當和數據庫頻繁交換數據是通過存儲過程可以提高運行速度，由於只有被授權的用戶才能執行存儲過程，所以存儲過程有利於提高系統的安全性。
存儲過程、函數必須檢索數據庫表記錄或數據庫其他對象，甚至修改（執行 Insert 、 Delete 、 Update 、 Drop 、 Create 等操作）數據庫信息。如果某項功能不需要和數據庫打交道，則不得通過數據庫存儲過程或函數的方式實現。在函數中避免採用 DML 或 DDL 語句。
在數據包採用存儲過程、函數重載的方法，簡化數據包設計，提高代碼效率。存儲過程、函數必須有相應的出錯處理功能。
2.4.6 安全性設計
4.4.6.1 管理默認用戶
在生產環境中，必須嚴格管理 sys 和 system 用戶，必須修改其默認密碼，禁止用該用戶建立數據庫應用對象。刪除或鎖定數據庫測試用戶 scott 。
2.4.6.2 數據庫級用戶權限設計
必須按照應用需求，設計不同的用戶訪問權限。包括應用系統管理用戶，普通用戶等，按照業務需求建立不同的應用角色。
用戶訪問另外的用戶對象時，應該通過創建同義詞對象 synonym 進行訪問。
2.4.6.3 角色與權限
確定每個角色對數據庫表的操作權限，如創建、檢索、更新、刪除等。每個角色擁有剛好能夠完成任務的權限，不多也不少。在應用時再爲用戶分配角色，則每個用戶的權限等於他所兼角色的權限之和。
2.4.6.4 應用級用戶設計
應用級的用戶帳號密碼不能與數據庫相同，防止用戶直接操作數據庫。用戶只能用帳號登陸到應用軟件，通過應用軟件訪問數據庫，而沒有其它途徑操作數據庫。
2.4.6.5 用戶密碼管理
用戶帳號的密碼必須進行加密處理，確保在任何地方的查詢都不會出現密碼的明文。
2.5 SQL 編寫
2.5.1 字符類型數據
SQL 中的字符類型數據應該統一使用單引號。特別對純數字的字串，必須用單引號，否則會導致內部轉換而引起性能問題或索引失效問題。利用 trim(),lower() 等函數格式化匹配條件。
2.5.2 複雜 sql
對於非常複雜的 sql( 特別是有多層嵌套，帶子句或相關查詢的 ) ，應該先考慮是否設計不當引起的。對於一些複雜 SQL 可以考慮使用程序實現。
USER_TAB_COMMENTS 數據字典
Comment on 可加註解
2.5.3 高效性
2.5.3.1 避免 In 子句
使用 In 或 not In 子句時，特別是當子句中有多個值時，且查詢數據表數據較多時，速度會明顯下降。可以採用連接查詢或外連接查詢來提高性能。
Char 比 varchar 查詢時高詢
在進行查詢及建立索引時， char 比 varchar 的效率要高，當然 varchar 在存儲上比 char 要好
2.5.3.2 避免嵌套的 Select 子句
這個實際上是 In 子句的特例。
2.5.3.3 避免使用 Select * 語句
如果不是必要取出所有數據，不要用 * 來代替，應給出字段列表，注：不含 select count(*) 。
2.5.3.4 避免不必要的排序
不必要的數據排序大大的降低系統性能。
2.5.4 健壯性
2.5.4.1 Insert 語句
使用 Insert 語句一定要給出要插入值的字段列表，這樣即使更改了表結構加了字段也不會影響現有系統的運行。
2.5.4.2 Count(*) 、 Count(*) 、 count(distinct id) 的區別
Select count(*) from testtab
得到表 testtab 的記錄數
select count(id) from testtab
得到表 testtab id 字段非空記錄數
select count(distinct id) from testtab
得到表 testtab id 字段值非相同記錄數
2.5.4.3 Not null 爲字段類型性質的約束
本約束功能在後期無語法使期失效，可使用修改字段類型方式
alter table modify 字段名 類型 not null
alter table modify 字段名 類型
2.5.4.4 外鍵值可用 null 的問題
外鍵列如沒有明確說明 not null ，可插入 null 記錄（而 null 是在外部表的記錄中沒有的），如無可插 null 記錄的想法，要對外鍵字段加 not null 約束。
2.5.4.5 序列 sequence 跳號的問題
sequence 因回滾，系統崩潰（使用 cache 內的值將認爲已用），多表引用都將使其跳號，所以不能用於爲連續序號 utl_row.cast_to_row
2.5.4.6 unicn\ intersect\ minus 使用 ordey by 的注意事項
以上語句進行連表操作，而表同表的字段順序的類型相同但字段標題名可不同，使用 ordey by 時後面如果是字段名，要求所有的表的字段標題名相同，否則用字段的順序號
2.5.5 安全性
2.5.5.1 Where 條件
無論在使用 Select, 還是使用破壞力極大的 Update 和 Delete 語句時，一定要檢查 Where 條件判斷的完整性，不要在運行時出現數據的重大丟失。如果不確定，最好先用 Select 語句帶上相同條件來果一下結果集，來檢驗條件是否正確。
2.5.6 完整性
有依賴關係的表，例如主外鍵關係表，在刪除父表時必須級聯刪除其子表相應數據，或則按照某種業務規則轉移該數據。 9I 中表中字段縮小及變類型，字段爲空或表空， varchar 和 char 長度不變可任意改，字段名和表名可字段可用 ALTER TABLE table SET UNUSED (column) 設定爲不可用，注意無命令再設爲可用
3 備份恢復設計原則
3.1 數據庫 exp/imp 備份恢復
Oracle 數據庫的 Exp 、 Imp 提供了數據快速的備份和恢復手段，提供了數據庫級、用戶級和表級的數據備份恢復方式。這種方法一般作爲數據庫輔助備份手段。
3.1.1 數據庫級備份原則
在數據庫的數據量比較小，或數據庫初始建立的情況下采用。不適合 7*24 的在線生產環境數據庫備份。
3.1.2 用戶級備份原則
在用戶對象表數據容量比較小、或則用戶對象初始建立的情況下使用。
3.1.3 表級備份原則
主要在以下場合採用的備份方式：
參數表備份
靜態表備份
分區表的分區備份。
3.2 數據庫冷備份原則
數據庫冷備份必須符合以下原則：
數據庫容量比較小。
數據庫允許關閉的情況。
3.3 Rman 備份恢復原則
這種方式適用於 7*24 環境下的聯機熱備份情形。
3.3.1 Catalog 數據庫
單獨建立備份恢復用的數據庫實例，儘可能與生產環境的數據庫分開，確保 catalog 與生產數據庫的網絡連接良好。在 9I 系統使用良好的備份策略以可，支持完全使用控制文件保存 catalog 信息，備份策略如下：
注意：對數據庫設定控制文件保存備份信息爲 365 天，具體語句如下。
3.3.2 Archive Log
設置 Archive Log 的位置，確保存儲介質有足夠的空間來保留指定時間內 archive log 的總量。建設定期對 RMAN 進行全備份，刪除冗餘歸檔日誌文件。
3.3.3 全備份策略
對於小容量數據庫，可以採用全備份策略。對於大容量數據庫，必須制定全備份策略方案，備份時對 archive log 進行轉儲，同時冷備份 catalog 數據庫。
3.3.4 增量備份策略
對於大容量數據庫，必須制定增量備份、累積備份和全備份的週期，備份時對 archive log 進行轉儲，同時冷備份 catalog 數據庫。
3.3.5 恢復原則
採用 Rman 腳本進行數據庫恢復。數據庫恢復有以下幾種：
3.3.5.1 局部恢復
主要用於恢復表空間、數據文件，一般不影響數據庫其他操作。
3.3.5.2 完全恢復
數據庫恢復到故障點，由 catalog 當前數據庫決定。
3.3.5.3 不完全恢復
恢復到數據庫的某一時間點或備份點。
恢復 catalog 數據庫。
恢復數據庫 control file 。
恢復到數據庫某一時間點。
重設日誌序列。
3.4 備用數據庫原則
數據庫系統在以下情況下可以考慮採用備用數據庫 data guard 原則：
數據庫容量適中。
數據庫嚴格要求 7*24 不間斷，或間斷時間要求控制在最小範圍內。
數據庫要求有異地備份冗餘。
3.5 一些小經驗
使用 oemc 的 oms 時，首選項要求是節點和數據庫分別加入系統用戶（如： administrator ）和數據庫 DBA 用戶 (system) 。節點的系統用戶必須有批處理作業登錄的權限
agent 不能啓動， lisnter 修改後都要手動刪除 oracle\ora9\network\agent 中的 *.q 文件
oracle\admin\my9i\bdump 中是用戶的出錯日誌
改變表的空間的方式 alter table hr.ssss move TABLESPACE example （要重建索引） ; 或用 imp 導入時，設定導入用戶只有某一表空間的使用權，無 RESOURCE 角色和 UNLIMITED TABLESPACE 權限
aleter system set log_checkpoint_to_alter=true ，後可報警文件發現 checkpoint 的起動和結束時間。