Exadata一体机使用的50个小技巧

Exadata数据库一体机已经经过多年的风雨磨砺修炼为X5版本;在中国Exadata也有着众多的成功案例,基于Oracle原厂和众多服务商的努力,我们对Exadata的使用也越来越成熟。 这里Maclean有幸能接受Oracle的邀请,参与到Oracle Exadata原厂团队的热烈技术讨论中。

通过实践或与同事/同行交流汇聚了50条Exadata使用中的小技巧,不吝抛砖引玉:

 

Exadata真机在装配流水线上

 


 

Exadata管理


Exadata性能优化

让表使用flash cache

ALTER TABLE <object name> storage (CELL_FLASH_CACHE KEEP);

 

可以使用如下公式计算Exadata特性对IO的优化

[ 1 – {(cell physical IO interconnect bytes returned by smart scan)

/ (cell IO uncompressed bytes + cell physical IO bytes saved by storage index)} ] * 100

 

可以使用如下公式计算Exadata Storage Index对Disk IO减少的共享

(cell physical IO bytes saved by storage index / physical read total bytes) * 100

 

可以使用如下计算Flash Cache的使用率

(cell flash cache read hit / physical read total IO requests) * 100

 

收集cell级别的表缓存统计信息的方法

SQL> SELECT data_object_id FROM DBA_OBJECTS WHERE object_name=’EMP’;
OBJECT_ID
———
57435
CellCLI> LIST FLASHCACHECONTENT –
WHERE objectNumber=57435 DETAIL cachedSize: 495438874
dbID: 70052
hitCount: 415483
missCount: 2059
objectNumber: 57435
tableSpaceNumber: 1

确认在使用write back flash cache

#dcli -g ~/cell_group -l root cellcli -e “list cell attributes flashcachemode”

Results:

flashCacheMode: WriteBack -> write back flash cache is enabled
flashCacheMode: WriteThrough -> write back flash cache is not enabled

 

确认所有的griddisk均为正常online状态

# dcli -g cell_group -l root cellcli -e list griddisk attributes asmdeactivationoutcome, asmmodestatus

确认所有的flashdisk均为正常online状态

# dcli -g cell_group -l root cellcli -e list flashcache detail

启用write back flash cache的方法

A. Enable Write Back Flash Cache using a ROLLING method

(RDBMS & ASM instance is up – enabling write-back flashcache one cell at a time)

Log onto the first cell that you wish to enable write-back FlashCache

1. Drop the flash cache on that cell
# cellcli -e drop flashcache

2. Check if ASM will be OK if the grid disks go OFFLINE. The following command should return ‘Yes’ for the grid disks being listed:
# cellcli -e list griddisk attributes name,asmmodestatus,asmdeactivationoutcome

3. Inactivate the griddisk on the cell
# cellcli –e alter griddisk all inactive

4. Shut down cellsrv service
# cellcli -e alter cell shutdown services cellsrv

5. Set the cell flashcache mode to writeback
# cellcli -e “alter cell flashCacheMode=writeback”

6. Restart the cellsrv service
# cellcli -e alter cell startup services cellsrv

7. Reactivate the griddisks on the cell
# cellcli –e alter griddisk all active

8. Verify all grid disks have been successfully put online using the following command:
# cellcli -e list griddisk attributes name, asmmodestatus

9. Recreate the flash cache
# cellcli -e create flashcache all

10. Check the status of the cell to confirm that it’s now in WriteBack mode:
# cellcli -e list cell detail | grep flashCacheMode

11. Repeat these same steps again on the next cell. However, before taking another storage server offline, execute the following making sure ‘asmdeactivationoutcome’ displays YES:
# cellcli -e list griddisk attributes name,asmmodestatus,asmdeactivationoutcome

 

B . Enable Write Back Flash Cache using a NON-ROLLING method

(RDBMS & ASM instances are down while enabling write-back flashcache)

1. Drop the flash cache on that cell
# cellcli -e drop flashcache

2. Shut down cellsrv service
# cellcli -e alter cell shutdown services cellsrv

3. Set the cell flashcache mode to writeback
# cellcli -e “alter cell flashCacheMode=writeback”

4. Restart the cellsrv service
# cellcli -e alter cell startup services cellsrv

5. Recreate the flash cache
# cellcli -e create flashcache all

 

确认Exadata 计算节点间的网络带宽

可以采用nc nc-1.84-10.fc6.x86_64.rpm获得

 

检测多个ORACLE_HOME是否RDS可用?

dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -l oracle md5sum ${ORACLE_HOME}/lib/libskgxp11.so

 

relink ORACLE_HOME的RDS

dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -l oracle “export ORACLE_HOME=$ORACLE_HOME;;cd `pwd`;;make – f i*mk ipc_rds”

dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -l oracle “export ORACLE_HOME=$ORACLE_HOME;;cd `pwd`;;make – f i*mk ioracle” | egrep ‘rm|mv.*oracle’

不同配置Exadata的推荐最大并行度

 

配置 CPU个数 推荐最大Parallelism
Full Rack 64 core DOP=256
Half Rack 32 core DOP=128
Quarter Rack 16 core DOP=64

 

Exadata EHCC支持

Exadata的EHCC支持宽表 最大支持1000个字段的表,而不像11.1中的压缩仅支持最多255列的表

 

Exadata 压缩信息

通过dbms_compression.get_compression_ratio 可以获得表的压缩信息

 

针对写日志redo特别多的应用建议启用Smart Flash logging特性

CREATE FLASHLOG ALL
CREATE FLASHLOG ALL SIZE=1G
CREATE FLASHLOG CELLDISK=’fd1,fd2′
CREATE FLASHLOG CELLDISK=’fd1,fd2′ SIZE=1G

 

 

Exadata DB管理

Exadata存储空间计算

FreeMB(最大可用空间) =
GridDisk*12*Num of Cells/Redundancy

UsableMB (支持1个CELL故障的最大可用空间) =
GridDisk*12*(Num of Cells – 1) /Redundancy

查看cell软件版本

imagehistory

imageinfo

了解cell的温度

dcli -g cell_group -l root “ipmitool sensor | grep ‘Inlet Amb Temp'”

 

cell存储节点的日志存放位置

