如何升级Exadata 存储节点db image

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

 

相比cell image而言,db image升级的风险要小很多,因为db节点没有存储任何数据。当然为了保证万无一失,在升级db image之前请先做好数据库备份。

在升级过程中db image的版本允许与cell image版本不一致,但是不允许db和cell的image的版本长期不一致,因为有可能潜在版本兼容性的问题。

当前db image补丁的介质为一个iso文件,类似于操作系统的补丁包。在早期的版本中,是使用rpm -UVh这样的方式来更新Exadata db节点的rpm包,这种方式相对比较繁琐,容易出错,所以在以前的版本中存在一种被称为minimal pack的补丁,这个补丁只升级db节点的操作系统内核,firmware, infiniband驱动等重要组建,其它的rpm放在另外一个补丁内,作为可选安装。从11.2.3.1.0开始采用的是Linux的yum来完成的,yum的优势在于简单,并且能自动解决rpm之间的依赖性。可以搭建一台单独的yum server作为yum源,这样所有的db节点作为yum的客户端都从这台服务器获取rpm包,然后进行升级。也可以采用db节点本机作为yum的源,下面就是将db节点本机作为yum源完成一台db节点升级的详细步骤。

  • 将iso文件mount到db节点的一个本地目录;
  • 在db节点安装所需的yum的rpm包;
  • 配置yum的源,将其源地址指定为iso文件挂载的目录;
  • 运行yum update对db节点的所有rpm包进行升级;
  • 删除老版本的rpm包

这一个过程被oracle封装到一个脚本里面,所以整个过程非常简单,只需要运行一个脚本,剩下的工作都交给自动脚本来完成。详细步骤如下:

升级前的准备工作

1.准备db image的patch

下载以下介质并且使用root用户上传到所有db节点的/u01/patches/linux_patches/iso目录下:

db节点的image p16432033_112321_Linux-x86-64.zip

db节点yum包p13741363_112321_Linux-x86-64.zip

解压两个介质安装包:

#cd /u01/patches/linux_patches/iso
#unzip p16432033_112321_Linux-x86-64.zip
#unzip p13741363_112321_Linux-x86-64.zip

解压以后会得到一个名为13741363文件夹和一个名为 112_latest_repo.iso的文件

2. 对dbserver进行备份:

给dbserver_backup.sh文件赋予执行权限:

#chmod +x /u01/patches/linux_patches/13741363/11.2.3.2.1/dbserver_backup.sh

运行备份脚本:

#sh /u01/patches/linux_patches/13741363/11.2.3.2.1/dbserver_backup.sh

整个过程大约需要30分钟:

 

3. 卸载所有的nfs文件系统

如果使用了nfs,请先umount nfs。

 

4. 将iso文件mount到对应的文件系统

 

mkdir -p /mnt/iso/yum/unknown/EXADATA/dbserver/11.2/latest
mount –o loop /u01/patches/linux_patches/iso/ 112_latest_repo_130302.iso \
/mnt/iso/yum/unknown/EXADATA/dbserver/11.2/latest

检查确认mount成功:

#dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -l root 'ls -lrt /mnt/iso/yum/unknown/EXADATA/dbserver/11.2/latest'

 

 升级过程

1. 禁用并停止数据库的crs

#crsctl disable crs
#crsctl stop crs

完成以后使用如下方式进行验证:

#dcli -g dbs_group -l root "ps -ef | grep grid"

2. 安装升级之前安装升级所需的rpm包:

#cd /u01/oracle/linux_patches/13741363/11.2.3.2.1/bootstrap.uln
# ./bootstrap.sh file:///mnt/iso/yum/unknown/EXADATA /dbserver/11.2/latest/x86_64

这个过程将老旧的rpm包升级。花费的时间比较长,一般需要四十分钟左右。

这个过程主机会自动重启两次。

3. 继续完成旧的rpm包升级
重新mount这个iso文件,继续完成rpm包的升级。

mount –o loop /u01/patches/linux_patches/iso/ 112_latest_repo_130302.iso \

/mnt/iso/yum/unknown/EXADATA/dbserver/11.2/latest

cd /u01/oracle/linux_patches/13741363/11.2.3.2.1/bootstrap.uln

 

# ./bootstrap2.sh

 

4. 对oracle二进制文件使用rds进行relink

#/u01/app/11.2.0.3/grid/crs/install/rootcrs.pl –unlock
#su - oracle
#echo $ORACLE_HOME
#echo $PATH
#ls -lrt $ORACLE_HOME
#export ORACLE_HOME=/u01/app/oracle/product/11.2.0.2/dbhome_1
#export PATH=$ORACLE_HOME/bin:$PATH
#cd $ORACLE_HOME/bin
#relink all
#make -C $ORACLE_HOME/rdbms/lib -f ins_rdbms.mk ipc_rds ioracle

5. patch并重新enable crs

#/u01/app/11.2.0.2/grid /crs/install/rootcrs.pl -patch
#/u01/app/11.2.0.2/grid /bin/crsctl enable crs

6. 挂载NFS

如果有nfs,请重新挂在nfs设备。

升级后验证工作

通过以下命令,验证版本信息是否正确:

#dcli -g dbs_group -l root “imageinfo”
#dcli -g dbs_group -l root “imagehistory”
#dcli -g dbs_group -l root “uname -a”
#dcli -g dbs_group -l root “rpm -qa | grep kernel”
#dcli -g dbs_group -l root “rpm -qa | grep ofa”
#dcli -g dbs_group -l root “rpm -qa | grep ofed”

 

查看crs所有资源的状态是否正常:

#crsctl stat res -t

 

Some questions raised by readers regarding Exadata simulator

Some questions raised by readers regarding Exadata simulator

Q1: Hi, Steven, I followed all of your steps but with no luck.  I encountered the below errors while creating flashcache, can you help me with this?

Initialization of celldisk CD_disk06_cell1 on /opt/oracle/cell11.2.3.2.0_LINUX.X64_120713/disks/raw/disk06 completed.
ossmmap_map: mmap failed for DiskHT len: 234881024 as there is insufficient memory
max_mem 3512729600 perm_mem 2991546368 sga 486541016 pga 919080 (bytes)
ALERT: Flash Cache allocation failed. Check trace file for more info.
Cellsrv encountered a fatal signal 11
Errors in file /opt/oracle/cell11.2.3.2.0_LINUX.X64_120713/log/diag/asm/cell/exadata01/trace/svtrc_5627_49.trc  (incident=25):
ORA-07445: exception encountered: core dump [_ZN14FlashCacheCore12fcDeleteCoreEv()+284] [11] [0x000000048] [] [] []
Incident details in: /opt/oracle/cell11.2.3.2.0_LINUX.X64_120713/log/diag/asm/cell/exadata01/incident/incdir_25/svtrc_5627_49_i25.trc
Exception [type: 11] [ADDR:0x48]
Cellsrv encountered a fatal signal 11

 A1: I just have succeeded in reproducing this error in my testing environment. I have the reason to believe that this issue lay in the memory size of your virtual machine. More specifically speaking, if you allocated more than 4 Gigabytes or more memory for your cell vm box, it is likely that you will hit this issue.

Pls reduce your memory size to 3 Gigabytes and it will eventually get fixed.

BTW: I have been using a old lenovo laptop, recently it was replaced by a new model.

 

Q2: I do not know too much about Chinese language though I would learn learn some of them one day while I have opportunity, but can you translated them to  English ?

A2: Thanks for your visiting. I do understand it is might be very difficult to read a language with Google translate you do not familiar with, some of the points might be lost or misunderstood while translating by robots. So I am considering to blog some of my articles in bilingual in  the future, nevertheless, before that most of them would be written in Chinese. Please drop me a line if you think it is valuable to you or it gonna benefit for more audiences.

 

Q3: Can I build this on my Linux Boxes? I mean not in a virtualbox.

A3: Of course you can, but please keep in mind that they are just simulator for testing purpose only and you can not build a fake Exadata.

