NOARCHIVELOG 模式
缺省情況下，數據庫是以NOARCHIVELOG 模式創建的。

1.在NOARCHIVELOG 模式下操作數據庫時有以下特性：
(1)重做日志文件以循環的方式使用。
(2)重做日志文件可以在檢查點發生之后立即重新使用。
(3)重做日志被覆蓋后，介質恢復將只能恢復到上一次完全備份。

2.NOARCHIVELOG 模式的含義
(1)如果某個表空間由于故障而不可用，將無法繼續對數據庫進行操作，除非刪除了該表空間或從備份還原了整個數據庫。
(2)只能在數據庫關閉時對數據庫執行操作系統備份。而且，必須使用NORMAL、IMMEDIATE 或TRANSACTIONAL 選項關閉數據庫。
(3)必須在每次備份時完整備份所有的數據文件和控制文件。盡管也可以備份聯機重做日志文件，但這是不必要的。由于此類備份中日志文件是一致的，無需恢復，因此，不需要備份聯機日志。
(4)如果聯機重做日志文件已被覆蓋，則將丟失上次完全備份后的所有數據。

3.NOARCHIVELOG 模式下的介質恢復選項
必須從數據庫的完全備份中還原數據文件和控制文件。如果使用導出實用程序來備份數
據庫，則可使用導入實用程序還原丟失的數據。但是，通過這種方法恢復的數據并不完
整，在導出后執行的事務處理工作將丟失。

ARCHIVELOG 模式
在發生檢查點并且已經通過ARCn 后臺進程備份重做日志文件之前，不能重新使用填滿的重做日志文件。控制文件中將有一個條目記錄歸檔日志文件的日志序列號。
對數據庫的最新更改在任何時候均可用于例程恢復，而歸檔重做日志文件可以用于介質恢復。

1.歸檔要求
(1)數據庫必須處于ARCHIVELOG 模式。通過發出命令將數據庫置于ARCHIVELOG 模式可以更新控制文件。可以啟用ARCn 后臺進程來實現自動歸檔。
(2)應該有足夠的資源來存放生成的歸檔重做日志文件。

2.將數據庫設置為ARCHIVELOG 模式的含義
(1)出現介質故障時，可以防止數據庫丟失數據。
(2)可以在數據庫聯機時對其進行備份。
(3)由于介質故障導致表空間（非SYSTEM）脫機時，數據庫的其余部分仍可用，因為表空間（非SYSTEM）可以在數據庫打開時恢復。

3.介質恢復選項
(1)無論數據庫處于聯機或脫機狀態，都可以還原損壞文件的備份副本，并使用歸檔日志文件將數據文件更新為當前的版本。
(2)可以將數據庫恢復至特定的時間點。
(3)可以將數據庫恢復至指定歸檔日志文件的末尾。
(4)可以將數據庫恢復至特定的系統更改號(SCN)。

4.在設置歸檔日志模式時，應該考慮以下因素：
下述情況中，NOARCHIVELOG 模式可能比較合適：
 (1)容許備份之間的數據損失（在開發、培訓期間等）
 (2)重新應用事務處理（從批處理文件）的速度更快
 (3)數據極少更改（非OLTP）
下述情況中，ARCHIVELOG 模式則更合適：
 (1)無法關閉數據庫以執行關閉的數據庫的備份
 (2)不允許數據損失
 (3) 使用歸檔重做日志文件比重新應用事務處理(OLTP) 更易于恢復

RAID 0+ 1
優點：
正常使用中,考慮性能上講,RAID0+1 好,就是先做RAID 0 條帶,再做 RAID 1 MIRROR,這樣寫入速度快,讀的速度和RAID1＋0一樣.
缺點,一旦一個硬盤壞了,一半的硬盤無法工作,如果1個條帶上各壞1個硬盤（RAID0+1只有2個條帶）,GAME OVER....即使是只有一個硬盤壞了,做數據恢復也很慢,因為一半的硬盤要rebuild（大家該知道為什么吧）.