$ADR_BASE/diag/asm/cell/`hostname`/trace/alert.log $ADR_BASE/diag/asm/cell/`hostname`/trace/ms-odl.* $ADR_BASE/diag/asm/cell/`hostname`/trace/svtrc__0.trc — ps -ef | grep “cellsrv 100” $ADR_BASE/diag/asm/cell/`hostname`/incident/*

/var/log/messages*, dmesg /var/log/sa/*

/var/log/cellos/*

列出cell中的alert history

list alerthistory where notificationState like ‘[023]’ and severity like ‘[warning|critical]’ and examinedBy = NULL;

为cell创建一个告警阈值

cellcli

create threshold CD_IO_ERRS_MIN warning=1, comparison=’>=’, occurrences=1, observation=1;

cell可用性监控

一般建议使用 EMGC Oracle Exadata Storage Server Management Plug-In 监控

 

如何禁用Smart Scan?

设置 Cell_offload_processing=false

如何禁用storage index?

设置 _kcfis_storageidx_disabled=true

如何禁用flash cache?

11.2.0.2 以后 设置_kcfis_keep_in_cellfc_enabled=false

11.2.0.1中设置_kcfis_control1=1

cell相关的数据库视图有以下这些视图

select * from sys.GV_$CELL_STATE;

select * from sys.GV_$CELL;

select * from sys.GV_$CELL_THREAD_HISTORY;

select * from sys.GV_$CELL_REQUEST_TOTALS;

select * from sys.GV_$CELL_CONFIG;

配置Inter-Database IORM

CellCLI> alter iormplan –
dbplan = ((name = production, level = 1, allocation = 100), –
(name = test, level = 2, allocation = 80), –
(name = other, level = 2, allocation = 20))
IORMPLAN successfully altered

CellCLI> alter iormplan active
IORMPLAN successfully altered

CellCLI> list iormplan detail
name: cell4_IORMPLAN
catPlan:
dbPlan: name=production,level=1,allocation=100
name=test,level=2,allocation=80
name=other,level=2,allocation=20
status: active

 

如何禁用布隆过滤Bloom Fliter

设置_bloom_pruning_enabled=false

 

 

Exadata数据备份

backup备份速率

Exadata下rman备份的速率从1通道到8通道 大约为1003MB/s 到 2081MB/s,视乎配置不同也略微有区别

recovery应用日志恢复速率

exadata recovery的速率大约为每秒600~1000MB/s的归档日志

standby database搭建

对于50TB的standby database搭建,若使用infiniband + 4rman通道大约耗费5.5小时,若使用GigE则在18个小时左右

 

Exadata恢复

 

cell 救护

可以通过 /opt/oracle.SupportTools/make_cellboot_usb脚本创建内部USB cellboot_usb_in_rescure_mode

 

 

Exadata部署

onecommand下载

可以下载patch (9935478) ONECOMMAND FOR Exadata 11gR2

 

Exadata安装前准备工作

1. 下载安装介质包括Grid, Database,Patches等
2. 硬件设备到货验收并安装就绪
3. 规划DBM用的管理网,生产网,ILOM等用的网段和IP地址
4. 配置DNS服务器
5. 将IP地址和域名注册到DNS服务器
6. 配置NTP服务器
7. 网络连线

环境检查

1. 检查DBM主机的eth0网卡是否可以通过cisco交换机被访问
2. 检查hardware and firmware profile是否正确
3. 验证InfiniBand Network

 

验证网络连通性

  1. 登陆第一台数据库服务器使用sh脚本验证网络连通性
  2. 验证DNS是否正常
  3. 验证NTP 服务器是否正常

安装Exadata Storage Server Image Patch (root user)
1. 在db server和cell server上为root用户配置SSH
# /opt/oracle.SupportTools/onecommand/setssh.sh -s -u root -p password -n N -h dbs_group

2. 检查当前Cell storage server的Exadata Image 版本
3. 安装最新的Patch具体步骤详见Readme
4. 验证当前Exadata Image version
#cd /opt/oracle.SupportTools/firstconf
#dcli -l root -g quarter ‘imagehistory | grep –i Version

使用OneCommand工具完成DBM的配置安装
1. #cd /opt/oracle.SupportTools/onecommand
2. Display the onecommand steps
# ./deploy112.sh -i –l
3. The steps in order are…
Step 0 = ValidateThisNodeSetup
Step 1 = SetupSSHForRoot
Step 2 = ValidateAllNodes
Step 3 = UnzipFiles
Step 4 = UpdateEtcHosts
Step 5 = CreateCellipnitora
Step 6 = ValidateHW
Step 7 = ValidateIB
Step 8 = ValidateCell
Step 9 = PingRdsCheck
Step 10 = RunCalibrate
Step 11 = ValidateTimeDate
Step 12 = UpdateConfig
Step 13 = CreateUserAccounts
Step 14 = SetupSSHForUsers
Step 15 = CreateOraHomes
Step 16 = CreateGridDisks
Step 17 = InstallGridSoftware
Step 18 = RunGridRootScripts
Step 19 = Install112DBSoftware
Step 20 = Create112Listener
Step 21 = RunAsmCa
Step 22 = UnlockGIHome
Step 23 = UpdateOPatch
Step 24 = ApplyBP
Step 25 = RelinkRDS
Step 26 = LockUpGI
Step 27 = SetupCellEmailAlerts
Step 28 = RunDbca
Step 29 = SetupEMDbControl
Step 30 = ApplySecurityFixes
Step 31 = ResecureMachine
To run a command
#./deploy112.sh –i –s N
Where N corresponds to a step number
Example to run step 0

Exadata监控

 

exachk健康检查脚本

exachk脚本可以以daemon形式后台运行

./exachk –d start

以daemon形式cluster support运行

./exachk –clusternodes [node1,[node N]] –d start!

 

Exadata文档信息

Exadata的官方文档 http://docs.oracle.com/cd/E50790_01/welcome.html

另外文档还保存在您cell 的 /opt/oracle/cell/doc/ 目录下。


 

Exadata硬件篇

 


 

 

常规

默认密码,以下是Exadata中cell/db node IB等的默认密码:

组件 登陆 默认密码
Storage Cells root nm2user welcome1
Infiniband Switch root nm2user welcome1 changeme
DB节点 root welcome1
CELL CLI celladmin welcome
ILOM root welcome1
KVM Switch Admin or none <none>
GigE switch <none> <none>

初始安装后asmsnmp的账号一般也是welcome1

硬件常规巡检:

在机房例行检查时,需要从Exadata机箱后方查看Exadata中是否有黄灯报警,如果有,记录位
置,即时登录OEM/ILOM/集成的第三方监控工具查明原因,定位部件,即时维护。

Exadata一体机健康检查脚本exachk,参考document 1070954.1

检测Exadata数据库机器上的硬件和固件版本是否匹配?

/opt/oracle.SupportTools/CheckHWnFWProfile
返回如下结果说明版本匹配:
[SUCCESS] The hardware and firmware profile matches one of the supported profile

 

检测软件版本与平台是否匹配?

/opt/oracle.SupportTools/CheckSWProfile.sh -c

 

为cell启用邮件告警

ALTER CELL smtpServer=’mailserver.maildomain.com’, – smtpFromAddr=’firstname.lastname@maildomain.com’, –

smtpToAddr=’firstname.lastname@maildomain.com’, –
smtpFrom=’Exadata cell’, –
smtpPort='<port for mail server>’, – smtpUseSSL=’TRUE’, – notificationPolicy=’critical,warning,clear’, – notificationMethod=’mail’;

alter cell validate mail;

 

监控 磁盘故障

当通过机房例行检查发现硬件黄灯警告或通过监控工具(命令行/ILOM/第三方工具)发现故

障并确定位置后,可进行更换操作。

更换Storage Cell硬盘

命令行登录Cell,判断故障硬盘,例如:
CellCLI> LIST PHYSICALDISK WHERE diskType=HardDisk AND status=critical DETAIL

 

观察Database Server 磁盘状态

[root@dm01db01 ~]# cd /opt/MegaRAID/MegaCli/
[root@dm01db01 MegaCli]# ./MegaCli64 -Pdlist -aAll | grep “Slot\|Firmware”

观察Database Server RAID状态

[root@dm01db01 MegaCli]# ./MegaCli64 -LdInfo -lAll –aAll

 

 

Storage Cell加电启动

远程登陆Storage Cell控制器ILOM,执行Power On,其它为系统的自动启动过程,知道Storage  Cell就绪

CellCLI> LIST GRIDDISK

若没有Active,需:

CellCLI> ALTER GRIDDISK ALL ACTIVE
等grid disk Active后,ASM会自动同步,使grid disk Online,查看状态: CellCLI> LIST GRIDDISK ATTRIBUTES name, asmmodestatus

 

确认ASM数据自动重新分布是否已经开始或完成。 Grid用户登录+ASM实例执行:

select * from v$asm_operation; 通过EM、SYSLOG、Cellcli、ILOM查看是否有告警解除信息

 

 

检测memory ECC错误

ipmitool sel list | grep ECC | cut -f1 -d : | sort -u

 

 

 

 

若发现Exadata上存在磁盘损毁则:

使用/opt/oracle.SupportTools/sundiag.sh 收集详细信息 并发给oracle support

 

检测 cell server Cache Policy

 

 
cell08#  MegaCli64 -LDInfo -Lall -aALL | grep 'Current Cache Policy'
Current Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU

cell09#  MegaCli64 -LDInfo -Lall -aALL | grep 'Current Cache Policy'
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU

Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU
Cache policy is in WB
Would recommend proactive  battery repalcement.

Example :
a. /opt/MegaRAID/MegaCli/MegaCli64 -LDGetProp  -Cache -LALL -aALL ####( Will list the cache policy)

b. /opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp  -WB  -LALL -aALL ####( Will try to change teh policy from xx to WB)
     So policy Change to WB will not come into effect immediately
     Set Write Policy to WriteBack on Adapter 0, VD 0 (target id: 0) success
     Battery capacity is below the threshold value
 
检测cell BBU备用电池状态:
cell08# /opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuStatus -a0

BBU status for Adapter: 0

BatteryType: iBBU
Voltage: 4061 mV
Current: 0 mA
Temperature: 36 C

BBU Firmware Status:

Charging Status : None
Voltage : OK
Temperature : OK
Learn Cycle Requested : No
Learn Cycle Active : No
Learn Cycle Status : OK
Learn Cycle Timeout : No
I2c Errors Detected : No
Battery Pack Missing : No
Battery Replacement required : No
Remaining Capacity Low : Yes
Periodic Learn Required : No

Battery state:

GasGuageStatus:
Fully Discharged : No
Fully Charged : Yes
Discharging : Yes
Initialized : Yes
Remaining Time Alarm : No
Remaining Capacity Alarm: No
Discharge Terminated : No
Over Temperature : No
Charging Terminated : No
Over Charged : No

Relative State of Charge: 99 %
Charger System State: 49168
Charger System Ctrl: 0
Charging current: 0 mA
Absolute state of charge: 21 %
Max Error: 2 %

Exit Code: 0x00
 
批量检测BBU 信息:
 
dcli -g ~/cell_group -l root -t '{
uname -srm ; head -1 /etc/*release ; uptime | cut -d, -f1 ; imagehistory ;
ipmitool sunoem cli "show /SP system_description system_identifier" | grep = ;
ipmitool sunoem cli "show /SP/policy FLASH_ACCELERATOR_CARD_INSTALLED
/opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuStatus -a0 | egrep -i
'BBU|Battery|Charge:|Fully|Low|Learn' ;
}' | tee /tmp/ExaInfo.log

 

Exadata 停机:

1. 确认无业务访问,以root 用户登录第1 个数据库服务器节点
2. 停止数据库(详见RAC/ASM 维护之RAC 启停章节)
3. 停止Cluster
# GRID_HOME/grid/bin/crsctl stop cluster -all
4. 停除本机以外的数据库节点

# dcli -l root -c dm01db02,dm01db03,dm01db04 shutdown -h -y now

5. 停存储服务器
cell_group 可自编辑,执行时并可由root 用户读取该文件(askmac.cn)
另需参考Storage Cell 存储维护Storage Cell 停机章节信息后方可执行下述命令
# dcli -l root -g cell_group shutdown -h -y now

6. 停本机
# shutdown -h -y now

7. 此时可通过ILOM 远程关机
8. 整机下电(关PDU)

 

Exadata 启动

1、为机柜加电(SWITCH 自然加电)
打开PDU开关进行加电,服务器指示灯都变绿,慢闪
若需手工开机数据库服务器、存储服务器需要按住其开关5秒。
也可在ILOM中点击Cell的Poweron开关进行开机,服务器指示灯为绿色长亮,再点击DB Server
的Poweron开关进行开机,服务器指示灯为绿色长亮。
2、检查是否有黄灯报警。
3、启动数据库、应用等。

 

 

 


 

Infiniband篇

 

启停IBSwitch

1. InfiniBand Switch电源的开启或关闭
InfiniBand Switch提供冗余电源,分别插在Exadata的2个冗余PDU电源上,并随PDU机柜电源

开启或关闭,若关闭InfiniBand Switch需断掉InfiniBand Switch的的冗余电源。 2. 查看OEM等是否有相关报警。

ILOM无法报警
从cell1的cellcli中查看list alerthistory可以看到

3. 从db01查看网络拓扑状态
[root@dm01db01 ~]# cd /opt/oracle.SupportTools/ibdiagtools

[root@dm01db01 ibdiagtools]# ./verify-topology -t halfrack

4. 插入InfiniBand电源线,查看InfiniBand Switch正常启动

 

检查IB链路状态

# /opt/oracle.SupportTools/ibdiagtools/infinicheck -z
# /opt/oracle.SupportTools/ibdiagtools/infinicheck

 

查看IB网络拓扑状态

登陆任意Database Server,采用Exadata工具命令:
[root@dm01db01 ~]# cd /opt/oracle.SupportTools/ibdiagtools
[root@dm01db01 ibdiagtools]# ./verify-topology -t halfrack

 

诊断IB链路没有错误

# ibdiagnet -c 1000 -r

 

查看IB网络连线

以root用户登陆InfiniBand Switch ILOM,采用listlinkup命令显示:
# listlinkup
Connector 0A Present <-> I4 Port 31 is ip
….

 

查看IB健康状态

# showunhealthy
OK – No unhealthy sensors.

 

IB健康检查

env_test

 

IB故障处理

1. 确认已经备份IB SWITCH
2. 确认所有的cable已经label,之后从IB switch上拔下cable
3. 拔下两根电源线poweroff
4. 取出IB switch
5. 安装新IB switch
6. 恢复IB switch设置
7. Disable the Subnet Manager
Disablesm
8. 连接cable
9. 确认cable连接的正确性
/opt/oracle.SupportTools/ibdiagtools/verify-topology
10. 从任何主机上运行如下命令确认 任何link没有错误
ibdiagnet -c 1000 –r
11. Enable the Subnet Manager using
Enablesm

 

IB硬件监控

showunhealthy & checkpower

Switch端口错误

ibqueryerrors.pl -s RcvSwRelayErrors,RcvRemotePhysE rrors,XmtDiscards,XmtConstraint Errors,RcvConstraintErrors,ExcB ufOverrunErrors,VL15Dropped

 

Link状态

/usr/sbin/iblinkinfo.pl -Rl

Subnet manager

/usr/sbin/sminfo

 

CISCO交换机

例行维护操作

采用Cisco IOS系统命令行方式,启动终端登陆管理网口IP:telnet xxx.xxx.xxx.xxx

输入用户名(root)/口令(welcome1),进入enable模式:

查看交换机的配置 通过show命令查看:

dm01sw-ip#show running-config Building configuration…
……

显示信息包括交换机主机名称、IP地址、网关地址、IOS系统版本、时区信息、DNS配置、 NTP配置、各网络端口配置、VLAN划分(全交换机一个VLAN)配置信息等。

运行监控
通过目前 Cisco 交换机监控的规范进行监控。

由于Cisco主要用于管理网使用,当完全不能访问时,只影响管理网的相关功能,不影响业务 网的正常运行。

当出现故障后,可采用目前Cisco交换机故障处理流程进行处理,并注意交换机主机名称、IP 地址、网关地址、IOS系统版本、时区信息、DNS配置、NTP配置、各网络端口配置、VLAN 划分(全交换机一个VLAN)等信息是否正确配置。

 

KVM

可通过 OEM GC 插件进行监控。

PDU

故障处理

单路故障不影响Exadata的连续性运行,但需要即时报修更换(包括管理IP等),以避免另外

备份PDU也出现故障,导致Exadata非正常停机。

Exadata的3D展示

Exadata的3D展示

 

Oracle Exadata Database Machine X5-2

 

 

 

Oracle Exadata Database Machine X4-8

 

高级客户服务 Oracle Exadata 服务 FAQ

问题的类别

 

Positioning定位

Pricing定价

Implementation实施

Process处理

Patching打补丁

General Delivery一般递送

 

问题的售支持系方式:

 

 

定位

 

问:操作管理operation management与白金服务有什么联系

 

: 在所有ACS服务中,操作管理operation management是建立在白金服务之上。对于Exadata而言,在购买操作管理operation management之前,白金服务是必需的。组件覆盖范围包括:硬件,Exadata软件和Oracle 11g第2版数据库。

 

:我的客户目前是SSC的客户,并对这个服务很满意,但他们的Exadata需要操作管理operation management。操作管理operation management是否能代替SSC

 

:操作管理operation management不会取代SSC。这两项服务是兼容的,但同时销售这两个需要你和你的销售支持联系人合作,以减少潜在重叠的服务组件,如账户管理。

 

: 我的客户对ACS很陌生。我是否该为他们新的Exadatas或操作管理operation management向他们推荐SSC(或相关的打包服务,例如ASA或白金服务)?

 

: 这取决于客户的需求。客户需求一般分为两大类:

  1. 想要以现有的雇员管理他们的 Exaadatas的客户。这个情况下,SSC可能是合适的,因为SSC的设计是提供专门的支持资源和积极规划,帮助客户自主管理Exadata,或;
  2. 重视特定IT操作,如Exadata的外包的客户。它与之前的数据库设置不同,让许多客户担心会损坏它。如果是这种情况,操作管理operation management可能是合适的选择。

除了以上这些,有些客户可能两者都不适合,这样的话与你的销售支持联系人合作,为你的客户定制正确的解决方案。

 

 

: 当用于ExadataAuto Service Request (ASR) 自动服务请求被发布,它是否会代替操作管理operation management

 

: 不。ASR 和操作管理operation management是兼容的。

ASR是:

  1. Premier Support的一部分,以及;
  2. 当这些 FRUs故障或达到预定的超出正常范围的操作限值时,对在Exadata中指定字段可替换单元(FRUs)的有价值的call home函数 。在满足其中一个条件的事件中,如果客户还没有注意到问题,ASR “phones home” 可以通过发出替换这些预定的FRU的SR,缩短支持过程。

ASR 不是:

  1. 在Exadata上目前可用,虽然它预计将很快面世,但需要当前Exadata客户的支持的升级
  2. 与 Oracle Configuration Manager (OCM)集成
  3. Exadata的完整监控解决方案

 

Operations Management建立在ASR之上,与ACS的整体定位一致。 ASR遥测是更丰富的一套定制的硬件,环境,软件和数据库的遥测的一部分,由Operations Management用于理解的整个Exadata堆栈的整体健康和性​​能。只有Operations Management有从数据库层到网络层的集成的完整的堆栈监控功能。更重要的是,Operations Management与ASR是功能分离的,因为ASR在损坏时加速修复的支持服务功能,而Operations Management有充分全天候管理Exadata的责任,与系统和数据库管理员相同。

 

: 那么,ExadataExadata季度丁部署Operations Management是如何运作的

 

: Operations Management包括季度补丁部署。补丁服务只提供客户季度Exadata的统一补丁的部署,其中包括硬件,固件,软件和数据库补丁。冗余的费用,如连接建立,账户管理时间和门户网站设置只有当包括Operations Management时才会从Patching Service的假设中删除。

定价

 

: 我如何定价Exadata Oracle Operations Management?

 

: 有两种定价Oracle Operations Management 交易的方式。对于小型交易,这里是第一个实例的价格:

price_management_monitoring

 

  • 小于$500,000的交易使用这些价格
  • 你会在1个工作日以内获得回复。
  • 请提供以下信息:
    • Exadatas将要部署的国家
    • 按国家的网站编号/位置
    • 按网址/位置的Exadata编号
    • 每个ExadataRack 大小和磁盘类型

 

  • 对于所有大型交易 (3个系统以上), 非标准交易如非英语交付(法语, 西班牙语,德语) 或根据国家的交付资源 (除了印度) 或定制配置

 

: 我如何定价,获得包含远程和现场资源的Ops Mgt交易的批准和合同?

 

: 参见以上指南,了解回答b中的非标准交易。

 

: 我有一个有多个rack非常大的Exadata。由于增长的经济,我是否可以得到更大的定价折扣?

 

: ACS Pricing Wizard 将所有大于 $500,000 的交易标志为需要定制定价。在这里,定价是由Operations Management业务送货人员给出的人力估算工具完成的。他们会将交易的各方面综合考虑,基于对帐户和交易的整体规模的了解,决定最有可能的价格。使用以上的bid desk alias。

 

: 是否可以监测SLA定价什么影响?

 

:监控的SLA是标准的且没有降价。

 

: 如果客提供了自己的DBA,他是否可以删除IT架构交付从而金?

 

:这个做法的节省是微不足道的,且应避免这种交易。我们可以与客户共享数据库管理职责,但Oracle作为责任的单点,他们最好保持服务紧密捆绑在一起为一体的产品。

 

: 什么非生Exadata机架成本相同?我是否可以得到一个非生的折扣?

 

: 很少。一直以来,我们的经验是,测试和开发系统需要相同工时作为生产系统进行监控,管理。如果有其他可减轻的情况,请让销售支持参与。

 

: 我的客户计在他们Exadata上放置大于标准数量的数据库= 2 / 四分之一机架4 /半机架,8 /全机架)是否更

 

: 是的,这将花费更多。这取决于正在实施的额外数据库的数量和其他的非标准变化。请与bid desk合作,以确定修改后的价格。

 

实施

 

: I understand a new “box” is necessary at the customer site. Is it one box per machine or one box per customer site? 我知道在客户站点有一个box”是必要的到底是一台机器一个盒子还是一个客户站点

 

: . 这个盒子被称为“Oracle Operations Management Gateway”。我们需要一个每个站点有一个(或更具体地每个网络有一个),所以如果一个box在相同的网络上,就能为多个位置提供服务。一般我们建议如果有多个位置配置两个box。

 

 

: 将安装个新的盒子Oracle Operations Management Gateway)?

 

:  Oracle Operations Management Gateway出厂时预先配置,并设计为客户安装。我们只需要电源,网络配置和防火墙的访问,然后就可以远程进行其余的安装。在事件中,如果客户不想自己安装,甲骨文的人员可以来现场。

 

: 我的客是一家大型金融机构。他需要管理Exadata帮助,但他有极其格的有关访问的安全政策我还有必要告诉这个服务吗

 

: Yes. Operations Management is both a highly flexible and secure service delivery model by design. Operations Management has very large customer in the US, European and Asian in the Financial, Healthcare and Government verticals. These customers have tailored security access process or in some cases purely on-site delivery models. Remote security compliance customization can include inbound access only on demand or with other limitations compliant with the customer requirements. But always bear in mind the security basics with any customer: 是的。Operations Management的设计是既高度灵活又安全的服务提供模式。Operations Management在美国,欧洲和亚洲,在金融,医疗保健和政府方面有大量的客户。这些客户有定制的安全访问过程或在某些情况下,纯粹的现场交付模式。远程安全合规性、的定制在按需或符合客户要求的其他限制下包括入站访问。但是,始终牢记对于任何客户的安全基本知识:

  1. 我们从不访问客户数据,只需要管理客户系统的元数据,以及;
  2. 我们对所有全球交付位置都进行 ISO 27001 认证,以及;
  3. 所有交付人员都经过筛选;
  4. 所有访问通过高度安全过程,包括密码验证被执行,同时也被记录和跟踪。

 

: 我知道远程Operations Management非常安全,但这并不重要。远程访问对我的客户是一个非首发,但他们想要一个托管的服务,我们有什么其他可销售的吗?

 

: 是的。有两个主要选项:

  1. 如果客户真的不愿接受任何连接,甚至只是站外连接,那么我们会提供现场的资源。转移覆盖,客户人员的整合,流程和工具都可以在此模型中定制。同样,现场工作人员可以追求所需的相应安全许可。
  2. 你可能已经涉及这个,但它值得一提,因为它可以使现场工作人员更有效,并给你的客户一个更经济的选择:如果客户允许仅站外连接,你可以对所有必要的访问提供有限的上门交付资源的混合模式,而无需工作人员每天3班。

 

过程

 

: 我知道 ”是全天候的,所有的事件都记录为务请求,然后将其传递给有没有其他通知机制可用?

 

: 客户当然可以给我们打电话或发送电子邮件,或通过Orion放置SR,但通常是我们通知他们。他们可以通过Operations Management Portal查看一切。他们还可以通过登录门户网站的记录事件,如果他们想的话。

 

: 如果客户只购买MON,服务会为客户在MOSMy Oracle Support中初始化SR创建 (假设决定15分钟通知SLA的激活事件发生)
: 在MON(仅监控)的合同中,当警报被触发,它被发送到我们​​的Operations Management控制中心,并在同一时间,一个ASR(自动服务请求)被Oracle Premier Support启动。我们向客户通知事件,并给了他们Incident Ticket。在这时,客户的工作是协调问题的缓解。如果在一个MAN(管理)的合同中,我们将保留turn-key责任,以解决该问题。

 

: 当我通知客户MON水平服务以下的事件会被提供什么级别细节?且他如何
:我们进行适当的客户通知联系,通常是通过电子邮件或电话,并提供Incident Ticket号。在ticket中,我们记录在警报中接收到的所有相关信息,以及Oracle Support SR号(如果适用)。

 

打补丁

 

 

: 如果客使用的是Exadata DBM提供独立的开测试UATQA境,是否可以独立地升级测试补丁程序的影响?

 

:  Quarterly Patching包被设计为一次性滚动到机架中的所有组件。从理论上讲,我们可以分离补丁以滚到测试/开发数据库实例,但是做到这一点就会加倍工时。在这样的情况下,我们将需要评估额外的工作级别并应用附加费。

 

:季度丁服相关的测试过是什么

 

: The primary value of the service is that the patch bundle has already been tested by SSC on complete Exadata machines.  We will not be replicating a customer environment and re-testing prior to roll-out.  Of course if the customer has a separate test/dev Exadata rack, we would apply it there prior to a production roll-out.  该服务的主要价值在于补丁包已经在完整的Exadata机器通过SSC测试。我们不会复制客户环境并在转出之前重新测试,转出。当然,如果客户有一个单独的测试/开发数据库Exadata机架,我们会生产转出之前在应用它。

 

一般递送

 

:该服务只提供数据库层的管理?

 

: 不。该服务是基于Sun和Oracle监视和管理工具的集成。Exadata一切都被控和管理,即使不支持SNMP数据(最常用于监视IT设备中的信息)的Infiniband交换机经由日志文件跟踪。该服务在行业内和Oracle中是唯一的,因为它聚集Oracle Enterprise Manager,Integrated Lights Out Management(ILOM),Auto Service Request(ASR)和自定义脚本,如对于机架内环境监测到单个无缝监控和管理提供。

 

:对于“24×7Predictive Monitoring预测监控”的定义是什么?

 

:  服务是一天24小时,每周7天提供的,并且是自动和预测的。在报警的情况下,我们会以我们的知识数据库中的信息自动匹配它,并采取行动,以确保最小或对客户没有影响。

 

: “数据库和存储配置”的定义是什么?

 

: 我们将代表客户配置和管理对环境的所有改变,即我们承担实际DBA和存储配置的工作 – 客户不需要做任何事情。

 

: 客户已经使用OEM Grid Control,它与“监控”是否兼容?有哪些影响?

 

: 是的我们的服务是兼容的。这样的客户将需要额外的步骤来评估最佳的执行配置,但这不会影响定价和交付能力。

 

: When packaged with an ASA or a BCA service, is it possible to just have Operations  “monitoring” on: 当与一个ASABCA服务打包,只有操作在“监控”可能吗:

 

  • 服务器和/
  • 操作系统和/
  • 存储和/
  • RDBMS

 

 

: 只购买监测和再单独卖ASA或BCA服务是可以的。独立监视或管理可以为Oracle Exadata IT栈(hw/os/db/storage)的任何或所有部件提供。但对客户来说,出售整个打包的Oracle Operations Monitoring或Exadata 解决方案的管理会带来最佳效益。取消捆绑消除了提供服务的协同作用,并会消除经济利益,如嵌入式季度补丁服务。

 

 

: 在林利斯戈,苏格兰有没有讲法语的人?这是否意味着,如果需要或现场参观的话,客户可以在法国与我们的ACS操作管理operation management控制中心通过电话互动?

 

: Oui, Oui/ 是的。我们有本地讲法语,德语和西班牙语的人。我们也支持10种其他语言,本地或是通过国外翻译POP。

 

 

: BCA Operations Management 门户相同吗?

 

: BCA 和Operations Management 是不同的服务,各自有唯一的门户。ACS Operations Management Portal 同时提供管理和各户对所有配置,事件,问题,变更管理报告以及基本系统性能报告的可见性的监控。

 

: 我的顾客喜欢Operations Management的理念,我们看了他的幻灯片和合同,但他们想知道具体有哪些操作且服务监控些什么。我在哪里可以得到这个信息?

 

: Activities are based in the ITILv3 process. A demo of the portal and sample account reviews should help 答 customer 问s about activates. Specific monitoring KPIs are available via your sales support contact. They are not generally available because they are continuously updated to improve service therefore must not be locked down in a contract. 活动在ITILV3过程中。门户和示例账户审查的演示将有助于回答客户关于激活的问题。具体的监测KPI是可以通过你的销售支持联系人获取。它们一般不可用,因为它们被持续更新以提高服务,因此不能在合同中被锁定。

 

所有其他ACS Exadata服务

 

定价

 

: 如果我3完整机架,定价向为红色,如所示。只有配置估和丁管理服机架数量敏感的其他组件的质量户门户机架数量,保持不是否所有的都要机架敏感

 

: No. Customer Orientation and Training, Customer Portal and Connectivity Set Up are among the components which are constant regardless of how many racks are purchased. Which service components do and do not change depending on the number of racks is built into the pricing wizard. 不。客户导向和培训,客户门户和连接设置在组件中是不变的,无论有多少购买的机架。哪些服务组件是否更改取决于定价向导中内置的机架的数量。

 

 

实施

 

: 我知道对于存储有特定的Exadata件。这需要收取外的配置服务费

 

: 不。Exadata是作为数据配置服的一部分被配置的

Exadata Reimaging 指南Guide

准备工作:

 

  1. 安装前需要考虑需要使用的image版本,image可以在e-delivery(https://edelivery.oracle.com/)上下载到,是分开cell和db两套Image的。
  2. 准备两个3GB大小的U盘,以及一个Linux操作系统,解压下载到的两个image到Linux中,运行其中的USB引导image脚本(是一个bash脚本),脚本提示的很清楚,按照提示进行即可。以此获得两套引导USB介质。

 

  1. 根据image版本去ARU上下载对应版本的onecommand(http://aru.us.oracle.com)。

 

  1. 下载到onecommand以后,解压,根据里面的readme文件,去support.oracle.com上下载对应版本的DB、GI、两者的BundlePatch、对应版本的Opatch安装介质(Opatch的安装介质版本不会写在onecommand中,可能需要运行onecommand时,根据报错再去下载,要做好准备!)。在安装完image以后需要放置到/opt/oracle.SupportTools文件夹下的onecommand目录中去(不要修改文件名!

 

  1. 如果是升级安装(例如本次升级到11.2.0.3的db版本),建议使用对应的onecommand版本和相应的DB、GI版本,不建议先安装到底版本的DB、GI然后再进行升级操作到需要的高版本。(本次升级PSC使用11.2.0.2的db版本和conmmand进行deploy,安装后才将db升级到11.2.0.3,这种方式不建议)

 

  1. onecommand中有dbconfigurator.xls文件,根据System同事的主机网络布线和配置情况(前期可能需要和system同事一起确定网络部署),填写该网络配置文件。填写好后,依次点击其中的两个按钮生成onecommand运行时需要的配置文件,并上传至装好相应Exadata的onecommand目录下。

 

  1. 如果是升级安装需要收集并保留原先的网络配置以备后续安装时使用。需要的信息:/opt/oracle.SupportTools/onecommand中原安装通过dbconfigurator.xls生成的配置文件(通常文件名为dbMachine_xxxx ,xxxx为主机名前缀);ifconfig 信息;/etc/hosts文件

 

 

安装DB:

 

  1. 插入DB USB Image,重启DB机器,在引导画面中进入引导选项菜单(或进入BIOS界面设置亦可),选择使用USB引导系统.

 

  1. 引导进去后,提示相对清晰,根据提示进行即可.

 

  1. 如果image版本较高,可能需要刷服务器固件,会占用大量时间!可以选择image版本。建议先了解当前机器的Image版本,选择与之相同或高一两个小版本的image。如果是升级安装则可能必须使用高版本,image操作首先开始刷固件微码(如果image比当前机器版本稍高则可能没有该步骤).

 

  1. 系统自动重起进行系统安装,安装成功后机器会自动关闭电源,此时拔去USB,加电后注意在BIOS中选择从硬盘引导,然后启动。

 

  1. 再次加电后,自动进入DB服务器节点IP等信息的配置阶段,根据和system同事确定的网络布线情况和ip规划填入相应的IP和网卡信息。(特别要注意IB网卡需要绑定、应用访问IP的以太网卡需要绑定,默认网卡请选择管理网端的网卡,具体使用那些网卡进行绑定需要视具体的网络连线而定).如果是升级安装则根据原先机器的网络配置进相应的配置操作。

 

  1. 配置成功后,再次自动重启。

 

  1. 成功进入系统后,上传解压后的onecommand工具至/opt/oracle.SupportTools目录下。

 

  1. 上传DB等安装介质和补丁至此目录。

 

  1. 等全部节点(DB、cell)的image安装完毕后,在onecommand目录下运行./checkip.sh进行网络配置检查,如果有问题根据显示的信息进行修正。检查没有问题之后运行onecommand目录下:deploy112.sh –s <step>(可以用-l 列出每个步骤代表的含义等,详见其帮助).注意DB版本11.2.0.3对应onecommand:deploy11203.sh

 

  1. 运行成功后,Exadata安装完毕。

 

 

安装Cell:

 

安装步骤大致同DB的1~5。

 

 

 

DBCell的安装可以并行进行,没有特定的顺序要求(先DB、先Cell都可以)。建议多刻几个USB启动盘,同时进行re-imaging这样可以节省很多时间。

 

【转】Exadata X2-2/X3-2的Reimage过程

ISO文件制作

1.根据文档888828.1获取db/cell Image文件,解压zip包,并在Linux文件系统下解压tar包,注意命令行为

tar -pxvf cellImageMaker_11.2.3.2.1_LINUX.X64_130109-1.x86_64.tar

tar -pxvf computeImageMaker_11.2.3.2.1_LINUX.X64_130109-1.x86_64.tar

 

2.preconf文件的准备

首先根据正常步骤使用xls或java配置工具生成preconf文件,然后获取db/cell节点eth0的MAC地址,并将MAC地址填写到管理IP前的两个逗号之间,如

--在修改前

dm03cel07,exadata.icbc,cell,eth0,eth0,Management,,84.2.51.135,255.255.255.0,84.2.51.254,dm03cel07-priv.exadata.icbc,Private,192.168.10.59,255.255.252.0,84.37.97.15,84.24.49.104,Asia/Shanghai,ilom,dm03cel07-ilom.exadata.icbc,84.2.51.157,255.255.255.0,84.2.51.254,84.37.97.15,enabled,84.24.49.104,,

dm03cel06,exadata.icbc,cell,eth0,eth0,Management,,84.2.51.134,255.255.255.0,84.2.51.254,dm03cel06-priv.exadata.icbc,Private,192.168.10.58,255.255.252.0,84.37.97.15,84.24.49.104,Asia/Shanghai,ilom,dm03cel06-ilom.exadata.icbc,84.2.51.156,255.255.255.0,84.2.51.254,84.37.97.15,enabled,84.24.49.104,,

--在修改后

dm03cel07,exadata.icbc,cell,eth0,eth0,Management,00:10:E0:21:BF:F6,84.2.51.135,255.255.255.0,84.2.51.254,dm03cel07-priv.exadata.icbc,Private,192.168.10.59,255.255.252.0,84.37.97.15,84.24.49.104,Asia/Shanghai,ilom,dm03cel07-ilom.exadata.icbc,84.2.51.157,255.255.255.0,84.2.51.254,84.37.97.15,enabled,84.24.49.104,,

dm03cel06,exadata.icbc,cell,eth0,eth0,Management,00:10:E0:22:37:38,84.2.51.134,255.255.255.0,84.2.51.254,dm03cel06-priv.exadata.icbc,Private,192.168.10.58,255.255.252.0,84.37.97.15,84.24.49.104,Asia/Shanghai,ilom,dm03cel06-ilom.exadata.icbc,84.2.51.156,255.255.255.0,84.2.51.254,84.37.97.15,enabled,84.24.49.104,,

填写所有的db/cell相关的MAC信息。其中一份文件为cell准备,将其中所有db节点的信息注释掉,另外一份为db准备,将其中所有cell的信息注释掉。可分别起名为preconf_mac_db.csv/preconf_mac_cell.csv

 

3.cell的ISO制作文件夹为dl180,db的ISO制作文件夹为dl360, X3-2/X2-2没有差别;

使用root用户支行以下命令制作db/cell的ISO文件

./makeImageMedia.sh -preconf ../preconf_mac_db.csv -stit -notests diskgroup -nodisktests  -dualboot no dbimg112321.iso

./makeImageMedia.sh -preconf ../preconf_mac_db.csv -stit -notests diskgroup -nodisktests  cellimg112321.iso

 

每个ISO文件大约需要时间为3-5分钟

 

4.启动Remote Console及ISO文件加载

ILOM上配置了JAVA程序,可以直接将相关主机的终端输出在本地显示出来,只要提供IP,ROOT用户及口令即可;

同时ILOM也提供了远程映射ISO文件的重定向功能,即将ECC的机器上的ISO映射到db/cell上的CDROM,等同于制作了CDROM光盘并用这个CDROM启动。

exadata-reimage-1

点击Launch Remote Console,启动Java终端。

 

加载本地ISO文件

exadata-reimage-2

在ILOM中设定下次启动为CDROM

exadata-reimage-3

 

在ILOM里重启主机:

exadata-reimage-5

 

5.REIMAGE过程

主机启动界面将变为:

exadata-reimage-6

敲enter键,主机从CDROM启动系统。

第一次为检测FIRMWARE版本,最终会停留在以下界面:

exadata-reimage-7

系统会提示IMAGE中的FIRMWARE比当前系统的版本新,需要更新。在更新完毕后5分钟系统会自动启动。

 

--DB、CELL的ReIMAGE过程及BIOS的启动次序

通常REIMAGE过程至少需要2次启动,一次检测并更新FIRMWARE,另外一次是实际的文件拷贝过程。除此之外cell还有另外一次本地启动的自检过程。

 

使用ILOM设置启动位置在X2-2和X3-2是不同的,前者会继续使用CDROM启动,进入正常的REIMAGE过程,后者会恢复到缺省本地启动,REIMAGE会被打断,所以务必按F2进入Bios里确认本次启动的位置。

 

所以务必要知道当前主机是第几次启动,并使用F2在BIOS里确认。

当db/cell从本地启动时,启动界面是这样的:

exadata-reimage-8

--DB/CELL的REIMAGE完成标记

exadata-reimage-9

 

当REIMAGE过程完毕时,无论CELL/DB都会出现Installation SUCCESSFUL字样,否则ReIMAGE过程就没有结束。

 

 

 

6.关于dualboot问题

缺省从工厂出来的机器里的db节点都是启用dualboot的,也就是说有一个solaris文件系统在(可使用fdisk看到),而使用上面制作的ISO文件reimage后db节点是不会有solaris文件系统的,不管有没有在制作 iso时添加-dualboot no选项。

所以db在做reimage后,不需要做reclaim,即使做也会异常退出的。

 

Exadata数据库一体机维护任务

目标

本课程结束后,你能执行以下数据库机器维护任务:

  • 开启及关闭数据库机器
  • 安全关闭单个EXADATA存储服务器
  • 在cell上替换损坏的物理磁盘
  • 在cell上替换损坏的flash卡
  • 将所有磁盘从一个cell转移到另一个
  • 使用EXADATA cell软件拯救步骤

 

数据库机器维护概览

 

  • 维护数据库机器与维护任何聚类Oracle数据库环境类似
  • 本课程介绍的数据库特定机器任务:
    • 开启及关闭数据库机器
    • 安全关闭单个EXADATA存储服务器
    • 在cell上替换损坏的物理磁盘
    • 在cell上替换损坏的flash卡
    • 将所有磁盘从一个cell转移到另一个
    • 使用EXADATA cell软件拯救步骤
  • 其他参考:
    • Oracle Exadata 数据库机器所有者指南
    • My Oracle Support

 

 

  • 维护数据库机器在许多方面与维护任何聚类Oracle数据库环境类似。维护Oracle集群软件的程序,ASM,RAC由于都在其他平台,所以它们在数据库机器上本质是相同的,主要区别是EXADATA cell对象的引用。
  • 本课程重点在管理员最可能遇到的一系列数据库特定机器维护任务。其他不常见的维护任务记录在OracleEXADATA数据库机器所有者指南。管理员也能参考My Oracle Suppor中其他维护问题。
  • 注:EXADATA数据库集群的补丁指南是本课程中独立的一节。

 

关闭并启动数据库机器

关闭过程:

  1. 数据库服务器

#<GRID_HOME>/bin/crsctl stop cluster

#shutdown -h -y now

 

确保执行之前所有数据库服务器都被关闭

  1. EXADATA存储服务器

shutdown -h -y now

确保执行之前所有数据库服务器都被关闭

  1. Rack,包括网络切换

启动过程:

  1. Rack,包括网络切换

执行之前电源接通几分钟

  1. EXADATA存储服务器

执行之前确认所有cell都在运行

  1. 数据库服务器

 

幻灯片列出了在非紧急情况下,关闭及启动数据库机器的建议顺序。

执行任一过程时,确保继续下一步之前,每个步骤都完全结束很重要。不以适当的顺序执行可能会导致在数据库机器不正常的工作。

当启动Exadata存储服务器和数据库服务器时,可以通过按下每个服务器前部的电源按钮,或通过为每个服务器登录到ILOM界面并发出start/ SYS命令来启动。

要启动或关闭rack,使用位于电源分配单元(PDU)的开关,位于机架背面。

 

 

安全关闭单个EXADATA存储服务器

 

安全关闭步骤:

  1. 确保关闭存储服务器不会让ASM磁盘组下线

CELLCLI>  LIST GRIDDISK WHERE asmdeactivationoutcome != ‘YES’

  1. 使所有grid磁盘在非活跃状态

CELLCLI>  Alter GRIDDISK ALL INACTIVE

  1. 验证所有grid磁盘在非活跃状态

CELLCLI> LIST GRIDDISK WHERE STATUS !=’inactive’

  1. 关闭存储服务器

启动步骤:

  1. 启动存储服务器

Cell服务自动启动

  1. 使所有grid磁盘在活跃状态

CELLCLI> ALTER GRIDDISK ALL ACTIVE

  1. 验证所有grid磁盘在活跃状态

CELLCLI> LIST GRIDDISK ATTRIBUTES name , asmmodestatus

 

在某些维护情况下,单个Exadata存储服务器必须孤立地关闭。例如,一个硬件组件,如闪存卡或磁盘控制器,可能有间歇故障,所以存储服务器必须被关闭,替换该部件,而系统的其余部分继续支持处理活动而不会对系统的用户产生实质性影响。在这些情况下,理想的结果是,数据库机环境继续支持处理活动,而不会对系统的用户产生实质性影响。

为了安全,正常关闭单个Exadata存储服务器,使用幻灯片中显示的命令。当确认关闭存储服务器将不会使任何ASM磁盘组离线,第一个LIST GRIDDISK命令应该没有输出。如果任何输出返回,那么使Exadata存储服务器离线是不安全的,因为适当的Oracle ASM磁盘组冗余将无法维持。

使Exadata存储服务器离线时,当一个或多个grid磁盘处于这种状态,会导致ASM卸载受影响的磁盘组,从而导致数据库突然关闭。在这种情况下,你需要分析情况,使其他grid磁盘在线来安全处理。

Exadata存储服务器被重启且grid磁盘被重新激活后,检查所有被分配到ASM磁盘组的网格磁盘显示asmmodestatus = ONLINE。未分配给ASM磁盘组的网格磁盘应显示asmmodestatus = UNUSED。

 

 

 

替换损坏的物理磁盘

 

Replacing a Damaged Physical Disk

  1. 确认损坏的磁盘
  2. 替换物理磁盘
  3. 监控ASM以确认磁盘的重新添加

 

由于问题或故障更换物理磁盘最有可能是Exadata存储服务器需要的硬件维护操作。假设你正在使用ASM冗余,更换有问题的磁盘的步骤相当简单。

第一步需要你识别问题磁盘。这有多种方式:

  • 使用ILOM的硬件监控可能会报告有问题的磁盘。
  • 当磁盘发生故障,生成一个Exadata警报。警报包括更换磁盘的具体说明。如果已经为系统配置了警报通知,警报将被发送到指定的电子邮件地址或SNMP目标。LIST ALERTHISTORY命令也可用于识别故障磁盘。
  • LIST PHYSICALDISK命令可以识别报告异常状态的磁盘。即使cell仍在工作,该问题可能是磁盘故障的前兆。
  • CALIBRATE命令可以识别提供异常低的吞吐量或IOPS的磁盘。即使cell仍能正常工作,一个坏的物理磁盘会降低其他优秀的磁盘的性能,所以你可以考虑更换识别的磁盘。注意在cell活跃的同一时间运行CALIBRATE会影响性能。

你可以使用ALTER PHYSICALDISK命令点亮一个LED的服务,其帮助将磁盘名称正确地翻译为相应的物理磁盘的位置。

 

当检测到故障磁盘,物理磁盘上与grid磁盘相关的Oracle ASM磁盘通过FORCE选项被自动删除,且Oracle ASM重新平衡操作恢复数据冗余。这个过程被称为主动式硬盘检疫。

如果你想更换一个表现不佳,但还没有被主动盘检疫磁盘分离的磁盘,您必须使用ALTER DISKGROUP … DROP DISK命令手动删除相关的网格磁盘。

确定问题磁盘后,你可以替换它。当你删除了磁盘,你会得到一个警告。当更换一个物理磁盘,磁盘使用之前,必须由RAID控制器确认。这并不需要很长的时间,你可以使用LIST PHYSICALDISK命令监视状态,直到其返回到NORMAL。

在插槽中之前磁盘的网格磁盘和cell磁盘将在新磁盘上被自动重建。如果这些网格磁盘是Oracle ASM磁盘组的一部分,NORMAL或HIGH冗余,它们将被重新添加到磁盘组,数据将基于磁盘组的冗余和AS​​M_POWER_LIMIT参数被重新平衡。

重建ASM磁盘及重新平衡数据可能需要一段时间来完成。你可以在ASM中监控这些操作的进展。你可以监控V$ASM_DISK.STATE报告的磁盘状态,直到它返回到NORMAL。你还可以使用GV$ASM_OPERATION监控重新平衡的进展。

更换故障磁盘时,请查看以下注意事项:

  • 磁盘可以被ASM删除,且重新平衡操作可能已成功运行。查看Oracle ASM警报日志来确认这点。在故障磁盘被替换后,还需要第二次重新平衡。
  • 磁盘可被删除,且重新平衡操作当前正在运行。查看GV$ ASM_OPERATION以确定重新平衡操作是否仍在运行。在这种情况下,更换磁盘后的重新平衡操作将被排列。
  • 磁盘可以被ASM删除,且重新平衡操作失败。查看GV$ ASM_OPERATION.ERROR以确定重新平衡操作失败的原因。更换磁盘后监控重新平衡操作以确保它运行。
  • 来自多个磁盘组的重新平衡操作可以在同一个集群的不同Oracle ASM实例来完成,如果被替换的物理磁盘包含来自多个磁盘组的网格磁盘。多个重新平衡操作不能在同一个Oracle ASM实例中同时运行。该操作将为实例被排列。

替换损坏的flash卡

Replacing a Damaged Flash Card

  1. 确认损坏的flash卡
  2. 关闭cell
  3. 替换flash卡
  4. 开启ceell

 

每个Exadata存储服务器配备了4个PCI闪存卡。每个卡具有4个闪存模块(FDOMs),每个cell中总共16个闪存模块。

识别损坏的闪存模块类似于识别损坏的物理磁盘。硬件监控使用ILOM或CALIBRATE命令提示的性能下降表示可能存在问题。如果检测到一个故障的FDOM,则生成警报。

一个坏的闪存模块会导致cell上闪存量的减少。cell的性能受到影响与失去闪速存储的大小成正比,但是数据库和应用程序不会面临故障的风​​险。

如图中显示,使用LIST PHYSICALDISK DETAIL命令也可报告损坏的闪存模块。SlotNumber属性显示了PCI插槽和FDOM数量。在这个例子中,status属性显示了关键故障。

虽然技术上在Exadata存储服务器中的PCI插槽是可热更换的,建议在更换损坏的闪存卡时关闭cell。

更换记忆卡并启动cell后,无需额外的步骤在新的闪存模块重建智能闪存高速缓存和智能闪存日志区域。

 

将所有磁盘从一个cell转移到另一个

Moving All Disks from One Cell to Another

 

  1. 使grid处于非活跃状态  CellCLI > ALTER GRIDDISK ALL INACTIVE
  2. 备份操作系统配置文件,其可能在新cell启动后更改
  3. 将磁盘,闪存卡,磁盘控制器和CELLBOOT USB闪存驱动从原本cell转移到新的cell。

确保系统磁盘占头两个插槽。

确保闪存卡占系统的PCI插槽。

  1. 启动新cell。
  2. 重启EXADATA cell服务:

CellCLI >  ALTER CELL RESTART SERVICES ALL

  1. 激活网格磁盘:

CellCLI> ALTER GRIDDISK ALL ACTIVE

 

您可能需要将所有驱动器从一个存储服务器到另一台服务器。当有一个机箱级别的组件故障,或当故障排除硬件问题时,该操作是必要的。要移动驱动器,执行以下步骤:

  1. 如果可能的话,使用ALTER GRIDDISK ALL INACTIVE命令,使网格磁盘无效。
  2. 如果可能,备份/etc/ hosts,/etc/modprobe.conf中,以及在/ /etc/sysconfig/network and /etc/sysconfig/network-scripts中的文件。这主要是一个预防措施,如果你要将磁盘转移回到原来的机箱这也是有用的。
  3. 关闭原始服务器并将硬盘,闪存卡,磁盘控制卡和CELLBOOT USB闪存驱动器转移到新的服务器。

注意:确保头两个磁盘,即系统磁盘,在相同的头两个插槽。同时确保闪存卡被安装到同一个PCI插槽。如果不这样做会导致Exadata存储服务器无法正常工作。

  1. 启动cell。cell操作系统应被自动重新配置,以适应新的服务器硬件。
  2. 使用ALTER CELL RESTART SERVICES ALL重启cell服务。
  3. 使用ALTER GRIDDISK ALL ACTIVE激活网格磁盘。

如果你正在使用ASM冗余且在DISK_REPAIR_TIME ASM初始化参数中指定的时间之前完成了步骤,那么ASM磁盘会自动联机,更新cell故障期间所做的任何更改。

 

 

使用Exadata Cell 软件拯救步骤

每个EXADATA存储服务器配备图个CELLBOOT USB闪存驱动以便于cell拯救

如果两个系统磁盘同时故障或崩溃就需要执行该操作

谨慎使用

要执行cell拯救:

  1. 使用控制台连接到EXADATA存储服务器
  2. 启动cell,一旦看到”Oracle Exadata” 画面显示,按下任意键
  3. 在显示的boot选项列表中,选择最后一个选项,CELL_USB_BOOT_CELLBOOT_usb_in_rescue_mode,按下Enter
  4. 选择rescue选项,处理拯救过程
  5. 在rescue过程的最后,确保cell从系统磁盘启动
  6. 重新配置cell

 

Exadata存储服务器维护在不同的物理磁盘的镜像系统区域。如果一个系统区被损坏或不可用,镜像副本用于恢复。

在这两个系统磁盘同时故障的极少数情况下,你必须使用提供内置于每个Exadata存储服务器的CELLBOOT USB闪存驱动器上提供的拯救功能。拯救过程可能还需要从文件系统损坏或损坏的boot区恢复。

使用拯救步骤时,要注意以下几点:

  • 使用此过程时请务必谨慎,并注意提示符。拯救过程可能会改写cell中一些或全部磁盘。如果发生这种情况,那么你可能无可挽回地失去这些磁盘上的内容。理想情况下,你应该仅在Oracle支持服务的帮助下使用拯救步骤。
  • 拯救过程不会破坏数据磁盘的内容或系统磁盘上的数据分区的内容,除非你在拯救过程中显式选择这样做。
  • 拯救步骤将Exadata存储服务器软件恢复到相同版本。这包括存在于cell的任何补丁,作为最后的成功启动。
  • 使用拯救过程无法恢复以下:
  • 一些cell配置的详细信息,如警报配置,SMTP信息,以及管理员的电子邮件地址。注意,cell网络配置被恢复,以及cell的SSH标识,root,celladmin和cellmonitor用户。
  • LOM配置。通常情况下,ILOM配置保持完好,即使在Exadata软件故障的情况下。
  • 拯救过程不检查或重建数据的磁盘或系统磁盘上的数据分区。如果在网格磁盘有数据损坏,则不要使用拯救步骤。相反,使用数据库备份和恢复步骤。

以下拯救选项可用于拯救步骤:

  • 部分重建恢复:在局部重建恢复期间,拯救步骤重建系统磁盘上的分区,检查磁盘中文件系统的存在。如果文件系统被发现,则该过程试图启动。如果cell成功启动,然后使用CellCLI命令,如LIST CELL DETAIL,以验证cell可用。你还必须适当地恢复任何数据磁盘。如果启动失败,则必须使用完整的原始版本恢复选项。
  • 完整的原始版本恢复:此选项重写系统磁盘的系统区域以恢复EXADATA软件。它还允许你删除系统磁盘上的任何数据,以及系统磁盘上的任何数据分区。

CELLBOOT USB闪存驱动器的重建:该选项是用来创建CELLBOOT USB闪存驱动器的副本。

使用CELLBOOT USB闪存驱动器来进行拯救:

  1. 使用控制台连接到Exadata存储服务器。
  2. 启动cell,只要你看到“Oracle Exadata”闪屏,请按下任意键。闪屏只可见5秒。
  3. 在boot选项显示的列表中,下拉到最后一个选项,CELL_USB_BOOT_CELLBOOT_usb_in_rescue_mode,然后按Enter键。
  4. 选择rescue选项,并继续拯救步骤。
  5. 当在拯救过程最后被提示,执行步骤如下:
    1. 选择进入shell。此时不要选择reboot选项。
    2. 使用拯救root密码登录到shell。
    3. 在shell运行reboot命令。
    4. 在重新启动期间,但在看到“Oracle Exadata”闪屏之前,按F8进入启动设备选择菜单。
    5. 选择RAID控制器作为启动设备。
  6. 成功拯救后,必须重新配置cell,使其恢复到故障前的配置。如果在拯救过程被提示时选择保留数据,那么导入cell磁盘。如果选择不保留数据,那么你应该创建新的cell磁盘和网格磁盘。

 

 

小测试

当关闭EXADATA数据库机器时,EXADATA存储服务器必须先被关闭:

A.True

B.False

Answer: B

 

小测试

EXADATA存储服务器应当被关闭以替换除了硬盘驱动的故障的硬件组件:

 

A.True

B.False

Answer: a

While the flash memory cards inside Exadata Storage Server are hot-swappable, Oracle recommends that cells should be shut down to replace hardware components inside the chassis.

当在EXADATA存储服务器中的闪存卡是可热插拔的,Oracle建议cell应当被关闭以替换机架中的硬件组件。

 

 

小测试

如果一个EXADATA存储服务器磁盘故障,以下哪个是正确的?

  1. 相关的ASM网格磁盘被自动删除且发生了ASM重新平衡,以快速恢复冗余
  2. 在没有关闭存储服务器时,磁盘可能被替换
  3. 存储服务器必须被关闭以替换磁盘
  4. 多个ASM实例能参与单个磁盘组的重新平衡操作

 

Answer: 1,2

总结

本课程中,你应该学会了执行以下数据库机器维护任务:

  • 开启及关闭数据库机器
  • 安全关闭单个EXADATA存储服务器
  • 在cell上替换损坏的物理磁盘
  • 在cell上替换损坏的flash卡
  • 将所有磁盘从一个cell转移到另一个
  • 使用EXADATA cell软件拯救步骤

 

 

 

 

 

如何诊断Exadata Cell CPU占用率高的问题

原文链接: http://www.dbaleet.org/how_to_troubleshooting_cell_node_high_cpu_issue/

事实上,Exadata Cell节点CPU占用率高的情况并不常见。主要是原因有两点:

一是当前Exadata smart scan发生的条件限制较多,通常情况下能够offload到cell节点进行运算的任务并不占绝大多数。

二是当前Cell节点CPU的运算能力实际上已经完全足够,在正常的情况下Cell节点CPU的空闲率都是比较高的。

而Cell节点CPU占用率高也分为所有的Cell节点CPU占用率都很高,还是只有一台或几台Cell节点占用率很高。这两者通常是不一样的,因为正常情况下,一个offloading的任务会均匀分布到所有的Cell节点上,如果所有Cell节点都很高的时候,通常说明当前系统负载较高。但是如果只有一台或者几台Cell节点CPU占用率高,那么这个大多数情况下不是正常的。本文讨论的情况属于后者。

那么如何诊断这一问题呢?可以试着按照以下步骤来解决:

是否为硬件的问题?

系统硬件的问题通常比较好判断,可以通过以下方式进行。(如果确定不是硬件问题,可以跳过这一步。)

  • 查看操作系统的/var/log/messages和dmesg,看是否有任何报错信息;
  • 登陆到ilom的faulty shell查看是否有faulty的信息:
->show /SP/faultmgmt
->start /SP/faultmgmt/shell
Are you sure you want to start /SP/faultmgmt/shell (y/n)? y
faultmgmtsp>
faultmgmtsp> fmadm faulty -a
No faults found
faultmgmtsp> exit
->
  •  运行Linux命令sosreport收集硬件的诊断信息。

exachk是否有帮助?

exachk is your friend.

在Exadata中,出现任何与数据库无关的问题的时候最好都运行exachk进行健康检查。exachk收集的信息很全,省去大量人工收集的繁琐步骤。并且收集完成以后,可以在整体上对系统的健康状况做一个评估,从中发现一些可疑点,进而缩小范围进行下一步的诊断。

通过操作系统的命令查看进程信息?

如果问题在当前环境下还存在,那么可以直接从操作系统中获取有用的信息。

  • 在cell上运行top命令来查看当前最消耗CPU资源的是哪个/哪些进程。然后获取其pid。
  • 如果是cellsrv进程占用cpu很高,可以考虑对其做一个systemstate dump。方法可以参考我之前的一篇文章
  • 如果是java进程,可以使用jstack来查看和分析其thread dump。jstack的语法如下:
jstack [-l] <pid>
(to connect to running process)
jstack -F [-m] [-l] <pid>
(to connect to a hung process)

如果问题已经消失并且无法重现,那么则可以通过OSW来查看问题时候操作系统资源占用的情况。我们可以使用sundiag来收集OSW信息,收集方式如下:

# /opt/oracle.SupportTools/sundiag.sh osw

收集完成以后,可以通过osw中的top来确认当时占用系统cpu高的进程,然后再进行下一步计划。

cell的日志中是否有报错信息?

因为cell软件的缺陷是一个比较大的怀疑点,所以这个cell节点的alert也是必需的,请查看问题时间段,以下日志中是否存在错误信息。

/opt/oracle/cell/log/diag/asm/cell/*/trace/alert.log
/opt/oracle/cell/log/diag/asm/cell/*/trace/ms-odl.trc
/opt/oracle/cell/log/diag/asm/cell/*/trace/