CellCLI> list cell detail
	 name:              	 cell1
	 bbuTempThreshold:  	 60
	 bbuChargeThreshold:	 800
	 bmcType:           	 absent
	 cellVersion:       	 OSS_11.2.3.2.1_LINUX.X64_130109
	 cpuCount:          	 1
	 diagHistoryDays:   	 7
	 fanCount:          	 1/1
	 fanStatus:         	 normal
	 flashCacheMode:    	 WriteThrough
	 id:                	 5841beec-6ca5-46ea-b2dc-f7778c62f5cd
	 interconnectCount: 	 1
	 interconnect1:     	 eth0
	 iormBoost:         	 0.0
	 ipaddress1:        	 192.168.56.101/24
	 kernelVersion:     	 2.6.18-274.el5
	 makeModel:         	 Fake hardware
	 metricHistoryDays: 	 7
	 offloadEfficiency: 	 1.0
	 powerCount:        	 1/1
	 powerStatus:       	 normal
	 releaseVersion:    	 11.2.3.2.1
	 releaseTrackingBug:	 14522699
	 status:            	 online
	 temperatureReading:	 0.0
	 temperatureStatus: 	 normal
	 upTime:            	 0 days, 0:26
	 cellsrvStatus:     	 stopped
	 msStatus:          	 running
	 rsStatus:          	 running

 

Q4: Do you mind if I am just a little bit too lazy to build a one?

A4: Never mind, If you are having a hard time understanding Chinese. I will upload the  VBox images.Pls note that cell vm image has already been upload to my Google Drive, pls click the following link to download:

https://docs.google.com/file/d/0BwRyLGXt5VmCSERNZFJVUWdmcnc/edit?usp=sharing

I will update this blog if db vm image has been uploaded.

all you have to do is

1. download and install Oracle VirtualBox, Vmware either, whatever.

2. download this image

3. import

4. you are done.

 

Q5: Can you clarity why there is no additional Exadata rpms have to be installed on DB nodes?

A5: That is a good question.

Firstly, I would like to say  it truly does. In fact, most of these features has been merged into Oracle Database binaries,  so you can not enable them if you are not using SAGE as your storage.

Sencondly, iDB, based on RDS, is a protocol running up on infiniband. infiniband drivers which  called OFED is built on Linux kernels. There is no such kind of packages installed on Exadata DB nodes simulator. So with this simulator, offloading is not likely to be working. Someone might argue that (s)he has already observed smart scans via Oracle database waiting events, unfortunately , that is not a truly offloading. It is just a demo to help you understand exadata mechanisms  better, you can not take it as seriously offloading.

Thridly, please note that In real life, db image involves no cell rpms, it only contains firmwares, drivers, kernel rpms, essential rpms for basical Linux etc. It is not necessary to install Exadata firmwares, drivers on a Virtual Machine cause there is no such kind of stuff.

Anyway, I am not from Exadata dev team, above are just my own understanding.

Exadata FAQ: 如何选择Exadata OS?Solaris还是Linux?

http://www.dbaleet.org/exadata-faq_how_to_choose_exadata_os_linux_or_solaris/

在安装Exadata之前,部分客户会问道:既然Exadata的操作系统既可以使用Solaris,又可以使用Linux,那么我应该如何选择?能不能给我们点参考意见?
对于用户而言,没有最好的,只有最合适的。我这里并不想深入的对两个操作系统进行深入的比较,只是谈谈一些事实和个人的意见,仅供参考。当然最终决定权还是用户的手里。
以下列举一些事实:

事实一: 首先并不是Exadata的操作系统既可以使用Solaris,又可以使用Linux。准确的说法应该是DB节点的操作系统可以选择Solaris或者Linux,这里的Solaris不是Sun小型机使用的SPARC架构,而基于Intel/AMD的X86_64架构,也就是说是Solaris i86pc。而cell节点的操作系统只能是Linux。以下除非特别注明,否则Solaris i86pc统称为Solaris。

事实二: Solaris 11 不是一个免费的系统,是需要单独付费license的。参见Oracle Solaris 11 Frequently Asked Questions, Solaris 11只提供30天的评估试用。

 

How can I obtain an Oracle Solaris license for a system
purchased on the open market, given that an Oracle
Solaris license is non-transferable?
For Oracle systems purchased on the open market, you may
obtain a license for Oracle Solaris by purchasing Oracle
Premier Support for Systems. If the system you purchased has
been off of Oracle support for more than 90 days, completion
of the Oracle Premier Support Qualification Service is a
requirement in order to receive Oracle Premier Support for
Systems coverage.

事实三: 在Exadata 11.2.3.1.0 之前, Exadata上运行的Solaris并非是Solaris 11, 而是Solaris 11 Express, 这两者是有区别的,Solaris 11 Express是一个定位非常尴尬的版本,并非适用于生产系统,大多数产品也不会对这个平台进行认证。你可以把它看成是一个开发或者测试版的操作系统,当然Oracle官方肯定不同意我这么说。在MOS文档1431284.1 Upgrading Solaris Exadata Database nodes from Oracle Solaris 11 Express to a latest supported Oracle Solaris 11 11/11 SRU上说Solaris 11 Express将在Exadata使用6月以后不支持, 届时必须升级到Solaris 11 11/11,届时用户又得折腾一番。但是同时要使用Solaris 11.11,又必须使用database 11.2.0.3以上版本,因为更低Database版本没有经过Oracle认证。

NOTE:
Oracle Solaris 11 Express 2010.11 will be desupported for use on Exadata six months after Oracle Solaris 11 2011.11 is available for Exadata on 06-September-2012. Systems running Oracle Solaris 11 Express 2010.11 must be upgraded to Oracle Solaris 11 11/11 before then.
Solaris 11 2011.11 requires Oracle Database 11.2.0.3. It is not certified to run Oracle Database 11.2.0.2 or earlier on Solaris 11 11/11.

事实四: 没有多少Exadata用户使用Solaris作为DB节点的操作系统。 据我所知,在中国区好像是没有。在全球这个比例也是少的可怜,预估这个比例不到10%。

事实五: Solaris的测试没有Linux平台充分,软件发布的速度没有Linux快。因为在Exadata上使用Solaris的用户相对较少,所以必然很多问题没有经过充分测试,至少没有在Linux平台测试充分,而部分软件针对Exadata的软件例如Exachk发布的速度也比较慢。

事实六: 在第四代的Exadata上,Exadata X3-8将不支持Solaris,如果要使用Solaris,只能使用X3-2。

以上六大事实说明(如果愿意,当然我还可以列举更多): 用户选择Solaris作为Exadata的操作系统是不推荐的。除非用户本身是Solaris专家,并且对Linux一无所知,否则请不要选择Solaris。这并不是因为Solaris的问题或者是本人对Solaris有偏见,Solaris本身是一个非常优秀的系统,有很多其它系统没有的高级特性。但是目前它并不适合运行在用户Exadata生产环境之上。如果您是Solaris的fans,并且期望获得与Exadata一样的体验,可以考虑基于SPARC平台的Sparc Suppercluster (SSC)。

最后, 附上一本关于Solaris平台的Exadata特性的白皮书。

What Oracle Solaris Brings to Oracle Exadata Database Machine

以上

Exadata X3-2都有哪些料?

原文链接: http://www.dbaleet.org/what_is_new_in_exadata_x3-2/

 

Oracle在2012年的10月的openworld宣布了最新一代的Exadata一体机X3, 时间已经过去快半年了,但是很少有看到全面介绍X3的中文文章。故我这里以对比的形式列出X2-2和X3-2的软硬件的异同,读者可以通过对比来发掘X3到底都有哪些料。(注:X3-8不在此讨论范围)

 

DB节点

 从上面可以看出最大的一个变化在于CPU从Intel Xeon L5640 (Nehalem平台)升级到了Intel Xeon E5 (Sandy Bridge平台)。Intel宣称Xeon E5充分利用了其睿频(Turbo Frequency (MHz))技术,所以能以更低的主频提供更高的性能,并且单核的电压更低,更省电。以下是CPU world对这两者参数的对比图:

 

