基於Linux的oracle 12cR2 RAC 標準化安裝（四）

安裝最新  PSU  版本

參看Quick Reference to Patch Numbers for Database PSU, SPU(CPU), Bundle Patches and Patchsets (  文件 ID 1454618.1)  文件，下載目前基於GI  的最新版本的PSU

                                             

根據文件下載最新的GI PSU  並安裝文件內容安裝最新的PSU  。

 

建立資料磁碟組

grid  使用者執行：

開啟Xmanager-passice

export DISPLAY=xxx.xxx.xxx.xxx:0.0(xxx.xxx.xxx.xxx  為操作機器的IP 0.0  為xxmanager  的埠)

grid  使用者執行asmca

asmca

 

 

 

下一步：建立DATA  磁碟組

輸入磁碟組名：DATA

選擇冗餘方式為  Extenal

如果未發現磁碟，選擇右下角Change Ddisk Discovery Path  修改磁碟發現路徑

編輯Database Compatibility  為12.2.0.0.0  （修改後12.2  之前資料庫將無法使用此磁碟組）

勾選需要建立磁碟組的磁碟

 

下一步：建立磁碟組

下一步：磁碟組建立成功

 

建立例項

執行命令

Oracle  使用者執行dbca  命令：

export DISPLAY=xxx.xxx.xxx.xxx:0.0(xxx.xxx.xxx.xxx  為操作機器的IP 0.0  為xxmanager  的埠)

$dbca

 

安裝截圖

選擇高階配置：

 

下一步：選擇建立叢集型別資料庫，並選擇資料庫型別

選擇節點

下一步：填寫例項名字，以及可選的cdb  引數

下一步：選擇資料存放的磁碟組，

下一步，快速恢復區和歸檔選項，可以不選，事後可新增

可不選  oracle vault  選項

 

記憶體配置

Process  配置

字符集設定

EM  設定（不建議此處配置）

下一步：輸入使用者密碼

選擇建立資料庫選項

預先的環境檢查

以上報錯可以忽略

下一步概要資訊

資料庫建立中

資料庫建立完成

安裝結束

引數最佳化

運維部分

密碼過期時間  ，從  11g  開始，  oracle  對資料庫所有密碼預設過期時間  180  天：

SQL> alter profile default limit  PASSWORD_LIFE_TIME unlimited;

 

密碼登陸錯誤次數  ，  對於輸入錯誤密碼導致資料庫賬號被鎖定  ：

SQL> alter profile default limit  FAILED_LOGIN_ATTEMPTS unlimited;

 

密碼大小寫敏感  ，該引數預設值是TRUE  ，因此，預設情況下密碼大小寫是敏感的

SQL> alter system set SEC_CASE_SENSITIVE_LOGON=false;

 

審計策略

Oracle  的審計從11g  開始，預設為開啟，在12c  中依然建議關閉：

SQL> alter system set audit_trail=none scope=spfile sid='*';

 

關閉延遲段建立

從  11.2  開始，這個值的預設值是  true  ，建議  12c  中設定成  false  。

備註：延遲段建立會導致  10g  客戶端  exp  匯出  12g  檔案無法匯出空表等

 

關閉跨節點並行查詢

ALTER SYSTEM SET =TRUE SCOPE=BOTH;

12g  會智慧的將查詢分佈在所有的節點，但是在普通心跳網路模式下，會加劇心跳壓力，在非  IB  交換機模式下建議關閉

 

直接路徑讀

對於大表，  Oracle 12c  傾向於直接路徑讀。如果  AWR  中，關於直接路徑讀的等待事件較高，可以考慮關閉該等待事件。

alter system  set "_serial_direct_read"=never scope=spfile sid='*';

 

9.1.6  調整  JOB  程式數量

11g  和12.1  裡面預設是1000  ，12.2  裡這個值預設是4000  ，建議設定成和CPU core  相等的值（以8 core  的cpu  為例）。

alter system set "JOB_QUEUE_PROCESSES" = 8 scope=spfile;

調整  _use_single_log_writer  隱含引數

alter system set "_use_single_log_writer"=true scope=spfile;

參考文件：

Multiple Log Writers in 12c Causing Enabling and Disabling of Adaptive Scalable Log Writer Workers Which Cause High 'log file sync' Wait Event (  文件 ID 2174075.1  )

該引數主要有三個可選值 true， false， adaptive， 預設值為ADAPTIVE。