如果问题发生时刻出现过rs-600或者rs-7445,请同时收集其trace文件。如果出现类似错误,可以考虑使用adrci来收集错误信息,如何通过incident来收集这一类错误日志,请参考

http://www.dbaleet.org/collect_exadata_diagnostic_info_via_ips/

RS- 600和RS-7445通常跟cell软件的内存泄露有关系,很多情况下会导致这些进程的挂起。而restart server会将挂起的进程自动重启,但是某些情况下可能存在失灵的情况。

以上仅仅为诊断这Exadata Cell节点上CPU高这一类问题的思路,仅供参考。

Exadata不同Cell发生两块以上的坏盘是否会导致数据的丢失?

原文链接:http://www.dbaleet.org/what_if_two_disks_reside_different_cell_failure_will_lead_to_data_corruption/

在 如何升级Exadata 存储节点cell image这一篇文章中提到:在升级一个cell的过程中,由于此时这个cell的所有的磁盘都是离线的,这个cell上的盘没有被drop并且完成镜像的重组,那么也就意味着这个cell上的所有的数据在其它cell中只有一份镜像,假如其它cell节点此时同时出现了坏盘,则有可能导致数据的丢失。

有个同学追问道: 是不是只要是不不同Cell同时发生两块以上的坏盘是否会导致数据的丢失?如果不是,那么是我有没有办法知道是哪些盘损坏可能造成数据丢失?这个概率有多大?相比传统的raid 10相比如何?