其中一个比较显眼的地方是其中Xeon E5支持AVX指令集,Intel声称其能大幅提升浮点运算的性能和Linux平台RAID驱动的性能。关于AVX的性能提升可参看IBM印度工程师Nagarajan Kathiresan的文章http://spscicomp.org/wordpress/wp-content/uploads/2012/05/ScicomP-2012-Prabhakar-Kathiresan-AVX.pdf, 不过从传统的TPC-C以及SPECint的测试对比结果来看,Xeon E5的性能与IBM Power 7大致持平,当然IBM利用其Turbocore技术,在单核上性能有明显的提升,但是就吞吐量而言却显得更慢。

内存方面, 也由原来的X2-2 96G内存升级到X3-2的128G,单个DIMM模块的大小也从原来的8G升级为16G,一台满配的Exadata(8个DB节点)就从原来X2-2的96G×8=768G扩展到X3-2的1TB,另外还有一点就是单个DB节点最大内存限制也从X2-2平台最高144G扩展到了X3-2平台的256G。

网络方面,从原来X2-2的4块千兆以太网网口升级为4块千兆/万兆自适应的以太网网口。但是如果需要使用万兆的以太网,用户依然需要自掏腰包单独购买万兆以太网的SPF+光纤模块。

另外在PCIe总线上,也有原来的PCI-e 2.0升级为PCI-e 3.0, PCI-e总线的带宽理论上提高了1倍,但是同时需要特定的PCI-e 3.0的卡支持。

 

Cell节点

 

相比DB节点而言,Cell节点的升级就显得有些波澜不惊。

CPU方面,6核的E5-2630L 2.0G与6核 Xeon L5640 2.26G性能大致相当,变化不大。

内存方面, 由原来X2-2的24G内存升级到X3-2的64G, 一来是内存颗粒的工艺有了进步,使得内存的价格更低,二来主要是因为闪存卡的容量增加了4倍,需要管理这些闪存卡实际上需要更大的内存做支撑。

闪存卡方面的变化可能是最引人注目的了。Exadata X3之所以号称Database In-Memory Machine, 闪存卡容量是最重要的一个方面了。Exadata的闪存卡从原来X2-2的4×96G=384G直接升级到了X3-2的4×400G=1600G,容量增加了4倍,所以Larry Ellison就单凭借这一点来当作嘲笑SAP hana的砝码。可见波澜不惊只是表面的,实际上还是暗藏汹涌。而新的F40卡相比较F20卡, 更耐擦写,寿命更长,读写的速率也有较大幅度的提升,F40卡的读写速率接近是原来F20卡的1.4倍,其相应的ESM模块的寿命也更长,防止写性能降级。

其他方面

其它组建基本没有太显著的变化。例如硬盘,infiniband交换机, PDU,值得一提的是X3系列去掉了KVM(Keyboard,Video, Mouse)。

 

 

更详细硬件配置信息,请参看X3-2的datasheet

软件

X3为Exadata一体机的第四代,除了硬件的更新以外同样也有软件方面的变化:

1. X3硬件本身的价格和X2保持一致,但是并不是说X3的价格和X2就是一致的,知道为什么了吧?因为Oracle的软件的license都是按照cpu核数来计算的(当然也有按照用户数计算的),DB节点从6核升级到8核,DB license是需要重新计算的,当然Database的license是利旧的。而Exadata Cell的软件是按照磁盘数计算的,磁盘数不变,Cell的license就不变。当然我只是提一下,具体的价格请向销售咨询,anyway, I am not a sales guy.

2. X3 Exadata image运行的最低版本是11.2.3.2.0, 也就是说,X3不支持downgrade到更低的版本,因为X3新的硬件对Exadata固件版本是有依赖的,另外就是从11.2.3.2.0开始,Exadata默认使用UEK的内核,并且在将来的版本移除与Red Hat兼容的内核。Exadata从11.2.3.1.0开始在ULN中建立了专门的Exadata分支,也就是说以后用户可以通过ULN对DB节点进行操作系统和固件的升级。

3. 改进了Exadata磁盘管理的算法。例如在更换磁盘以前,需要蓝灯亮了以后才能更换磁盘。还有就是更进一步改进了磁盘管理的算法。Exadata的自动磁盘管理行为是通过隐含参数 _AUTO_MANAGE_EXADATA_DISKS控制的,参见MOS文档Full details on Auto disk management feature in Exadata (Doc ID 1484274.1)

4. X3的一大杀手锏就是支持Exadata Write Back Flashcache (WBFC), 这个特性使得写操作可以缓存在闪盘中,而闪盘的IOPS远高于磁盘。这个特性使得Exadata真正意义上通吃了OLAP和OLTP。当然X2也可以使用WBFC,但是需要将Exadata和Oracle Database升级到特定的版本以后才能启用这个特性,并且X2的闪盘的容量很小,所以最终效果终究是无法达到X3的程度。我会在以后的blog中陆续介绍WBFC的特性,敬请关注。

以上。

使用IPS收集Exadata的诊断信息

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

IPS是Incident Packaging Service的简称,即事件打包服务。在此之前,能提供打包服务的一般是物流公司,例如Fedex或者UPS。从Oracle 11g开始,Oracle也介入这个行业与他们开始正面竞争了。

 

事件打包服务是FDI(Fault Diagnosability Infrastructure)故障诊断基础架构中的一项技术, 属于ADR的一部分。IPS可以针对某一特定错误或故障相关的数据进行打包,一次性收集诊断此问题需要的日志,例如traces, dumps, health check reports等,免去多次索要和提供日志之苦。Just wait for 1 minutes. 收集日志我用diagcollection.pl脚本不就行了么?何苦还需要另外学习收集日志方式? diagcollection.pl一般用于收集集群某个特定时间段的信息,或者某种特定类型的日志,例如chm;而IPS通常使用来收集数据库或者cell软件的诊断信息,例如可以用它来针对某一错误进行日志收集,例如ORA-00600,这两者并不冲突并且可以互补。

 

在Exadata上除了可以使用IPS收集DB节点的日志信息,还可以使用它来收集Cell节点的日志信息。DB节点的收集方式同样可以用于非Exadata的数据库,Cell节点的收集方式仅用于Exadata。以下分别讲述如何在DB节点和Cell节点使用IPS收集日志信息。我这里并不打算介绍所有的IPS的特性,仅仅只是针对某一错误进行日志收集。

 

DB节点:

        1.  进入adrci界面:
          $adrci
          adrci> help ips
          
           HELP IPS [topic]
             Available Topics:
                  ADD
                  ADD FILE
                  ADD NEW INCIDENTS
                  CHECK REMOTE KEYS
                  COPY IN FILE
                  COPY OUT FILE
                  CREATE PACKAGE
                  DELETE PACKAGE
                  FINALIZE PACKAGE
                  GENERATE PACKAGE
                  GET MANIFEST
                  GET METADATA
                  GET REMOTE KEYS
                  PACK
                  REMOVE
                  REMOVE FILE
                  SET CONFIGURATION
                  SHOW CONFIGURATION
                  SHOW FILES
                  SHOW INCIDENTS
                  UNPACK FILE
                  USE REMOTE KEYS
        2. 设置ADR HOME:
          adrci> show home
          
          adrci> set homepath  /u01/app/oracle/diag/rdbms/dbm/dbm1/
        3. 查看问题:
          adrci> show problem 
          ADR Home = /u01/app/oracle/diag/rdbms/dbm/dbm1:
          *************************************************************************
          PROBLEM_ID PROBLEM_KEY LAST_INCIDENT LASTINC_TIME
          -------------------- ----------------------------------------------------------- -------------------- ---------------------------------------- 
           1 ORA 7445 [kfkrqDump()+30] 1964325 2012-09-23 23:35:08.763000 +08:00
          1 rows fetched
          adrci> show incident -p "problem_key='ORA 7445 [kfkrqDump()+30]'"
          ADR Home = /u01/app/oracle/diag/rdbms/dbm/dbm1:
           *************************************************************************
           INCIDENT_ID PROBLEM_KEY CREATE_TIME 
           -------------------- ----------------------------------------------------------- ---------------------------------------- 
           1964325 ORA 7445 [kfkrqDump()+30] 2012-09-23 23:35:08.763000 +08:00
           1 rows fetched
        4. 生成此问题的IPS包:
adrci> ips pack incident 1964325 in /u01/app/oracle/admin

 Generated package 3 in file /u01/app/oracle/admin/ORA7445kf_20120924090018_COM_1.zip, mode complete

DB节点的一个IPS包就生成好了。

Cell节点:

Cell节点的IPS与DB节点的IPS差异并不大,但是它会额外收集以下信息:

1. Restart Server trace文件:rstrc_<pid>_<tid>.tr*
2. Cell Server trace文件: svtrc_<pid>_<tid>.tr*
3. Management Server trace文件
4. ms-odl.log文件
5. Cell的alert log文件

以下演示如何在Cell节点上使用IPS收集Cell的诊断信息:

  •  检查环境:
# env |grep ADR
ADR_BASE=/opt/oracle/cell11.2.2.2.0_LINUX.X64_101206.2/log
# which adrci
/opt/oracle/cell11.2.2.2.0_LINUX.X64_101206.2/cellsrv/bin/adrci
# which celldiag.pl
/opt/oracle/cell11.2.2.2.0_LINUX.X64_101206.2/cellsrv/bin/celldiag.pl
  •  查看事件信息
#/opt/oracle/cell11.2.2.2.0_LINUX.X64_101206.2/cellsrv/bin/adrci
adrci> set homepath diag/asm/cell/dmorlx8cel06
adrci> show problem

ADR Home = /opt/oracle/cell11.2.2.2.0_LINUX.X64_101206.2/log/diag/asm/cell/dmorlx8cel06:
*************************************************************************
PROBLEM_ID           PROBLEM_KEY            INCIDENT        LASTINC_TIME               
-------------------- -----------------------------------------------------
1                    RS 7445                  1              2011-01-12 18:09:16.759000 -05:00
1 rows fetched
adrci> show incident -p "problem_key='RS 7445'"

ADR Home = /opt/oracle/cell11.2.2.2.0_LINUX.X64_101206.2/log/diag/asm/cell/dmorlx8cel06:
*************************************************************************
INCIDENT_ID          PROBLEM_KEY             CREATE_TIME
-------------------- -------------------------------------------------
1                    RS 7445                2011-01-12 18:09:16.759000 -05:00
1 rows fetched
  • 收集错误信息:
adrci>  ips pack incident 1 in /tmp/
diag/asm/cell/dmorlx8cel06 Generated package 1 in file /tmp/RS7445_20110805074355_COM_1.zip, mode complete

当在Exadata上运行IPS的时候, 系统会自动检查celldiag.pl脚本是否存在, 如果这个脚本存在,那么IPS会在ADR的输出中放入这个脚本的输出,并且调用这个目录作为一个它的参数使用。celldiag.pl调用的语法如下:

./celldiag.pl -adr <file_destination> -aftertime <start_time> -beforetime <end_time> -level typical

 

用户可以手工执行这个脚本:

# /opt/oracle/cell11.2.2.2.0_LINUX.X64_101206.2/cellsrv/bin/celldiag.pl -adr /tmp/adrci -aftertime 201101120000 -beforetime 20110130000 -level all

这个脚本主要收集一些系统信息:例如meminfo, cpuinfo,/var/log/messages 以及一些ADR中不存在的trace文件(ms.err, oss<pid>.trc)。

收集完以后,就可以把上述使用IPS生成的zip包上传到MOS对应的SR中供Oracle Support分析。

以上

如何修改Exadata的密码?

http://www.dbaleet.org/how_to_modify_the_password_of_exadata

 

Exadata上的密码可谓是纷繁复杂,名目繁多。总的来说可以分为两类,一类是数据库的密码,另外一类则是操作系统用户的密码。通常在安装完Exadata以后,客户会收到一份初始的密码表,上面列出了所有以后可能用到的各类密码。例如:

DB节点:
The root password for all database servers is welcome1
The oracle password has been set to welcome
All oracle database passwords are welcome
The ASMSNMP password is welcome1
The ILOM username and password is root/welcome1
Cell节点:
The root password for all storage servers is welcome1
The celladmin password for all storage servers is welcome
The ILOM username and password is root/welcome1

PDU:
The PDUs username/password of admin/admin

KVM:
The KVM username/password of Admin/welcome1

infiniband交换机:
The infiniband switch username/password of root/welcome1

思科以太网交换机:
The Cisco Ethernet Switch username/password of root/welcome1

要知道默认密码很多人都是知道的, 万一被心怀不轨的人利用则后果可能很严重。如果不对其进行修改,则很会加大系统的安全风险。当然相信很少有客户不对其默认的密码进行修改。以下简要介绍如何修改Exadata操作系统的密码。

DB节点:

OS用户名: root, grid, oracle

修改方式:使用root登录到主机:然后在命令提示符下输入:

passwd 用户名, 然后按照提示输入新的密码;

例如修改默认root的密码:

#passwd root

如果所有的DB节点使用相同的密码则可以使用如下命令完成:

 #PASSWORD=your_new_password
 #dcli -l root -g ~/dbs_group "echo ${PASSWORD} | passwd --stdin root"

Cell节点:

OS用户名: root, celladmin, cellmonitor

修改方式与DB节点一致。如果所有的Cell节点使用相同的密码, 则同样可以使用如下命令完成:

 #PASSWORD=your_new_password
 #dcli -l root -g ~/cell_group "echo ${PASSWORD} | passwd --stdin root"

ILOM:

使用ILOM登录

# ssh -l ilom-admin <node-name>

-> set /SP/users/root password

 

KVM:

登录KVM,在User Accounts选择Local;
在 “Users” 点击 “Admin” 然后输入密码;点击“Save”保存。

infiniband交换机:

用户名: root, ilom-admin, ilom-user, ilom-operator, and nm2user

使用ssh登录,使用version查看当前的版本,如果是1.3.*, 则需要使用
ILOM来修改密码,规避bug 13494021

# ssh -l ilom-admin <switch-name>
# set /SP/users/<username> password

在此以后的版本可以使用操作系统命令直接修改:

#passwd <username>

思科以太网交换机:

使用telnet登录到思科交换机:

- Switch>enable
Password:
Switch#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)#enable password <new password>
Switch(config)#enable secret <new password>
The enable secret you have chosen is the same as your enable password.
This is not recommended. Re-enter the enable secret.
Switch(config)#end
Switch#write memory

 

PDU:

用户名:admin

在浏览器中输入pdu的ip地址:

点击Net Configuration并使用admin用户登录;

在页面底部找到Admin/User模块;

在Admin/User输入用户名和密码以及是否为管理员用户;

点击提交,保存。

 

以上

如何修改Exadata密码策略?

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

 

使用onecommand安装Exadata的最后一个步骤会执行一个叫做ResecureMachine的过程。这个过程的主要目的就是对操作系统本身进行一些必要的安全加固。例如:设置ssh的登录超时,移除root用户的等效性,对密码进行策略进行加强等。但是这个过程增强了Exadata安全的同时,也给很多Exadata造成了一些不必要的麻烦。以下来自用户经常遇到的一些与密码有关系的case:

 

case 1: 无法从oracle用户/grid su到root用户;

 

[oracle@dm01db01 ~]$ su - root
Password:
su: incorrect password

原因: oracle用户/grid用户不再wheel用户组,所以无法su到root。这是系统默认的行为:

解决方法: 退出以后,直接使用root登录。不从oracle/grid之类的用户su到root。

解除限制:将这些用户加入到wheel组。

#usermod -aG wheel <username>

case 2: 用户需要修改密码, 但是无论怎么输入都无法达到密码复杂度的要求;

原因: Exadata在做ResecureMachine这个步骤修改了pam_passwdqc中的密码复杂度的要求。

解决方法: 选择复杂度更高的密码。

解除限制: 去掉了pam_passwdqc中的密码复杂度限制。

#vi /etc/pam.d/system-auth

将其中的min=disabled,disabled,16,12,8替换为min=1,1,1,1,1。这样你就可以将密码设置为任何值。如果需要明白修改代表什么意思,请查看pam_passwdqc的manpage: http://linux.die.net/man/8/pam_passwdqc

 