RAID 1+0
優點 數據安全性好,只要不是1個條帶上的2個硬盤同時壞,沒有問題,還可以繼續跑數據.數據恢復快.
缺點 寫性能稍微比RAID 0+1 差（讀性能一樣）

這里舉個例子,20個硬盤
做RAID 0＋1,共2個條帶做MIRROR,每個條帶10個硬盤,如果壞了1個硬盤,只能是另外一個完好的條帶（10個硬盤）同時工作,這邊條帶9個好的硬盤也要休息.

做RAID 1＋0,共10個條帶,每個條帶2個硬盤做MIRROR,如果壞了1個硬盤,沒關系,其它19個硬盤還要同時工作,只要不是壞在一個MIRROR里面的,沒事.

建議,硬盤很多時,同時壞的幾率就比較大,建議使用安全系數高的RAID 1+0,寧愿損失點性能（其實差不多).
如果僅僅是4塊硬盤或者不考慮安全,不是關鍵業務,只是為了追求速度快感,你可以選擇RAID 0+1

RAID是通過磁盤陣列與數據條塊化方法相結合,以提高數據可用率的一種結構.IBM早于1970年就開始研究此項技術.RAID 可分為RAID級別1到RAID級別6, 通常稱為:RAID 0, RAID 1, RAID 2, RAID 3,RAID 4, RAID 5,RAID6.每一個RAID級別都有自己的強項和弱項. "奇偶校驗"定義為用戶數據的冗余信息, 當硬盤失效時,可以重新產生數據.

RAID 0: RAID 0 并不是真正的RAID結構, 沒有數據冗余. RAID 0 連續地分割數據并并行地讀/寫于多個磁盤上. 因此具有很高的數據傳輸率. 但RAID 0在提高性能的同時,并沒有提供數據可靠性,如果一個磁盤失效,將影響整個數據.因此RAID 0 不可應用于需要數據高可用性的關鍵應用.
RAID 1: RAID 1通過數據鏡像實現數據冗余,在兩對分離的磁盤上產生互為備份的數據. RAID 1可以提高讀的性能, 當原始數據繁忙時,可直接從鏡像拷貝中讀取數據.RAID 1是磁盤陣列中費用最高的, 但提供了最高的數據可用率. 當一個磁盤失效,系統可以自動地交換到鏡像磁盤上, 而不需要重組失效的數據.
RAID 2: 從概念上講, RAID 2 同RAID 3類似, 兩者都是將數據條塊化分布于不同的硬盤上, 條塊單位為位或字節.然而RAID 2 使用稱為"加重平均糾錯碼"的編碼技術來提供錯誤檢查及恢復.這種編碼技術需要多個磁盤存放檢查及恢復信息, 使得RAID 2技術實施更復雜.因此,在商業環境中很少使用.
RAID 3: 不同于RAID 2, RAID 3使用單塊磁盤存放奇偶校驗信息. 如果一塊磁盤失效, 奇偶盤及其他數據盤可以重新產生數據. 如果奇偶盤失效,則不影響數據使用.RAID 3對于大量的連續數據可提供很好的傳輸率, 但對于隨機數據, 奇偶盤會成為寫操作的瓶頸.
RAID 4: 同RAID 2, RAID 3一樣, RAID 4, RAID 5也同樣將數據條塊化并分布于不同的磁盤上, 但條塊單位為塊或記錄. RAID 4使用一塊磁盤作為奇偶校驗盤, 每次寫操作都需要訪問奇偶盤, 成為寫操作的瓶頸. 在商業應用中很少使用.
RAID 5: RAID 5沒有單獨指定的奇偶盤, 而是交叉地存取數據及奇偶校驗信息于所有磁盤上.在RAID5 上, 讀/寫指針可同時對陣列設備進行操作, 提供了更高的數據流量.RAID 5更適合于小數據塊, 隨機讀寫的數據.RAID 3 與RAID 5相比, 重要的區別在于RAID 3每進行一次數據傳輸,需涉及到所有的陣列盤.而對于RAID 5來說, 大部分數據傳輸只對一塊磁盤操作, 可進行并行操作.在RAID 5中有"寫損失", 即每一次寫操作,將產生四個實際的讀/寫操作, 其中兩次讀舊的數據及奇偶信息, 兩次寫新的數據及奇偶信息.
RAID 6: RAID 6 與RAID 5相比,增加了第二個獨立的奇偶校驗信息塊. 兩個獨立的奇偶系統使用不同的算法, 數據的可靠性非常高.即使兩塊磁盤同時失效,也不會影響數據的使用.但需要分配給奇偶校驗信息更大的磁盤空間, 相對于RAID 5有更大的"寫損失".RAID 6 的寫性能非常差, 較差的性能和復雜的實施使得RAID 6很少使用.