我想说: theses are  really good questions,but you just asked too many. 天气太热,记得多喝水。

回到正题上,这个课题其它可以写满满一篇论文了,尤其是后面那个概率的问题。我这里只是简单的描述下,因为大多数人不要关心如此多的细节。Anyway, we are engineers, not scientist.

我们知道, ASM与传统的RAID技术的冗余方式并不一样,ASM不是以disk而是以extent为单位的,而这些extents会分布在多块磁盘中,此时ASM引入概念将其称为Partner DIsk, 这些Partner disk会有系统分配放置在一个或者多个failure group上。假如其中的一块磁盘操作失败,那么ASM会更新其extent map,然后只对其正常状态的Partner disk进行操作。注意:以上只是针对ASM Normal Redundancy而言,External Redundancy没有partner disk的概念。

在10g版本中,ASM failure group中的每一块盘都会存在最多10个DIsk partner,而在11gR2中默认的disk partner 的数量为8, 它是受到隐含参数”_asm_partner_target_disk_part”控制的。也就是说,对这块盘的数据镜像分布在其它8块partner disk中。

在一台1/4配的Exadata中,通过以下SQL查询 group#=1 disk#=0的partner disk的分布情况。

select DISK, NUMBER_KFDPARTNER, NAME, FAILGROUP
from V$ASM_DISK A, X$KFDPARTNER B
where DISK = 0
and GRP=1
and B.NUMBER_KFDPARTNER = A.DISK_NUMBER
and name like 'DATA%'
order by NUMBER_KFDPARTNER asc
/