對於ADAPTIVE 和False 如果CPU個數大於一個則會有多個lg0n程式

對於true 則不會生成多個lg0n程式，而如同12.1之前那樣僅有單個LGWR

 

裡面關閉  DRM

alter system set "_gc_policy_time"=0 scope=spfile sid='*';

alter system set "_gc_undo_affinity"=false scope=spfile sid='*';

 

DRM  本身是需要消耗資源的，並且存在諸多bug，對於一個設計較差的系統而言，頻繁的DRM，也會引發Library cache lock而導致例項掛住。

最佳化部分

9.2.1  關閉自適應執行計劃調整

自適應執行計劃調整為oracle  自動最佳化機制，異常情況下會導致執行計劃不穩定。

alter system set OPTIMIZER_ADAPTIVE_PLANS =false;

 

自適應遊標共享調整

自適應遊標共享為oracle  自動最佳化機制，異常情況下會導致執行計劃不穩定及記憶體使用異常。

alter system set "_optimizer_adaptive_cursor_sharing"=false scope=spfile;

alter system set "_optimizer_extended_cursor_sharing"=none  scope=spfile;

alter system set "_optimizer_extended_cursor_sharing_rel"=none  scope=spfile;

 

關閉  feedback

一些透過feedback  修正執行計劃的行為可能導致執行計劃不穩定及記憶體使用異常。

alter system set "_optimizer_use_feedback"=false scope=spfile;

alter system set "_optimizer_gather_feedback"=false scope=spfile;

 

調整  SCN  引數

alter system set " "=1 scope=spfile sid='*';

alter system set "_external_scn_logging_threshold_seconds"=600 scope=spfile sid='*';

SCN  遞增的一個極限閥值，模式是  24  小時，調整到  1  小時有助於減少  dblink  報錯：無效的  SCN

第二個引數為了檢測當資料庫被同步一個很大  SCN  後告警日誌能夠及時檢測，防止出現  SCN  過度傳染

以上兩個引數需要在  11.2.0.3  以上版本設定，低於該版本需要  patch  一定補丁才可以設定。

記憶體抖動引數

alter system set " "=false scope=both;

 

備註：

當資料庫系統由於  shared pool(large pool..)  中的記憶體被耗盡而將產生  ORA-4031  錯誤時  ,  即使沒有使用自動記憶體管理的特性  ,  資料庫也會透過縮小  buffer cache  的記憶體  ,  然後擴充套件  shared pool  記憶體的大小  ,  從而避免發生  ORA-4031  錯誤  .  當將引數”  _memory_imm_mode_without_autosga  ”設定為  FALSE  時  ,  可以關閉該特性  ,  但資料庫仍然會像以前一樣受到  ORA-4031  錯誤的威脅  .  注意  ,  從實際使用中的觀察結果看來  ,  這種記憶體調整是不可逆的  ,  就是說當  shared pool  存在大量空閒記憶體時並不會釋放上次從  buffer cache'  借用  '  的記憶體  .  建議如果有存在記憶體抖動的問題，還是以最佳化  SQL  為主，建議關閉該引數。

 

開啟  DDL  記錄操作

alter system set enable_ddl_logging=true;

備註：

對於希望監控  DDL  操作的，可以將次引數開啟，相關  DDL  操作會記錄到資料庫告警日誌中

 

記憶體引數最佳化

在  64G  主機記憶體的情況下，建議  ORACLE  記憶體設定如下  :

SGA	25G
PGA	5G
SHARED_POOL	5G

 

以上引數設定相對保守，可以自行決定具體引數設定範圍，但是不能讓  SGA+PGA  記憶體  >60%OS_Mem  並且確保主機交換空間充足

線上日誌調整

線上  redo  日誌組建議，每個節點  5  組，每組一個日誌檔案，每個日誌檔案大小在  200M-500M  （視具體業務情況而定），但是預設的  4  組每個節點  2  組  每組  50M  的預設設定明顯是不夠的

 

 

部分引數最佳化

磁碟組相容性

compatible  引數（資料庫的相容版本）還確定啟用的功能。該引數適用於資料庫例項或  ASM  例項，具體取決於  instance_type  引數。例如，將該引數設定為  10.1  將禁止使用  Oracle Database 11g  中引入的任何新功能（磁碟聯機  /  離線、可變區等）。