這個類型支持前后滾動取得紀錄next（）、previous()，回到第一行first()，同時還支持要去的ResultSet中的第幾行absolute（int n），以及移動到相對當前行的第幾行relative(int n)，要實現這樣的ResultSet在創建Statement時用如下的方法。
Statement st = conn.createStatement(int resultSetType, int resultSetConcurrency)
ResultSet rs = st.executeQuery(sqlStr)
其中兩個參數的意義是：
resultSetType是設置ResultSet對象的類型可滾動，或者是不可滾動。取值如下：
ResultSet.TYPE_FORWARD_ONLY只能向前滾動
ResultSet.TYPE_SCROLL_INSENSITIVE和Result.TYPE_SCROLL_SENSITIVE這兩個方法都能夠實現任意的前后滾動，使用各種移動的ResultSet指針的方法。二者的區別在于前者對于修改不敏感，而后者對于修改敏感。
resultSetConcurency是設置ResultSet對象能夠修改的，取值如下：
ResultSet.CONCUR_READ_ONLY 設置為只讀類型的參數。
ResultSet.CONCUR_UPDATABLE 設置為可修改類型的參數。
所以如果只是想要可以滾動的類型的Result只要把Statement如下賦值就行了。
Statement st = conn.createStatement(Result.TYPE_SCROLL_INSENITIVE,
ResultSet.CONCUR_READ_ONLY);
ResultSet rs = st.excuteQuery(sqlStr)；

一些常用的動態性能試圖
1.先來張總的

實例級別統計

上面兩個框是系統統計信息，包括了一些性能指標，有STAT關鍵字
下面兩個框是事件統計信息，有EVENT關鍵字，包括了各種不同類型的等待事件信息

3.會話級別統計

上面三個框是會話的系統統計信息，包括了一些性能指標，有STAT關鍵字。
下面三個框是會話的事件統計信息，包括了該會話各種不同類型的等待事件信息，有EVENT或WAIT關鍵字。

4.這些事件都列在V$EVENT_NAME視圖中，擁有以下字段：
EVENT#
事件號
NAME
事件名
PARAMETER1
第一個參數名
PARAMETER2
第二個參數名
PARAMETER3
第三個參數名

5.事件統計信息
V$SYSTEM_EVENT: 所有會話對一個事件的總等待，它是累計信息。
V$SESSION_EVENT: 每個會話對一個事件的總等待，它是累計信息。
V$SESSION_WAIT:正在等待的當前活動對一個事件的等待，它是實時狀態。

6.V$SYSTEM_EVENT:整個實例某個特定等待事件的統計值


7.V$SESSION_EVENT: 

某個會話特定等待事件的統計值

8. V$SESSION_WAIT :當前會話正在等待的事件及統計信息,我們通過它能準確的發現當前性能問題的現象是什么

WAIT_TIME
非0:最近一次等待的時間, (當STATE為waited known time,單位為厘秒)
0:當前正在等待

STATE
waiting:
正在等待中,該狀態,通常seconds_in_wait會有值
waited known time:
現在已經不等待了,但提供了詳細的等待信息
waited short time:
現在已經不等待了,但提供了簡短的等待信息

select * from v$sysstat t where t.name ='CPU used by this session';

Service Time = SQL解析時間 + 遞歸調用時間 + 其他時間