DISK NUMBER_KFDPARTNER NAME FAILGROUP
---------- ----------------- ------------------------------ ------------------------------
0 16 DATA_DM01_CD_04_DM01CEL02 DM01CEL02
0 18 DATA_DM01_CD_06_DM01CEL02 DM01CEL02
0 20 DATA_DM01_CD_08_DM01CEL02 DM01CEL02
0 21 DATA_DM01_CD_09_DM01CEL02 DM01CEL02
0 28 DATA_DM01_CD_04_DM01CEL03 DM01CEL03
0 29 DATA_DM01_CD_05_DM01CEL03 DM01CEL03
0 30 DATA_DM01_CD_06_DM01CEL03 DM01CEL03
0 34 DATA_DM01_CD_10_DM01CEL03 DM01CEL03

可以看到这块盘的对应的partner disk包括:cell2 的disk16, disk18, disk20, disk21和cell3 的disk28, disk29, disk30, disk34。如果对一些互为Partner disk的磁盘同时不可写,那么会导致这个disk所在的diskgroup强行的dismount,从而发生数据的丢失和不可用。

ASM的这种冗余方式与传统的RAID相比,并不会增加其丢失数据的概率。Pythion的Alex Gorbachev有一个slice对两者的故障容忍率进行过专门的分析和对比,需要进一步了解的同学请走次传送门

