1 資料庫實體設計原則
1.1 資料庫環境配置原則
1.1.1 作業系統環境：
對于中小型資料庫系統，采用linux作業系統比較合适，對于資料庫備援要求負載均衡能力要求較高的系統，可以采用Oracle9i RAC的叢集資料庫的方法，叢集節點數範圍在2—64個。對于大型資料庫系統，可以采用Sun Solaris SPARC 64位小型機系統或HP 9000 系列小型機系統。RAD5 适合隻讀操作的資料庫，RAD1 适合OLTP資料庫
1.1.2 記憶體要求
對于linux作業系統下的資料庫,由于在正常情況下Oracle對SGA的管理能力不超過1.7G。是以總的實體記憶體在4G以下。SGA的大小為實體記憶體的50%—75%。對于64位的小型系統，Oracle資料庫對SGA的管理超過2G的限制，SGA設計在一個合适的範圍内：實體記憶體的50%—70%，當SGA過大的時候會導緻記憶體分頁，影響系統性能。
1.1.3 交換區設計
當實體記憶體在2G以下的情況下，交換分區swap為實體記憶體的3倍，當實體記憶體>2G的情況下，swap大小為實體記憶體的1—2倍。
1.1.4 其他環境變量參考Oracle相關的安裝文檔和随機文檔。
1.2 資料庫設計原則
1.2.1 資料庫SID
資料庫SID是唯一标志資料庫的符号，命名長度不能超過5個字元。對于單節點資料庫，以字元開頭的5個長度以内字串作為SID的命名。對于叢集資料庫，當命名SID後，各節點SID自動命名為SIDnn，其中nn為節點号：1，2，…,64。例如rac1、rac2、rac24。
1.2.2 資料庫全局名
資料庫全局名稱：
<sid>.domain
1.2.3 資料庫類型選擇
對于海量資料庫系統，采用data warehouse的類型。對于小型資料庫或OLTP類型的資料庫，采用Transaction Processing類型。
1.2.4 資料庫連接配接類型選擇
Oracle資料庫有專用伺服器連接配接類型和多線程伺服器MTS連接配接類型。對于批處理服務，需要專用伺服器連接配接方式，而對于OLTP服務則MTS的連接配接方式比較合适。由于采用MTS後，可以通過配置網絡服務實作某些特定批處理服務采用專用伺服器連接配接方式，是以資料庫設計時一般采用MTS類型。
1.2.5 資料庫SGA配置
資料庫SGA可以采用手工配置或按實體記憶體比例配置，在資料庫初始設計階段采用按比例配置方式，在實際應用中按系統調優方式修改SGA。
1.2.6 資料庫字元集選擇
為了使資料庫能夠正确支援多國語言，必須配置合适的資料庫字元集，采用UTF8字元集。
注意：如果沒有大對象，在使用過程中進行語言轉換沒有什麼影響，具體過程如下（切記設定的字元集必須是ORACLE支援，不然不能start）
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter system enable restricted session;
SQL> alter system set job_queue_processes=0;
SQL> alter database open;
SQL> alter database character set internal_use we8iso8859p1;
SQL> shutdown immediate;
SQL> startup
1.2.7 資料庫其他參數配置
1.2.7.1 DB_FILES
Db_files是資料庫能夠同時打開的檔案數量，預設值是200個。當資料庫規劃時檔案數量FILES接近或超過200個時候，按以下估計值配置:
DB_FILES = FILES * 1.5
1.2.7.2 Db_block_size
一個extent要是5個blocks的倍數為好，如：一個blocks是4096位元組，那一個extent就是2M、4M或8M為好。Db_block_size是資料庫最小實體單元，一旦資料庫建立完成，該參數無法修改，db_block_size按以下規則調整：
資料倉庫類型： db_block_size盡可能大，采用8192 或 16384
OLTP類型： db_block_size 用比較小的取值範圍： 2048 或 4096
Blocks推薦是系統操作的塊倍數（裸裝置塊大小是512位元組，NTFS是 4K，使用8K的方式在大部分系統上通用）。
1.2.8 資料庫控制檔案配置
1.2.8.1 控制檔案鏡象
多個控制檔案存放在不同的實體位置。
1.2.8.2 控制檔案配置
控制檔案中參數設定，最大的資料檔案數量不能小于資料庫參數db_files。
1.2.9 資料庫日志檔案配置
1.2.9.1 日志檔案大小
日志檔案的大小由資料庫事務處理量決定，在設計過程中，確定每20分鐘切換一個日志檔案。是以對于批處理系統，日志檔案大小為幾百M 到幾G的大小。對于OLTP系統，日志檔案大小為幾百M以内。
1.2.9.2 日志檔案組數量
對于批處理系統，日志檔案組為5—10組；對于OLTP系統，日志檔案組為 3—5組，每組日志大小保持一緻；對于叢集資料庫系統，每節點有各自獨立的日志組。
1.2.9.3 日志成員數量
為了確定日志能夠鏡象作用，每日志組的成員為2個。
1.2.10 資料庫復原段配置
在Oracle9i資料庫中，設計Undo表空間取代以前版本的復原段表空間。
Undo 表空間大小的設計規範由以下公式計算：
Undospace = UR * UPS *db_block_size+ 備援量
UR： 表示在undo中保持的最長時間數（秒），由資料庫參數UNDO_RETENTION值決定。
UPS：表示在undo中，每秒産生的資料庫塊數量。
例如：在資料庫中保留2小時的回退資料，假定每小時産生200個資料庫塊。則Undospace = 2 * 3600 * 200 * 4K = 5.8G
1.2.11 資料庫臨時段表空間配置
資料庫臨時段表空間根據實際生産環境情況調整其大小，表空間屬性為自動擴充。
1.2.12 資料庫系統表空間配置
系統表空間大小1G左右，除了存放資料庫資料字典的資料外，其他資料不得存儲在系統表空間。
1.3 資料庫表空間設計原則
1.3.1 表空間大小定義原則
當表空間 大小小于作業系統對最大檔案限制時，表空間由一個檔案組成。如果表空間大小大于作業系統對最大檔案限制時，該表空間由多個資料檔案組成，表空間的總大小為估算為：
Tablespace + sum (資料段+索引段)*150%。
1.3.2 表空間擴充性設計原則
表空間資料檔案采用自動擴充的方式，擴充容量快大小按2的整數倍（1M、2M、4M、8M、16M、32M、64M）進行擴充，建立表空間時盡量采用nologing選項。表空間的最大限制一般采用unlimited，除非确切知道表空間資料檔案的最大使用範圍。（一般windows ３２位系統的檔案最大２Ｇ，６４位的unix系統系統檔案最大１２８G,但也要注意檔案格式設定的檔案大小）,建議最大為2G。表空間采用local管理方式，例如：
CREATE TABLESPACE TBS_USERINFO
DATAFILE
'/oradata/tbs_userinfo.dbf'
SIZE 8M
REUSE
AUTOEXTEND ON
NEXT 2M
MAXSIZE UNLIMITED
NOLOGGING
EXTENT MANAGEMENT
LOCAL
AUTOALLOCATE
SEGMENT SPACE MANAGEMENT AUTO;
1.4 裸裝置的使用
一個scsi裝置可以 14個分區，unix作業系統256個分區,性能比檔案系統方式高15％左右，空間大于要小于(實際分區大小減兩個ORACLE的資料塊)，比如100M，大于為100000K，推薦在unix使用軟連接配接(ln)方式把裸裝置形成檔案，用加入表空間時加resue 選項，當然也可隻接把裝置加入表空間，移動裸裝置使用dd指令
對于windows平台，oracle提供軟連接配接工具，實作裸裝置的使用，計算一條記錄的長度
2 資料庫邏輯設計原則
2.1 命名規範
2.1.1 表屬性規範
2.1.1.1 表名
字首為Tbl_ 。資料表名稱必須以有特征含義的單詞或縮寫組成，中間可以用“_”分割，例如：tbl_pstn_detail。表名稱不能用雙引号包含。
2.1.1.2 表分區名
字首為p 。分區名必須有特定含義的單詞或字串。
例如 ：tbl_pstn_detail 的分區p2004100101表示該分區存儲 2004100101時段的資料。
2.1.1.3 字段名
字段名稱必須用字母開頭，采用有特征含義的單詞或縮寫，不能用雙引号包含。
2.1.1.4 主鍵名
字首為PK_。主鍵名稱應是 字首+表名+構成的字段名。如果複合主鍵的構成字段較多，則隻包含第一個字段。表名可以去掉字首。
2.1.1.5 外鍵名
字首為FK_。外鍵名稱應是 字首+ 外鍵表名 + 主鍵表名 + 外鍵表構成的字段名。表名可以去掉字首。
2.1.2 索引
4.1.2.1 普通索引
字首為IDX_。索引名稱應是 字首+表名+構成的字段名。如果複合索引的構成字段較多，則隻包含第一個字段，并添加序号。表名可以去掉字首。
2.1.2.2 主鍵索引
字首為IDX_PK_。索引名稱應是 字首+表名+構成的主鍵字段名，在建立表時候用using index指定主鍵索引屬性。
2.1.2.3 唯一是以
字首為IDX_UK_。索引名稱應是 字首+表名+構成的字段名。
2.1.2.4 外鍵索引
字首為IDX_FK_。索引名稱應是 字首+表名+構成的外鍵字段名。
2.1.2.5 函數索引
字首為IDX_func_。索引名稱應是 字首+表名+構成的特征表達字元。
2.1.2.6 蔟索引
字首為IDX_clu_。索引名稱應是 字首+表名+構成的簇字段。
2.1.3 視圖
字首為V_。按業務操作命名視圖。
2.1.4 實體化視圖
字首為MV_。按業務操作命名實體化視圖。
2.1.5 存儲過程
字首為Proc_ 。按業務操作命名存儲過程
2.1.6 觸發器
字首為Trig_ 。觸發器名應是 字首 + 表名 + 觸發器名。
2.1.7 函數
字首為Func_ 。按業務操作命名函數
2.1.8 資料包
字首為Pkg_ 。按業務操作集合命名資料包。
2.1.9 序列
字首為Seq_ 。按業務屬性命名。
2.1.10 表空間
2.1.10.1 公用表空間
字首為Tbs_ 。 根據存儲的特性命名，例如： tbs_parameter 。
2.1.10.2 專用表空間
Tbs_<表名稱>_nn。該表空間專門存儲指定的某一個表，或某一表的若幹個分區的資料
2.1.11 資料檔案
<表空間名>nn.dbf 。nn =1，2，3，4，…等。
2.1.12 普通變量
字首為Var_ 。 存放字元、數字、日期型變量。
2.1.13 遊标變量
字首為Cur_ 。存放遊标記錄集。
2.1.14 記錄型變量
字首為Rec_ 。 存放記錄型資料。
2.1.15 表類型變量
字首為Tab_ 。 存放表類型資料。
2.1.16 資料庫鍊
字首為dbl_ 。 表示分布式資料庫外部連結關系。
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時後面如果是字段名，要求所有的表的字段标題名相同，否則用字段的順序号
select id,name,year from user1
union
select no,name,to_number(null) year from user2
order by 1,name,year
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資訊，備份政策如下：
backup spfile format '/data/backup/%d_SPFILE_%T_%s_%p.bak';
sql "alter system archive log current";
backup archivelog all format '/data/backup/%d_ARC_%T_%s_%p.bak' delete all input;
backup current controlfile format '/data/backup/%d_CTL_%T_%s_%p.bak';
在spfile、控制檔案、資料庫全丢的情況下可通過下面的方式恢複
RMAN> connect target
connected to target database (not started)
RMAN> startup
RMAN> restore spfile from '/data/backup/COMMDB_SPFILE_20030411_9_1.bak';
SQL> startup
ORA-00205: error in identifying controlfile, check alert log for more info
RMAN> restore controlfile from 'd:/DB92_CTL_20031113_9_1.BAK';
Mout database:
RMAN> recover database;
RMAN> alter database open resetlogs;
注意：對資料庫設定控制檔案儲存備份資訊為365天，具體語句如下。
alter system set control_file_record_keep_time=365 SCOPE=BOTH;
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的起動和結束時間。
3.6 系統調優知識
3.6.1.1 生成狀态報表（statspack的使用）
使用（存放位置@?/rdbms/admin/）的檔案生成報表使用者
@?/rdbms/admin/Spcreate.sql建表
将timed_statistics設定true
使用生成的perfstat使用者登入，執行以下語句手動收集資訊
Exex statspack.snap
Exec statspack.snap(I_SNAP_LEVEL=>0,I_MODEFY_PRAMETER=>TRUE) 0級，最少10最大
使用下面的語句生成狀态報表
@?/rdbms/admin/Spreport.sql
其他相關檔案
delete stats$snapshot ;清原來記錄資料
@?/rdbms/admin/Saputo.sql
select job from user_jobs 取使用者作業号
exec dbms_remove(作業号)
timed_statistics=true要求
@?/rdbms/admin/spdrop.sql ;
3.6.1.2 sql追蹤
設定全部使用者跟蹤
alter system set sql_trace=true;
使用者級别跟蹤
alter session set sql_trace=true;
使用者的跟蹤檔案生成在 admin/{pid}/udump/{pid} _ora_{ SPID}.trc 中,spid從下面語句得到
SELECT b.name bkpr, s.username, p.spid,s.sid,s.serial# FROM v$bgprocess b, v$session s, v$process p WHERE p.addr = b.paddr(+) AND p.addr = s.paddr and s.username=user;
DBA對特定使用者跟蹤
exec dbms_system_set_Sql_trace_in_session(sid,serial#,true)
資訊從下面得到
SELECT b.name bkpr, s.username, p.spid,s.sid,s.serial#,osuser,s.program
FROM v$bgprocess b, v$session s, v$process p
WHERE p.addr = b.paddr(+)
AND p.addr = s.paddr;
使用者的跟蹤檔案生成在 admin/{pid}/udump 中
系統的跟蹤檔案生成在admin/{pid}/bdump/alert_{pid}.log
tkprof.exe将log檔案生成格式化文本
在av Rd(ms) 20以上說明表空間使用過用頻繁，考慮将表分開其他表空間上
系統變量fast_start_mttr_target的值要大到不産生log等待，當然也可通過加log組使其不等待
reao log大小應為每30分鐘切換一次
建議表空間的使用率不超80%
buffer hit 要達80%以上為好
3.6.1.3 記憶體調整
一般的記憶體配置設定原則
SGA 50%（其中80% DATA BUFFER，15% SHARE POOL，5其他）
PGA30%
OS 20%
例如：2G的WINDOWS的平台，OS 300M，SAG 1.2G,PGA 500M
記憶體配置設定的基本機關
ＳＧＡ《＝１２８Ｍ ４Ｍ
ＳＧＡ》１２８Ｍ ６４位系統１６Ｍ，３２Ｍ系統８Ｍ
動态配置設定時總值不可大于sga_max_size
通過V$SGA_DYNAMIC_FREE_MEMORY取空閑記憶體空間
在縮小時如果記憶體空間實際在應用中，ＣＰＵ使用率将達１００％，最後将語句出錯。
V$SGASTAT 可看實際的使用情況
Redo log buffer一般在５Ｍ内，可通過v$sessuon_wait看是否等，v$sysstat
可也通過報警檔案看是否等切換，方法可加組。可通過nologging（資料庫也要設定支援nologging）方法減少日志檔案産生量。
java_pool 沒有設定時，使用shared_pool_size
3.6.1.3.1 shared_pool
本緩沖區用于sql語句，pl sql等的對象儲存
Cursor_sharing{Exact|Similar|force} 遊标共享設定
Force方式适用OLTP資料庫，Exact方式适合資料倉庫，similar為智能方式
hard parses 硬SQL語句分析，每秒要底于100次,小要加大shared_pool
soft parse 軟SQL語句分析，OLTP要達90%以上，小要加大shared_pool
不建議用無命名PL SQL段
如果有大PL SQL(存儲過程)對象可強制儲存于記憶體，也可加大SHARED_POOL_RESERVED_SIZE，大小不可過SHARED_POOL_SIZE的50%，不然執行個體不能起動
3.6.1.3.2 db_cache
本緩沖區用于資料庫資料對象儲存
db_cache_advice 為on，可以提出通過企業管理器看到系統建議
通過select * from v$system_event 進行系統檢視。
發現存在free buffer waits，說明不能将data buffer及時寫入data file;
可通過增加加CPU後，加db_writer_processes=CPU數改善。
也可設disk_asynch_io為true,使用異步IO（前提同要作業系統支援）db_writer_processes=1時（隻有一個CPU的情況下），也可通加大dbwr_io_slaves來改善。db_writer_processes>1,不可用本功能
調整效果排序：異步IO>CPU>dbwr_io_slaves
Buffer Busy Waits大說明出現IO沖突
Buffer Busy Waits 大 和 dbbock大說明全表掃描多，說明資料不能讀入，可加大
db_cache_size來改善.
Undo block大要加大復原段（手動管理方式，９Ｉ預設是自動管理）
undo header 大要加大復原段（手動管理方式，９Ｉ預設是自動管理）
db_cache命中率99%，不是唯一因素，關系是不要出現等待。建議達90%以上。
記憶體使用建議：
系統可以設三個緩沖區，建表時可設定用那個緩沖區（預設在db_cache_size）
db_cache_size （預設區）
db_keep_cache_size （常通路，小于db_keep_cache_size的10%的表可放于本區）
db_recycle_cache_size （一個事物完成後常時間不再使用，或兩倍大小于緩沖區）
3.6.2 排序的優化
9I為專用伺服器時系統變量workarea_size_policy 設定為auto, statistics_level設定為 TYPICAL 可擷取v$pga_target_advice中的優化建議。參數pga_aggregate_target值為所有連接配接使用者可用排序記憶體。
9I為共享伺服器時workarea_size_policy設定為menaul, sort_area_size值為每使用者排序記憶體。
如果記憶體不足将使用TEMP表空間進行排序,排序使用比率disk/meme應小于5%
盡量少用排序,如果使用排序功能，盡量在字段上加索引進行優化。
SQL分析模式:RBO(基于規則)方案小表(驅動表)放在最後,優先使用索引,對SQL語句要求嚴格(8I以前的模式);CBO （基于開銷）根據統計值進行選擇開銷最少,性能最優的最佳方式進行,但本方式DBA(使用analyze table語句)要定期進行分析統計.系統設定通過optimizer_mode 系統參數
說明: 指定優化程式的行為。如果設定為 RULE, 就會使用基于規則的優化程式, 除非查詢含有提示。如果設定為 CHOOSE, 就會使用基于成本的優化程式, 除非語句中的表不包含統計資訊。ALL_ROWS 或 FIRST_ROWS
始終使用基于成本的優化程式。
值範圍: RULE | CHOOSE | FIRST_ROWS | ALL_ROWS
預設值: CHOOSE
｛rule（RBO）|choose（自動選擇）|fist_rows| fist_rows_n|all_row｝
3.6.3 統計資訊
進行某表的統計分析
EXECUTE dbms_stats.gather_table_stats ('HR','EMPLOYEES');
檢視結果
SELECT num_rows, blocks, empty_blocks as empty,
avg_space, chain_cnt, avg_row_len
FROM dba_tables
WHERE owner = 'HR'
AND table_name = 'EMPLOYEES';
4 設計工具
統一使用sybase power designer設計工具，在該工具上完成實體模型的設計。所有的資料庫對象盡可能在實體模型上進行設計，而且每個實體模型都要有相應的文字描述。
所有的資料庫對象變更以資料庫實體模型為基準。為了避免字元敏感問題，産生的腳本以大寫字母為标準。
![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)