case3: 用户因为输入密码多次错误,导致操作系统用户被锁;

这种情况解决的方法比较复杂,留到下篇文章。

 

case 4: 90天后,用户密码过期,需要重置;

原因: ResecureMachine这个步骤修改了密码的过期策略。

解决方法:

达到90天阈值以后,用户手工修改这些用户的密码。

解除限制:

#chage -d 14000 -E -1 -m 0 -M -1 <username>

或者

#chage -M 99999 <username>

其中username表示需要修改的用户名称,需要修改的用户包括DB节点的root, oracle, grid用户;cell节点上的root, celladmin, cellmonitor用户。
case 5: 输错一次密码以后,此用户被锁10分钟;

原因: Exadata在做ResecureMachine这个步骤设置了输入错误对其进行锁定的限制。

解决方法:过10分钟以后再登录,并且输入正确的密码。

解除限制: 将/etc/pam.d/sshd 和 /etc/pam.d/login这两个文件中的lock_time条目移除。即将

auth required pam_tally2.so deny=5 onerr=fail lock_time=600
修改为
auth required pam_tally2.so deny=5 onerr=fail

 

case 6: 节点之间ssh的连通性被移除;

解决方法:ssh的连通性不是必需的,只是在管理上稍微不是太方便。

原因: Exadata在做ResecureMachine这个步骤移除了ssh root用户等效性。

解除限制:

运行/opt/oracle.SupportTools/onecommand/setssh-Linux.sh脚本或者

/opt/oracle.SupportTools/setup_ssh_eq.sh脚本(取决于你所在的版本)手工建立用户等效性。

 

case 7: ssh登录自动超时;

原因: Exadata在做ResecureMachine这个步骤设置了ssh的登录自动超时。

解决方法:重新登录

解除限制:

#dcli -g all_group -l root "cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig; sed -i 's/^ClientAliveInterval/#ClientAliveInterval/' /etc/ssh/sshd_config; service sshd restart"

#dcli -g all_group -l root "cp /etc/profile /etc/profile.orig; sed -i 's/^TMOUT/#TMOUT/' /etc/profile"

令人乍舌的Exadata版本号

http://www.dbaleet.org/exadata_version_what_a_surprise

在版本号领域一直存在着这么一些传说:

1. 从2008年9月开始到2012年11月,Google Chrome 版本号从1.0一路狂飙到25.0, 每六周发布一个新版本,当之无愧版本帝,远远甩开老牌浏览器firefox(这家伙也被带坏了), IE, Opera

2. 腾讯qq,如果你要问我腾讯最大的创新是什么?我会告诉你是它前无古人,后无来者,惊天地,泣鬼神的版本号: qq2010 正式稳定版,正式beta版,beta稳定版,beta正式版,稳定beta版等等,可谓开创了一个历史的新纪元。

3. foobar版本, 一个做了10年的软件一度都是不停在刷0.9,我曾一度以为它会9到天荒地老,最终也还是迈向1.0, 不得不令人感慨2012终究是来了。

以上仅仅吐槽几句,本不该出现在这里,请自觉忘记。

 

1. 以下是Exadata版本与其对应的操作系统版本,内核版本,OFED版本,Exadata不支持手工单独修改/升级操作系统,内核,ofed,hca固件版本。

Exadata版本 操作系统版本 内核版本 OFED版本
11.2.3.2.0 OL5.8 Default: 2.6.32-400.1.1.el5uek
Optional: 2.6.18-308.8.2.0.1.el5
1.5.1-4.0.58
11.2.3.1.1 OL 5.7 2.6.18-274.18.1.0.1 1.5.1-4.0.58
11.2.3.1.0 OL 5.7 2.6.18-274.18.1.0.1 1.5.1-4.0.58
11.2.2.4.2 OL 5.5 2.6.18-238.12.2.0.2 1.5.1-4.0.53
11.2.2.4.1 OL 5.5 2.6.18-238.12.2.0.2 1.5.1-4.0.53
11.2.2.4.0 OL 5.5 2.6.18-238.12.2.0.2 1.5.1-4.0.53
11.2.2.3.5 OL 5.5 2.6.18-194.3.1.0.4 1.5.1-4.0.50
11.2.2.3.3 OL 5.5 2.6.18-194.3.1.0.4 1.5.1-4.0.47
11.2.2.3.2 OL 5.5 2.6.18-194.3.1.0.4 1.5.1-4.0.47
11.2.2.3.1 OL 5.5 2.6.18-194.3.1.0.4 1.5.1-4.0.47
11.2.2.2.2 OL 5.5 2.6.18-194.3.1.0.4 1.5.1-4.0.40
11.2.2.2.0 OL 5.5 2.6.18-194.3.1.0.3 1.5.1-4.0.28
11.2.2.1.1 OL 5.5 2.6.18-194.3.1.0.3 1.4.2-14
11.2.2.1.0 OL 5.5 2.6.18-194.3.1.0.3 1.4.2-14

在11.2.3.1以下DB节点有所谓的minimal bundle,这种patch只升级内核,OFED,固件等,不升级对应的操作系统,也就是说大多数非关键性的rpm包没有升级。11.2.3.1以后取消了这种升级模式。

为了方面排版以下单独把infiniband HCA固件版本列出:

Exadata版本 InfiniBand HCA 固件版本
11.2.3.2.0
11.2.3.1.1
11.2.3.1.0
11.2.2.4.2
11.2.2.4.1
11.2.2.4.0
11.2.2.3.5
11.2.2.3.3
11.2.2.3.2
11.2.2.3.1
For PSID SUN0160000002: 2.7.8130
For PSID SUN0170000009: 2.7.8130
For PSID SUN0150000001: 2.7.0
For PSID HP_09D0000001: 2.7.0
11.2.2.2.2
11.2.2.2.0
11.2.2.1.1
11.2.2.1.0
For PSID SUN0160000002: 2.7.8100
For PSID SUN0170000009: 2.7.8100
For PSID SUN0150000001: 2.7.0
For PSID HP_09D0000001: 2.7.0

3. 以下列出数据库版本,infiniband交换机固件版本, infiniband交换机固件版本与Exadata版本之间的依赖关系:

数据库版本 最低Exadata版本
11.2.0.3 11.2.2.4.0
11.2.0.2 11.2.2.x
11.2.0.1 11.2.1.x
Exadata 版本 最低Infiniband交换机固件版本
11.2.2.2.2+ 1.1.3-2
11.2.2.2.0 1.0.1-1

注: 如果当前在11.2.0.1数据库版本,如果Exadata需要升级到 11.2.3.1, 则需要先打11.2.0.1 BP12 Patch+13998273。

3. 以下是onecomand默认安装的BP:(onecommand没有版本号,每次发布都以patch号形式发布)

OneCommand补丁号 Versions Installed
Patch 14734044 11.2.0.3.11 – Oct 2012 or 11.2.0.2 BP17
Patch 14617927 11.2.0.3.10 – Sep 2012 or 11.2.0.2 BP17
Patch 14401706 11.2.0.3.9 – Aug 2012 or 11.2.0.2 BP17
Patch 14300737 11.2.0.3.8 – Jul 2012 or 11.2.0.2 BP17
Patch 14210449 11.2.0.3.7 – Jun 2012 or 11.2.0.2 BP16
Patch 14028866 11.2.0.3.6 – May 2012 or 11.2.0.2 BP16
Patch 14004092 11.2.0.3.5 – Apr 2012 or 11.2.0.2 BP16
Patch 13710456 11.2.0.3.3 – Feb 2012 or 11.2.0.2 BP14
Patch 13612149 11.2.0.3.2 – Jan 2012 QDPE
Patch 13593012 11.2.0.2 BP13

从上面看到首个支持11.2.0.3的onecommand的patch号是:13612149,以后发布的onecommand既可以安装11.2.0.2又可以安装11.2.0.3, 直到不再支持11.2.0.2(目前X3系列还支持)。另外还有就是虽然2012年10月发布了11.2.0.2的BP18, 但是最新的onecommand却默认没有安装BP18, 而是安装BP17。