Under the Hood of Oracle ASM: Failability Analysis

以上

Exadata Flash Cache Compression名不副实的特性

http://www.dbaleet.org/uncover_the_secret_of_exadata_flash_cache_compression/

Exadata X4的更新主要是集中在硬件层面的更新换代以及改进,相对硬件而言,软件层面的新特性乏善可陈,大多数集中在一些小细节的完善。

当然也有令人“眼前一亮”的新特性,比如Exadata Flash Cache Compression, 在Oracle的官方关于Exadata X4新特性介绍的ppt中,我们可以找到如下关于Exadata Flash Cache Compression的介绍:

有几个关键词看上去是“人见人爱,花见花开”:

1. 自动压缩/解压(automatic compressed/decompressed)

2. flashcache能存储多达2倍的数据(up to 2x more data)

3. 硬件级的压缩解压,零额外开销(implemented in hardware, zero performance overhead )

4. 支持Exadata X3和 Exadata X4 (supported on X3 and X4 storage servers)

官方没有提供更多的实现细节,但是告知如果需要使用这个特性,就需要在cell一段启用高级压缩的特性(Advanced Compression Option),

CellCLI> alter cell flashCacheCompress=TRUE

而高解压缩的特性是一个独立的组件,需要额外的license。

Oracle Advanced Compression Option must be licensed  to enable flash cache compression.