建或變更  ASM  磁碟組時，可以使用  CREATE DISKGROUP  命令或  ALTER DISKGROUP  命令新增的  ATTRIBUTE  子句更改其屬性。

調整  ASM  記憶體引數  (  影響版本  Release 11.2 to 12.2)

該部分參考  RAC  規模，如果主機  CPU  數量低於  32  記憶體小於  64G ASM  磁碟組規模低於  4T  則不需要設定該部分引數

MEMORY_TARGET  引數又基於  PROCESSES  引數相關連，有可能導致預設配置不足，在記憶體充裕的情況下建議調整（  asm  例項修改  ）：

SQL> alter system set memory_max_target=4096m scope=spfile;
SQL> alter system set memory_target=1536m scope=spfile;

 

備註：參看  文件 ID In   11.2.0.3/11.2.0.4, the "  PROCESSES" parameter will be default   to "available CPU cores * 80 + 40" (in the ASM spfile).  As   the default value for "  MEMORY_TARGET" is based on "  PROCESSES",   it can be insufficient if there is a large number of CPU cores or large number   of diskgroups which could cause issues (i.e. Grid Infrastructure stack fails   to stop with   ORA-04031 etc) per    &   , it is recommended to increase   the value of   MEMORY_MAX_TARGET &   MEMORY_TARGET before   upgrading/installing to 11.2.0.3/11.2.0.4 (does not apply to 10g ASM).   1) If PROCESSES   parameter is explicitly set: The MEMORY_TARGET should   be set to no less than:       256M + PROCESSES  * 132K (64bit)  or       256M + PROCESSES  * 120K (32bit) 2) If PROCESSES   parameter is not set: The MEMORY_TARGET should   be set to no less than:       256M + (available_cpu_cores * 80 + 40)   * 132K  (64bit) or 256M +   (available_cpu_cores * 80 + 40) * 120K    (32bit)

 

監控部署

監控部署對於  RAC  有著至關重要的作用，在出現故障或者出現疑難雜症的時候，必要的監控部署對問題的解決有著關鍵幫助

 

部署

OSwatch  作為監控主機效能及資源的工具，由  oracle  開源提供，建議每個工程師都會部署該工具

詳見文件：

301137.1     OS Watcher User Guide

580513.1      How To Start OSWatcher Black Box Every System Boot (Linux specific)

 

 

策略調整

預設  30  分鐘執行一次，保留  10  天（一個業務週期）

exec dbms_workload_repository.modify_snapshot_settings(interval=>30, retention=>10*24*60);

exec dbms_workload_repository.modify_baseline_window_size(10);

 

 

 

記憶體開啟大頁（實體記憶體大於  128g  開啟）

HugePages  詳解

參考文件：

HugePages and Oracle Database 11g Automatic Memory Management (AMM) on Linux (  文件 ID 749851.1)

HugePages on Linux: What It Is... and What It Is Not... (  文件 ID 361323.1)

HugePages on Oracle Linux 64-bit (  文件 ID 361468.1)

Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB Configuration (  文件 ID 401749.1)

/proc/meminfo Does Not Provide HugePages Information on Oracle Enterprise Linux (OEL5) (  文件 ID 860350.1)

Hugepages are Not used by Database Buffer Cache (  文件 ID 829850.1)

 

 

正文：

 

HugePages  是透過使用大頁記憶體來取代傳統的  4kb  記憶體頁面，使得管理虛擬地址數變少，加快了從虛擬地址到實體地址的對映以及透過摒棄記憶體頁面的換入換出以提高記憶體的整體效能。尤其是對於  8GB  以上的記憶體以及較大的  Oracle SGA size  ，建議配值並使用  HugePage  特性

 

huge page  的大小

huge page  的大小取決於所使用的作業系統的核心版本以及不同的硬體平臺
可以使用  $grep Hugepagesize /proc/meminfo  來檢視  huge page  的大小，對於較大的系統記憶體以及  sga  ，使用  hugepage  可以極大程度的提高  Oracle  資料庫效能

 

 

正確配置huge page

本次配置過程詳見文件：
HugePages on Oracle Linux 64-bit (  文件 ID 361468.1)

本操作基於  RHEL 6  進行測試：

[root@rehl6 ~]# more /etc/redhat-release

Red Hat Enterprise Linux Server release 6.2 (Santiago)

[root@rehl6 ~]# uname -a

Linux rehl6 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

 

1.

檢視當前系統是否配置  HugePages