4. 有一些固件版本在上面没有列出,但是LOM, BIOS, LSI HBA磁盘控制器, Seagate, Hitachi, SAS, flash, FMOD的固件版本都没有列出,但它们确实存在,当然Oracle也不支持客户单独升级这些固件。

5. 有一些特性是在特定版本以后才加入的,例如ASR, 3T SAS盘, exadata smart flash cache write-back等,也是有一定版本依赖的。

6. 还有有些组件是独立的,没有任何依赖关系。可以单独对其进行升级来解决一些bug,例如kvm,pdu的固件。

Exadata囊括了很多组件,每个组件本质都是独立的,有自己的版本。但是作为一体机,Oracle却并不希望用户过多的关注版本信息,如果每个组件都可以单独进行升级,则会大大增加其复杂度,而破坏了其一体性。最终有可能导致升级,故障诊断等变得不可能,所以一体机不得不以牺牲灵活性为代价换取最佳实践和体验一致性。

这个故事您或许听说过,因为它本身是真实的。某用户Exadata阵列的电池没电了,其cache自动从write-back变为write-through,影响到数据库的读写性能。这个时候本来换电池就可以解决的问题,但是因为这款电池刚好停产了,最终的方案变为 升级infiniband交换机固件到1.1.3-2->升级infiniband交换机固件到1.3.3-2->给11.2.0.1 GI打BP6->给11.2.0.1 RDBMS打BP12->升级Exadata Cell的Image到11.2.2.4.2->升级Exadata DB的Image到11.2.2.4.2->更换电池。原因只是因为客户Exadata版本太老,老的raid控制器固件版本不支持新型号的电池,如果要用新电池则必须升级Exadata版本,升级Exadata版本如果要使用rolling的方式必须将GI和RDBMS升级,并且需要最终升级到的Exadata Image版本对infiniband交换机版本还有依赖,不得不升级infiniband,而且infiniband还需要升级两个版本。

综上,Exadata的版本信息及其依赖性是Exadata入门的第一步,因为它是与Exadata上软件相关一切的基础。我也会在以后逐步介绍Exadata的安装,升级,故障诊断,最佳实践,性能调整等,敬请围观。

以上

Exadata Cell的命令行工具CellCLI

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

 

CellCLI也许远远并没有你想象中的那么复杂,它仅仅是一个管理Exadata Cell存储节点的一个命令行工具。这个工具有点类似于Oracle数据库中的sqlplus命令行,它是用户与Exadata Cell交互的一个接口。

 

 

Cell软件使用的是java构建的,天生具有跨平台的能力。也就意味着Exadata从技术上来说, Exadata是可以移植到任何平台的,但是限于市场策略,Oracle的公司绝不会这么做,所以目前仅仅有基于自家Oracle Linux平台和Solaris平台的Exadata。CellCLI使用了部分开源项目,例如其语法分析工具使用的是 BYACC/J, 而其命令行历史信息工具使用的是JLine,这些工具是基于BSD协议的,所以可以用于商业用途并且无需开源。由于其本身完成的工作量有限,所有CellCLI甚至有望移植到其它平台例如windows的客户端。

1. CellCLI的语法

CellCLI在设计之初就考虑到了其语法的移植性,所以CellCLI的语法与sqlplus以及SQL的语法非常类似,具有sqlplus和SQL经验的dba无需经过一个新的语法学习过程就能使用它。以下举例说明CellCLI的语法:

  • CellCLI具有sqlplus中同样的命令:
EXIT/QUIT: 退出CellCLI命令行;
HELP: CellCLI的语法帮助;
SET : 设置CellCLI的环境变量;
SPOOL: 将命令行结果写入到本地一个日志文件;
START/@: 运行CellCLI的脚本
  • CellCLI的语法结果:

CellCLI命令行语法基本结构如下:

 <verb> <object-type>  [ALL |object-name] [<options>]

其中CellCLI verb(动词)包括:ALTER, CREATE, DROP,  LIST 分别代表修改,创建,删除和查看。

CellCLI的object-type(对象类型)一共包括三类:

资源配置相关的对象:
CELL, CELLDISK, GRIDDISK, IORMPLAN, KEY, LUN, PHYSICALDISK,

性能指标相关的对象:
ACTIVEREQUEST, METRICCURRENT, METRICDEFINITION, METRICHISTORY

失败告警相关的对象:
ALERTDEFINITION, ALERTHISTORY,THRESHOLD.

Tips: 以上标黑的属性不可修改或者删除,只能用于查看(list)

以下简单举几常用到的列子:

列举对象类型的属性:describe命令, 但是无法使用Oracle数据库的语法desc:

CellCLI> describe griddisk
        name                    modifiable
        availableTo             modifiable
        cellDisk
        comment                 modifiable
        creationTime
        errorCount
        id
        offset
        size                    modifiable
        status

列举资源对象的名称及状态,直接使用list命令就可以了:

CellCLI> list physicaldisk
         34:0            xxxxxx                  normal
         34:1            xxxxxx                  normal
......

如果需要查看详细信息,则需要加上detail关键字:

CellCLI> list physicaldisk detail
         name:                   34:0
         deviceId:               33
         diskType:               HardDisk
         enclosureDeviceId:      34
         errMediaCount:          0
         errOtherCount:          0
         foreignState:           false
         luns:                   0_0
         makeModel:              "SEAGATE ST360057SSUN600G"
         physicalFirmware:       0805
         physicalInsertTime:     2012-10-14T18:38:12+08:00
         physicalInterface:      sas
         physicalSerial:         XXXXXX
         physicalSize:           558.9109999993816G
         slotNumber:             0
         status:                 normal
......

如果要列出此资源对象的所有属性,则需要加上关键字all:

CellCLI> list physicaldisk attributes all
         34:0            33              HardDisk        34                      0       0                               false   0_0                     "SEAGATE ST360057SSUN600G"      0805                    2012-10-14T18:38:12+08:00       sas     xxxxxx  558.9109999993816G      0       normal
......

如果只需要列举出部分所需要的属性,则可以使用关键字attributes加上属性名称,多个属性用逗号隔开:

CellCLI> list physicaldisk attributes name, disktype, makemodel, physicalrpm, physicalport, status
         34:0            HardDisk        "SEAGATE ST360057SSUN600G"      normal
......

如果要使用过滤条件,则需要使用关键字where加过滤条件:

list physicaldisk attributes name, physicalInterface, physicalInsertTime  where disktype = 'HardDisk'

         34:0    sas 2012-10-14T18:38:12+08:00
......

Kerry Osborne甚至还总结了其与sqlplus/SQL的相似之处并列举出CellCLI Top 10 List, 参见:

http://kerryosborne.oracle-guy.com/2010/11/cellcli-command-syntax-top-10/

3. CellCLI的解析过程

以下是使用伪代码描述CellCLI解析用户发送的命令行的过程 :

BEGIN
IF command IN ('help', 'describe', 'set', 'spool', 'start')
THEN send to cellcli;
ELSE IF command IN ('alter cell startup services', 'alter cell shutdown services')
THEN send to rs;
ELSE IF command ==  ('calibrate')
THEN send to orion;
ELSE
send to ms;
END

简单的说分为四个步骤:

1. 如果命令行是 ’help’, ‘describe’, ‘set’, ‘spool’, ‘start’,  则将其将给cellcli本身来处理;
2. 如果命令行是启动或者关闭cell服务,则将其发送给rs(Restart Server);
3. 如果命令行是calibrate, 则将其服务发送给orion;
4. 其它情况将其发送给ms(Management Server)。

2. CellCLI命令选项

cellcli可以直接在shell下进行调用,所以进入CELLCLI>命令提示符并不是必须的,这主要是为了方便使用脚本对其进行管理。例如在shell下,我们可以使用cellcli -e “list physicaldisk”, 其产生的结果与在CELLCLI>下运行list physicaldisk效果一样。其中e代表执行(execute)。除了-e选项以外,还有-n代表非交互模式(non-interactive), port-number代表端口号,默认端口为8888, 但是实际这个端口是可以在cellinit中自定义的。

当然cellcli绝对不止这三个选项,还有一些文档没有记录的隐藏选项:例如-d 代表debug模式, -v 代表verbose。