看到这里,根据一般人的理解,Exadata Smart Flash Cache Compression的工作原理应该是:

当有数据存入到Exadata Flash Cache的时候,数据会使用Oracle的高级压缩选项进行压缩,压缩是在硬件级完成的,所以这个过程非常快,近似的可以认为是零开销。同理,当数据库需要从Exadata Flash Cache中读取数据的时候,Exadata的F40/F80加速卡会自动将其解压,同样这个过程实在闪存卡的控制器这一端来完成的。整个压缩解压过程对于数据库而言是透明的,不需要进行人为干预。

看上去这种解释合情合理,但是仔细想想有几个问题实际上很让人感觉很诡异:

1. 如果压缩和解压是在硬件级别完成的,那么为什么还需要单独手工启用这个高级压缩的选项?
2. 如果压缩和解压是在硬件级别完成的,F40卡就可以使用了,那么这个版本到底更新了什么?
3. 如果压缩和解压使用的是Oracle的高级压缩选项,那么压缩的比例为什么最高达两倍的容量?

通过一番google以后,可以得到如下结论:

1. 目前确实存在硬件级别自动的压缩和解压的闪存卡,并且压缩和解压是在闪盘控制器这个层面来完成的;
2. 这种算法属于SandForce专利算法,SandForce后来被LSI公司收购,成为LSI公司的闪存部门,Oracle/Sun目前没有类似的专利;
3. 根据各项指标的匹配程度来看,Sun F40卡应该是LSI Nytro Warpdrive BLP4-400的OEM版,而F80卡则是LSI Nytro Warpdrive BLP4-800的OEM版本。