1.視圖的使用
--實例級系統性能視圖:v$sysstat
使用:(以CPU used by this session為例)

select * from v$sysstat t where t.name ='CPU used by this session';

--會話級系統性能試圖:

select a.STATISTIC# from v$statname a  where a.NAME like '%CPU used by this session%';

找到STATISTIC#,代入到下面
--當前所有session的

select * from v$sesstat b where b.STATISTIC# = &STATISTIC#;

--自己的session的

select * from v$mystat c where c.STATISTIC# = &STATISTIC#;

--或者直接

select b.sid, a.STATISTIC#, a.name, b.value
  from v$statname a, v$mystat b
 where a.STATISTIC# = b.STATISTIC#;
 and a.name like '%xxxxxxx%'

2.sql解析時間(sql解析過程..比較重要,后面專門寫一篇)

  select name, sid, value "Total parse Cpu time"
          from v$statname a, v$mystat b
         where a.name like '%parse%'
           and a.statistic# = b.statistic#

3.遞歸調用時間是用在語義分析階段查找數據字典或者PLSQL內部包造成的解析所花的CPU時間

select * from v$statname a  where a.NAME like '%recursive cpu%';

實例級和會話級查詢方法同上

4.其它CPU時間:通常占絕大多數，它是執行內存BUFFER搜索，索引和全表掃描涉及的IO操作所占有的CPU

select a.VALUE as "Total CPU",
       b.VALUE as "Parse CPU",
       c.VALUE as "Recursive CPU",
       a.VALUE - b.VALUE - c.VALUE as "Others"
  from v$sysstat a, v$sysstat b, v$sysstat c
 where a.NAME = 'CPU used by this session'
   and b.NAME = 'parse time cpu'
   and c.NAME = 'recursive cpu usage';

5.等待常是由于并發，需要等待別的會話處理完獨占的資源后所花的時間，這通常也是最常見的性能問題.
如果等待時間（wait time）占響應時間(Pesponse time)的大多數時，我們需要減小等待時間來提高系統性能。我們需要剝離等待時間來分析和優化等待時間

   select d.EVENT, d.TIME_WAITED, d.AVERAGE_WAIT
     from v$system_event d
    where d.EVENT not in
          ('pmon timer', 'rdbms ipc message', 'smon timer',
           'virtual circuit status', 'SQL*Net message from client')

not in 里面的event通常被認為是不會產生等待的事件

三.相關視圖
1.v$sysstat
這個使徒列出系統統計數據.為找到與每個統計數據號(STATISTIC#)關聯的統計數據
名稱，請參閱V$STATNAME.
列 數據類型 說明
STATISTIC# NUMBER 統計數據號
NAME VARCHAR2 統計數據名
CLASS NUMBER 統計數據類別:1(用戶);2(重做);
4(排隊);8(高速緩存);16(操
作系統);32(并行服務器);64
(SQL);128(調試)
VALUE NUMBER 統計數據值
CLASS NUMBER 統計數據類別:

2.v$sesstat
這個視圖給出用戶會話的統計數據.為了找到與每個統計數據號(STATISTIC#)有關的
統計數據名稱，請參閱V$STATNAME.
列 數據類型 說明
SID NUMBER 會話標識符
STATISTIC# NUMBER 統計數據名(標識符)
VALUE NUMBER 統計數據值

3.v$mystat
這個視圖包含當前會話的統計數據。
列 數據類型 說明
SID NUMBER 當前會話的ID
STATISTIC NUMBER 統計數據號
VALUE NUMBER 統計數據值

4.v$statname
這個視圖顯示列在V$SESSTAT 和V$SYSSTAT 表中的統計數據的解碼統計數據名。詳細信
息，請參閱V$SESSTAT 和SYSSTAT。
列 數據類型 說明
STATISTIC# NUMBER 統計數據號
NAME VARCHAR2 統計數據名。參見表B-13
CLASS NUMBER 1(用戶);2(重做);4(排
隊);8（高速緩存);16(操
作系統);32(并行服務器);
128(調試)