下面的查詢中HugePages相關的幾個值都為0，表明當前未配置ugePages，其次可以看到[root@rehl6 ~]#

AnonHugePages:   1142784 kB

HugePages_Total:       0

HugePages_Free:        0

HugePages_Rsvd:        0

HugePages_Surp:        0

Hugepagesize:       2048 kB

2.

修改使用者的memlock限制

透過修改/etc/security/limits.conf 配置檔案來實現

   該引數的值通常配置為略小於當前的已安裝系統記憶體，如當前你的系統記憶體為64GB，可以做如下設定

  *   soft   memlock    60397977

  *   hard   memlock    60397977

   上述的設定單位為kb，不會降低系統效能。至少也要配置為略大於系統上所有SGA的總和。

   使用ulimit -l 來校驗該設定

 

3.  禁用AMM(Oracle 11g)

如果當前的Oracle 版本為10g，可以跳過此步驟。

如果當前的Oracle 版本為11g、12c，由於AMM(Automatic Memory Management)特性與Hugepages不相容，需要禁用AMM。

ALTER SYSTEM RESET memory_target SCOPE=SPFILE;

ALTER SYSTEM RESET memory_max_target SCOPE=SPFILE;

ALTER SYSTEM SET sga_target=<n>g SCOPE=SPFILE;

ALTER SYSTEM SET pga_aggregate_target=<n>g SCOPE=SPFILE;

SHUTDOWN IMMEDIATE;

STARTUP;

 

4.

計算vm.nr_hugepages 值

簡單的計算方法如下：（只做系統估計）