既然硬件硬件是OEM了LSI的闪存卡,压缩和解压使用的是SandForce的专利算法,那么压缩和解压使用Oracle Advanced Compression Option就是无稽之谈了。那么alter cell flashCacheCompress=TRUE到底打开了什么?可以肯定的这个开关一定不是启用了压缩解压功能。

那么它到底打开了什么功能?

在 MOS文档 1571789.1 中有如下一段话(当然现在已经被删掉了):

Flash cache compression dynamically increases the logical capacity of the flash cache by transparently compressing user data as it is loaded into the flash cache. This allows much more data to be kept in flash, and decreases the need to access data on disk drives. The I/Os to data in flash are orders of magnitude faster than the I/Os to data on disk. The compression and decompression operations are completely transparent to the application and database, and have no performance overhead whatsoever, even when running at rates of millions of I/Os per second. Please refer to and satisfy the additional database licensing requirements listed in the Exadata Licensing Guide before enabling this feature.

我们可以认为一块F80卡的容量为800GB,正常情况下,用户存储在F80卡中的数据都是通过闪存卡的主控进行压缩以后的结果,假如压缩的比例是2倍,这并不意味这你可以向这张F80卡中保存1.6TB的数据。理论上物理可寻址的空间为1.6TB,而默认情况下逻辑可寻址的空间只有800GB,所以保存的数据因为受到其逻辑可寻址限制最多也只能保存800GB,其余的物理空间即使是剩余的也是无法使用的。

因此alter cell flashCacheCompress=TRUE的作用实际上是解除了闪存卡逻辑寻址的限制。也就是说设置这个参数以后,原来逻辑不可寻址的另外一半物理空间现在变成可寻址了,此限制解除以后,最直接的影响是增加了闪存卡的可用空间,例如一块F80卡经压缩后保存的数据实际上能达到1.6TB。

所以,Exadata Smart Flash Cache Compression需要高级压缩组建(Oracle Advanced Compression Option)更多是一种商业上的策略,而非技术本身的因素,要知道ACO的license可不便宜,每个核心需要大约10k美刀,看来Larry Elison真是生财有道呀。

Exadata的配置工具——Exaconf

http://www.dbaleet.org/exadata_configuration_tools_exaconf/

上两篇文章介绍了的Exadata的配置工具dbm configurator, dbm configurator功能很强大,并且一直是Exadata默认的配置工具,但是存在以下几个明显的缺点

 

1. 不跨平台

dbm configurator 是使用基于Microsoft Office 2007 宏开发的,如果不使用Windows平台(老外用Mac的人很多),则无法进行配置。即使是Windows平台,如果Office不是2007版本,也可能存在兼容性的问题。

2. 缺乏向导

dbm configurator工具的好处就是一目了然,从一个文件可以一眼看到所有的配置信息,但是需要配置的信息太多,看上去非常复杂,用户需要一个step-by-step向导式的配置模式就更好了,并且dbm configurator在生成配置以前无法进行错误检查。

3. 对于非标准配置支持较差

dbm configurator可以很方便的配置出标准规格的Exadata,但是对于非标准的配置则比较麻烦,例如用户在购买一个半配(half)的基础之上可能希望再增加1个DB节点,或者需要增加2个Cell节点,dbm configurator对于这类型的配置支持不是太好。

针对以上问题,在新版的onecommand(Patch 14734044)中增加了一个基于java的向导式的工具Exaconf,全称是Oracle Exadata Deployment Assistant。Oracle推荐用户使用新版的Exaconf进行配置,但是同时也保留了dbm configurator。

在使用这个工具前,请先确保您的机器上安装了JRE 1.5以上的版本。在Exaconf目录下,运行exaconf.sh或者exaconf.cmd(取决于您运行在什么平台之上)。

one picture is worth more than ten thousand words, let’ s get started.

第一步:显示向导,当然这里也可以导入先前的配置文件。

第二步:输入用户信息。

第三步: 输入Exadata的规格。

第四步: 网络配置要求

第五步: 输入管理网的IP信息, 从这里开始,节点主机名默认增加了adm这样的前缀。

第六步: 输入生产网的信息, 从这里开始,节点主机名默认增加了client这样的前缀。

第七步: 输入私网信息。

第八步: 配置备份网信息

第九步:配置操作系统信息。

第十步:配置ASM磁盘组信息。

第十一步:配置Alert信息。

第十二步:配置OCM。

第十三步:配置ASR信息。

第十四步:配置gc agent信息。

第十五步: 审核与确认

第十六步,完成,生成配置文件。

沪ICP备14014813号-2

沪公网安备 31010802001379号