以上

Exadata Cell 隐含参数的获取方式与反向负载转移(reverse offloading)

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

Exadata一体机的offloading有一个很重要的功能就是db节点和cell节点之间的负载可以互相感知。

例如数据库节点大量使用smart scan,smart scan把负载offload到cell一端,在某些情况下,可能导致cell节点的cpu负载过高,甚至过载的情况。相反db节点由于把负载offload到cell节点反而比较空闲。

在这种情况下reverse offloading就派上用场了,cell如果发现cpu的占用率过高,这个时候会将一部分原本使用smart scan的查询不使用smart I/O过滤, 而是直接使用普通db的block I/O返回给db节点以缓解cell节点CPU的负载,等到cell的负载降下来,再次smart scan, 这个过程就叫做reverse offloading。当然如果此时发现db节点的CPU也很高,那么cell就不返回block I/O的数据块。整个这个过程对于数据来说是透明的。

所以在某些情况下,不要相信Exadata不需要索引的传言,即使所有的扫描都是smart scan!
也并不是说只要可能走smart scan,就一定非要强制其进行smart scan。如果smart scan过度很可能导致cell节点的cpu非常高,这个时候建立合适的索引不适用smart scan未尝不是明智之举。

有几个专有的统计信息叫做“cell physical IO bytes sent directly to DB node to balance CPU” 来标记reverse offloading这个过程。

如下:

SQL> select name, value from v$sysstat where name like'%balance%';

NAME VALUE
---------------------------------------------------------------- ----------
cell physical IO bytes sent directly to DB node to balance CPU 0

这项统计信息的描述是:

The number of I/O bytes sent back to the database server for processing due to CPU usage on Oracle Exadata Storage Server.

也就是说cell因自身cpu占用过高使用普通block I/O扫描返回给db节点的I/O字节数。

那么这个过程是通过什么参数来控制的呢?遗憾的是我虽然知道有这个特性但是却一时也记不起来了,我只记得这是一个cell端设置的隐含参数。如果能把所有的cell的隐含参数摆在我面前,我一定能够一眼认出它来。遗憾的是,我并没有一份包含所有的cell的隐含参数的列表,也不知道如何获取这个信息。至少目前我并不知道通过什么命令或者视图可以查询到cell端使用的所有隐含参数信息。

经过一段时间的思考以后。。。

我想既然cell端的systemstate是dump cell端存储软件的内存信息的,cellsrv中应该包含当前所有参数的信息。

于是尝试进行cell端的systemsate dump,方法我在以前的文章如何在Exadata的cell节点做systemstate dump中有提到过。

[root@dm01cel01 ~]# cellcli
CellCLI: Release 12.1.1.1.0 - Production on Tue Oct 08 02:24:45 MDT 2013

Copyright (c) 2007, 2013, Oracle. All rights reserved.
Cell Efficiency Ratio: 589

CellCLI> alter cell events="immediate cellsrv.cellsrv_statedump(0,0)"
Dump sequence #2 has been written to /opt/oracle/cell/log/diag/asm/cell/dm01cel01/trace/svtrc_27579_59.trc
Cell dm01cel01 successfully altered

 

打开/opt/oracle/cell/log/diag/asm/cell/dm01cel01/trace/svtrc_27579_59.trc,搜索parameter就能得到一份当前cell隐含参数的列表(令人遗憾的是暂时无法获取这些隐含参数的描述信息),如下所示:

+ Parameters for process at dump time