簡單的計算原理是total SGA_MAX_SIZE(多個instance的總和）/hugepagesize + N

N  為少量記憶體盈餘，一般多出100就足夠了。如果主機記憶體128GB，計劃70GB用於SGA共享記憶體，則大頁記憶體需70×1024/2=35840

使用Oracle 提供的指令碼hugepages_settings.sh的指令碼來計算vm.nr_hugepages的值（這個值設定的是hugepage momory 的大小）

   在執行指令碼之前確保所有的Oracle 例項已啟動以及ASM也啟動(存在的情形下)

  $ ./hugepages_settings.sh

該文件指令碼可以參看MOS文件，附錄一提供摘錄

：

Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB Configuration (  文件 ID 401749.1)

 

5.  設定vm.nr_hugepages引數

編輯/etc/sysctl.conf 來設定vm.nr_hugepages引數

  $ sysctl -w vm.nr_hugepages = 1496  （該值為上述指令碼獲得的值，  vm.nr_hugepages指明瞭記憶體頁數） 

  $ sysctl -p

 

6.  重啟例項及服務：

上述的所有步驟已經實現了動態修改，但對於HugePages的分配需要重新啟動主機server才能生效。

 

7.  驗證

HugePages  相關引數的值會隨著當前伺服器上的例項的停止與啟動而動態發生變化

   通常情況下，HugePages_Free的值應當小於HugePages_Total的值，在HugePages被使用時HugePages_Rsvd值應當為非零值。

  $ grep Huge /proc/meminfo

  HugePages_Total:   131

  HugePages_Free:     20

  HugePages_Rsvd:     20

  Hugepagesize:     2048 kB

 

   如下面的情形，當伺服器上僅有的一個例項被關閉後，HugePages_Rsvd的值為零。且HugePages_Free等於HugePages_Total

  $ grep Huge /proc/meminfo

  HugePages_Total:   131

  HugePages_Free:    131

  HugePages_Rsvd:      0

  Hugepagesize:     2048 kB  

 

 

 

後續備註:

/etc/security/limits.conf  配值檔案中memlock引數的值通常配值位略小於當前的已安裝系統記憶體

 

2. Huge  pagesize  LINUX  的大頁的大小為  2M  這是不能改變的，而且大頁在  oracle  伺服器上只與引數  sga_max_size  有關，  hugepage  目前只能用於共享記憶體段等少量記憶體型別，例如  oracle SGA  。  PGA  則不適用，所以不能隨便亂設定大頁內容，如果沒有  oracle  提供的指令碼，我們只需要簡單的計算原理：  total SGA_MAX_SIZE(  多個  instance  的總和）  /hugepagesize + N N  為稍微超出一點的記憶體大小，如果主機記憶體  128GB  ，計劃  70GB  用於  SGA  共享記憶體，則大記憶體頁需  70×1024/2=35840

 

vm.nr_hugepages  引數指定了大頁的數目，大頁數目*2（2048K大頁每頁的大小）就是可以使用的記憶體大頁總大小。

huge page  的大小
huge page  的大小取決於所使用的作業系統的核心版本以及不同的硬體平臺
可以使用  $grep Hugepagesize /proc/meminfo  來檢視  huge page  的大小
下面是不同平臺常用的  huge page  的大小。
HW Platform Source Code Tree  Kernel 2.4  Kernel 2.6
----------------- ---------------------  ------------  -------------
Linux x86 (IA32) i386  4 MB  4 MB * 
Linux x86-64 (AMD64, EM64T)  x86_64  2 MB  2 MB 
Linux Itanium (IA64) ia64  256 MB    256 MB 
IBM Power Based Linux (PPC64) ppc64/powerpc  N/A **    16 MB 
IBM zSeries Based Linux s390  N/A 1 MB 
IBM S/390 Based Linux s390  N/A   N/A

 

附錄一：  (  該指令碼不同版本或許會有些許變化，建議參考檔案重新下載)

hugepages_settings.sh

#!/bin/bash # #   hugepages_settings.sh # #   Linux bash script to compute values for the #   recommended HugePages/HugeTLB configuration # #   Note: This script does calculation for all shared memory #   segments available when the script is run, no matter it #   is an Oracle RDBMS shared memory segment or not. # #   This script is provided by Doc ID 401749.1 from My Oracle Support #     #   Welcome text echo   " This   script is provided by Doc ID 401749.1 from My Oracle Support ()   where it is intended to compute values for the   recommended HugePages/HugeTLB configuration for the current shared memory   segments. Before proceeding with the execution please note following:  * For ASM instance, it needs to configure   ASMM instead of AMM.  * The 'pga_aggregate_target' is outside the   SGA and    you should accommodate this while   calculating SGA size.  * In case you changes the DB SGA size,    as the new SGA will not fit in the   previous HugePages configuration,    it had better disable the whole HugePages,      start the DB with new SGA size and run the   script again. And   make sure that:  * Oracle Database instance(s) are up and   running  * Oracle Database 11g Automatic Memory   Management (AMM) is not setup    (See Doc ID 749851.1)  * The shared memory segments can be listed   by command:      # ipcs -m     Press   Enter to proceed..."   read   #   Check for the kernel version KERN=`uname   -r | awk -F. '{ printf("%d.%d\n",$1,$2); }'`   #   Find out the HugePage size HPG_SZ=`grep   Hugepagesize /proc/meminfo | awk '{print $2}'` if   [ -z "$HPG_SZ" ];then     echo "The hugepages may not be   supported in the system where the script is being executed."     exit 1 fi   #   Initialize the counter NUM_PG=0   #   Cumulative number of pages required to handle the running shared memory   segments for   SEG_BYTES in `ipcs -m | cut -c44-300 | awk '{print $1}' | grep   "[0-9][0-9]*"` do     MIN_PG=`echo   "$SEG_BYTES/($HPG_SZ*1024)" | bc -q`     if [ $MIN_PG -gt 0 ]; then         NUM_PG=`echo   "$NUM_PG+$MIN_PG+1" | bc -q`     fi done   RES_BYTES=`echo   "$NUM_PG * $HPG_SZ * 1024" | bc -q`   #   An SGA less than 100MB does not make sense #   Bail out if that is the case if   [ $RES_BYTES -lt 100000000 ]; then     echo "***********"     echo "** ERROR **"     echo "***********"     echo "Sorry! There are not enough   total of shared memory segments allocated for HugePages   configuration. HugePages can only be used for shared memory segments that   you can list by command:       # ipcs -m   of   a size that can match an Oracle Database SGA. Please make sure that:  * Oracle Database instance is up and running    * Oracle Database 11g Automatic Memory   Management (AMM) is not configured"     exit 1 fi   #   Finish with results case   $KERN in     '2.4') HUGETLB_POOL=`echo "$NUM_PG*$HPG_SZ/1024"   | bc -q`;            echo "Recommended setting:   vm.hugetlb_pool = $HUGETLB_POOL" ;;     '2.6') echo "Recommended setting:   vm.nr_hugepages = $NUM_PG" ;;      *) echo "Unrecognized kernel   version $KERN. Exiting." ;; esac   #   End