Dumping configuration parameter values
Unable to lookup value for parameter local_ipaddresses
ipaddress1 = 192.168.10.11/22 (default = NULL)
Unable to lookup value for parameter ipaddress2
Unable to lookup value for parameter ipaddress3
Unable to lookup value for parameter ipaddress4
version = 0.0 (default = )
_cell_max_pll_pred_writes = 36
_cell_pred_writes_autotune_enabled = TRUE
_cell_max_pll_pred_reads = 36
_cell_pred_reads_autotune_enabled = TRUE
_cell_max_flash_largeios = 48
_cell_num_threads_in_short_wait = 40
_cell_max_pll_pred_filters = 24 (default = 0)
_cell_pred_filters_autotune_enabled = TRUE
_cell_pred_filter_max_iosize = 1073741824
_cell_num_threads = 100
_cell_num_buffers = 5000
_cell_num_1mb_buffers = 8000 (default = 0)
_cell_num_1mb_bwr_buffers = 180
_cell_num_1mb_brr_buffers = 180
_cell_max_dynbufs_memsize = 3072 (default = 0)
_cell_listener_port = 5042
_cell_listener_backlog = 1000
_cell_listener_pll_jobs = 23
_cell_listener_req_batch = 100
_cell_num_0_byte_recv_ports = 4
_ms_cell_ioctl_timeout = 30000
_cell_iorm_test_mode = FALSE
_cell_iorm_perf_stats = FALSE
_cell_iorm_wl_mode = 0
_cell_iorm_hipri_alloc = 0
_cell_iorm_medpri_alloc = 0
_cell_iorm_lowpri_alloc = 0
_cell_iorm_asm_alloc = 0
_cell_iorm_lutil_limit = 0
_cell_iorm_hints_enabled = FALSE
_iorm_hint0 = -1
_iorm_priority0 = -1
_iorm_hint1 = -1
_iorm_priority1 = -1
_iorm_hint2 = -1
_iorm_priority2 = -1
_iorm_hint3 = -1
_iorm_priority3 = -1
_iorm_hint4 = -1
_iorm_priority4 = -1
_iorm_hint5 = -1
_iorm_priority5 = -1
_iorm_hint6 = -1
_iorm_priority6 = -1
_iorm_hint7 = -1
_iorm_priority7 = -1
_cell_iorm_pri_catidx = -1
_cell_iorm_pri_dbidx = -1
_cell_iorm_pri_cgidx = -1
_cell_iorm_enable = TRUE
_cell_iorm_max_io = 0
_cell_iorm_max_lio = 0
_cell_iorm_conc_writes = 0
_cell_iorm_deadline = 0
_cell_iorm_fake_dbs = 0
_cell_hard_disable = FALSE
_cell_raise_softassert_on_harderr = FALSE
_cell_enable_ossnet_checksum = FALSE
_cell_enable_skgxp_stats = TRUE
_skgxp_udp_use_tcb = TRUE
_skgxp_udp_use_tcb_client = TRUE
_cell_memory_tracing = TRUE
_cell_dmpsga_enabled = FALSE
_cell_enable_dynamic_credits = TRUE
_cell_num_ios_per_predjob = 10
_cell_num_pred_flashio_corrupt_retries = 1000
_cell_pred_dump_disk_onclose = FALSE
_cell_pred_polling_ctl_enabled = TRUE
_cell_pred_sim_block_byteord_conv = FALSE
_cell_max_kuty_failure_diagnostics = 0
_cell_print_all_params = FALSE
_cell_pred_disable_destbuf_refill = FALSE
_cell_smartio_passthru_enabled = FALSE
_cell_pred_no_predio_limit = FALSE
_cell_pred_enable_io_buffer_eviction = TRUE
_cell_pred_enable_dest_buffer_eviction = TRUE
_cell_pred_enable_flashio = TRUE
_cell_snapshot_bufsize = 1
_cell_snapshot_interval = 100
_cell_gen_time_stats_level = 1
_cell_gen_time_stats_timer_level = 0
_cell_force_split_gdisk = FALSE
_cell_testlevel = 0
_cell_max_receive_buffers_per_port = 600
_cell_num_8k_buffers = 10000
_cell_num_16k_buffers = 5000
_cell_num_32k_buffers = 5000
_cell_num_64k_buffers = 5000
_cell_max_receive_buffers_8k_port = 1000
_cell_max_receive_buffers_1mb_port = 50
_cell_crash_on_error = 0
_cell_crash_on_error_skip_n = 0
_cell_1mb_buffers_hugepage_support = TRUE
_skgxp_udp_interface_detection_time_secs = 4
_skgxp_gen_ant_ping_misscount = 2
_disable_diskmon_tcp_monitor = FALSE
_disable_diskmon_subnet_manager_query = FALSE
_skgxp_min_zcpy_len = 2147483647
_skgxp_min_rpc_rcv_zcpy_len = 2147483647
_skgxp_zcpy_flags = 2147483647
_skgxp_ctx_flags1 = 0
_skgxp_ctx_flags1mask = 0
_skgxp_dynamic_protocol = 0
_skgxp_inets = 0
_skgxpg_last_parameter = 27
_skgxp_ant_options = 0
_libcell_enable_libcell_interrupts = 1
_cell_rcvport_hist_size = 0
_skgxp_gen_rpc_no_path_check_in_sec = 1
_skgxp_gen_rpc_timeout_in_sec = 300
_skgxp_gen_ant_off_rpc_timeout_in_sec = 30
_reconnect_to_cell_freq_in_sec = 2
_reconnect_to_cell_attempts = 7
_disconnect_to_cell_attempts = 2
_reconnect_controls_reset_interval = 60
_dskm_disable_reconnect_to_cell = FALSE
_cell_disable_resource_leak_check = FALSE
_cell_disable_ant_check_reid = FALSE
_cell_disable_proactive_drop = FALSE
_cell_server_event = 
_cell_client_event = 
_cell_reserve_hugepage_memory_mb = 24
_cell_tolerates_max_backward_drift_microsecs = 300000
_cell_num_sched_log_entries = 8192
_cell_storage_index_columns = 8 (default = 0)
_cell_storage_index_partial_reads_threshold_percent = 85
_cell_storage_index_partial_rd_sectors = 512
_cell_enable_storage_index_for_loads = TRUE
_cell_enable_storage_index_for_writes = TRUE
_cell_storage_index_diag_mode = 0
_cell_storage_index_sizing_factor = 2
_cell_pred_max_smartio_sessions = 3820 (default = 0)
_cell_pred_max_con_ccfilter = 23 (default = 14)
_cell_pred_max_con_filters = 0
_cell_pred_num_ios_toissue_keptobj = 2
_cell_pred_max_cus_per_filter = 1
_cell_load_timezone_during_boot = TRUE
_cell_sendport_private_rqh_pool_size = 10
_cell_sendport_global_rqh_num_pools = 512
_cell_sendport_global_rqh_pool_maxincr = 150
_cell_capability_version = 0
_cell_iolat_stats_disable = FALSE
_cell_pred_mapelem_split_size = -1
_cell_perf_flags = 0
_cell_enable_sbuf_check = FALSE
_cell_disable_crash_dump_enhancement = FALSE
_cell_buffer_expiration_hours = 48
_cell_object_expiration_hours = 24
_cell_pred_max_num_outstanding_ios = 1000
_cell_mutex_stats = 0
_cell_port_activity_threshold = 300000
_cell_ant_port_activity_threshold = 1800000
_cell_ant_port_noopen_threshold = 60000
_cell_in_lrg_testing = FALSE
_cell_io_hang_reboot = TRUE
_cell_iohang_wtfc_reboot = FALSE
_cell_io_hang_time = 90
_cell_io_hang_kill_time = 95
_cell_io_hang_disable = FALSE
_cell_write_simulate_hard_error_freq = 0
_cell_assert_on_flash_data_corruption = 0
_cell_memalloc_analysis = disabled
_cell_flashcache_diag_reads_frequency = 0
_cell_read_flash_data_verif_level = 3
_cell_read_flash_gdisk_verif_level = 3
_cell_max_retry_on_read_flash_gdisk_verif_err = 2
_cell_enable_read_verif_on_these_gdisks = 
_cell_enable_read_verif_on_gdisk_first_N_MB = -1
_cell_flash_cache_sanity_checking = 0
_cellrsdef_fast_restart = 1
_cell_max_memory = 22355 (default = 0)
_cell_max_connections = 1500 (default = 0)
_cell_sga_lowmem_threshold_size = 1024 (default = 0)
_cell_nomem_threshold_enabled = TRUE
_cell_sga_lowmem_threshold_enabled = TRUE
_cell_disable_heap_summary = FALSE
_cell_disable_flashcache_hung_io_handling = FALSE
_cell_flashcache_aging_writes_enabled = TRUE
_cell_flashcache_lru_max_hot_percent = 50
_cell_flashcache_max_FDOM_outst_ios = 70
_cell_populate_flash_max_FDOM_outst_wr_ios = 100
_cell_auto_close_fd_interval = 120
_cell_dump_sga_on_oom_exception = FALSE
_cell_quarantine_manager_disabled = FALSE
_cell_qm_disable_sql_step_quarantine = FALSE
_cell_qm_disable_disk_region_quarantine = FALSE
_cell_qm_db_quarantine_threshold = 3
_cell_qm_offload_quarantine_threshold = 3
_cell_thread_max_trace_file_size = -1
_cell_redolog_fast_ack = FALSE
_cell_max_tsld_hd_svctm_ms = 500
_cell_max_tsld_fd_svctm_ms = 100
_cell_max_rltv_svctm_ratio = 10
_cell_svctm_ratio_wt = 100
_cell_err_num_wt = 20
_cell_iopoor_perf_disable = FALSE
_cell_disable_flashcache_db_blk_chksum = FALSE
_cell_disable_flash_gdisk_db_blk_chksum = FALSE
_cell_auto_dump_errstack = TRUE
_cell_perf_max_hd_proa_fail = 0
_cell_perf_max_fd_proa_fail = 16
_cell_max_hd_hung_reboot = 2
_cell_max_fd_hung_reboot = 9
_cell_si_max_num_diag_mode_dumps = 20
_cell_fc_persistence_max_io_retry = 4
_cell_fc_persistence_state = 0
_cell_fc_md_shadow_paging_enabled = FALSE
_cell_fc_bootstrap_timeout = 20000000
_cell_fc_cache_mirror_writes = 1
_cell_fc_dw_batch_size = 1
_cell_simulate_railroad_crashes = FALSE
_cell_qm_max_simulated_railroad_crashes = 2
_cell_latency_warning_threshold = 
_cell_latency_threshold_check_interval = 360000
_cell_latency_threshold_print_warning = FALSE
_cell_si_expensive_debug_tracing = FALSE
_cell_poor_perf_schedule_time = 5
_cell_iohang_schedule_time = 1
_cell_io_hang_drop_flash = TRUE
_cell_io_hang_drop_hard = FALSE
_cell_assert_unsafe_allocmem = FALSE
_cell_fplib_fix_control = 0
Unable to lookup value for parameter _lost_cache_detect
_cell_num_vers_check_fail_messages = 0
_cell_qm_db_quarantine_time_threshold = 86400
_cell_flashlog_flags = 0
_cell_flashlog_max_active_table_size = 1024
_cell_secure_erase_power = 5
_cell_mpp_cpu_freq = 2
_ms_listener_port = 5043
_cell_mpp_threshold = 90
_cell_mpp_max_pushback = 50
_si_write_diag_disable = FALSE
_cell_max_cellsrvstat_sessions = 3
_cell_si_diag_mode_force = FALSE
_cell_tracefile_max_size = 1610612736
_cell_bwrite_si_build_disabled = FALSE
_cell_state_dump_options = 0

有了这份参数列表以后我就能认出来了
控制这个功能的隐含参数为

_cell_mpp_threshold = 90
_cell_mpp_max_pushback = 50

其中_cell_mpp_threshold表示cell cpu的阈值,默认为90%,_cell_mpp_max_pushback表示返回Block I/O的最大比例,默认为50%。
也就是说默认情况下如果cell节点的cpu超过90%, 那么cell就会使用不经smart scan过滤Block I/O返回给db节点,这部分I/O的最大比例为50%。

我们可以在cellinit.ora参数文件中修改这个默认值。也可以使用如下方式修改当前内存中的值:

CellCLI> alter cell events = "immediate cellsrv.cellsrv_setparam('_cell_mpp_threshold','75')"

免责声明:

以上过程和隐含参数仅供参考,请不要在非Oracle Support的指导下设置这些隐含参数,如果造成任何负面影响,本人不承担由此造成的任何损失。

沪ICP备14014813号-2

沪公网安备 31010802001379号