如何在脱机模式下载新的Oracle Cloud Control 12c的Agent软件

从OEM 12c开始,agent无法直接通过互联网可以下载,而需要在Self Update (自行更新)下载。但通常在生产环境中部署的OEM,出于安全考虑是没法直接连接互联网的。那么问题就来了,如果OEM是安装在Linux平台下,那么即只有对应平台的Agent软件。如果想要监管AIX或者HP-UNIX平台呢?本文就是为了解决此问题,如何在脱机模式中仍然使用self-update和补丁管理特性。

其他版本的下载可参考:http://www.oracle.com/technetwork/oem/grid-control/downloads/agentsoft-090381.html

1、首先,在OEM中通过“Setup(设置)”>“Extensibility(可扩展性)”>“ Self Update (自行更新)”。进入“ Self Update (自行更新)”配置页,查看“Connection Mode(连接模式)”的显示结果,必须是设置为”Offline”模式。

如下图:

OEM2

OEM1

2、返回“Self Update(自行更新)”配置页,点击“ Check Updates(检查更新)”,此时弹出“ Check updates in offline mode(在脱机模式中检查更新)”提示框,根据提示框,到可与Internet连接的主机上,先下载更新目录:

OEM3

比如:https://updates.oracle.com/Orion/Download/download_patch/p9348486_112000_Generic.zip

根据Use the following link to download the latest updates catalog 提供的网址,下载相应的文件后上传至OEM主机。

3、我们将使用emcli工具来导入catalog,emcli工具本身就已经安装在Manager Cloud Control server中的。如果没法正常使用,可以采用以下方式来安装emcli工具:

  1. 下载和安装最新的Java 1.6.x
  2. 下载emclikit.jar https://emcc_host:emcc_port/em/faces/core-emcli-emcliDownload
  3. 安装:java -jar emcliadvancedkit.jar -install_dir=<em_cli_home_dir>
  4. 配置:/u01/app/oracle/emcli/emcli setup -url=https://192.168.56.241:7802/em/ -username=SYSMAN

使用以下命令,登陆emcli并导入catalog:

4、再次检查“ Self Update (自行更新)”配置页:

EMCC01

此时可以看到,虽然仍然是在Offline模式下,但是已更新catalog内容,可以看到Agent Software有50个Available Updates。

5、点击”Agent Software “,进入agnet列表,选择所需的agent,然后点击”Download”:

EMCC02

然后使用emcli导入agent软件:

6、再次检查“ Self Update (自行更新)”配置页,可以看到新的agent已经下载完毕: EMCC03 点击”Apply”使之可以给部署使用。此时会有一个后台作业呗创建,在几秒之后,可以看到状态被改变为”applied”。EMCC04

此时我们就可以开始部署此平台。
参考文档:

http://docs.oracle.com/cd/E24628_01/install.121/e22624/install_agent.htm#EMBSC292

记一次控制文件恢复异常处理

在一次需要采用RMAN恢复一个新建的测试库时,发现控制文件无法正常恢复,特此记录本次处理过程如下。

环境介绍:
Source DB: 2-Node Oracle Database 11g R2 RAC On AIX (11.2.0.4 with ASM)
Target DB: Single Instance Database 11g R2 On AIX (11.2.0.4 with ASM)

问题描述:

使用RMAN恢复控制文件的时候,产生以上报错。

解决思路:
1、ASM磁盘组权限问题,Oracle用户未加asmadmin权限

2、确定ASM磁盘已经被挂载

3、如果是ASM磁盘组权限问题,需重启主机

上述确认无误后,重启主机

控制文件恢复成功

12c New Feature:Temporary Undo

背景:

本文是学习12c新特性的笔记,主要来源于官方文档和OU教材汇总而成。

什么是临时undo?

Temporary Undo是12c的新特性,如下图所示:

Temporary Undo verview

临时表广泛的被用作于为暂存中间结果分配区域,这是因为改变哪些表是比用非临时表快很多的。性能提升主要是因为实际上修改临时表没有redo条目直接产生。然而,在临时表(和索引)上操作的undo任然记录到redo log。临时表的undo,在该临时对象的其生命期的一致性读和事务回滚是有用的。超出此范围的undo是多余的。因此它在redo流中不需要持续。举例来说,事务恢复只是丢弃临时对象的undo。

从12c开始,可以通过把临时表的事务产生的undo,直接在临时表空间中存储独立undo流,来避免在redo流中记录undo。

注意:临时undo segment是会话私有的。它存储属于相应会话的临时表改变的undo

默认情况下,undo记录临时表是存储在undo表空间中,且记录到redo中,这是与undo管理永久表相同的方式。然而,你可以使用TEMP_UNDO_ENABLED初始化参数来从永久表的undo分离临时表的undo。当此参数设置为TRUE,临时表的undo调用temporary undo。
Continue reading 12c New Feature:Temporary Undo

如何在CentOS 6上安装Python 2.7和Python 3.4

在最新的CentOS release 6.6 (Final)(截至于2014年11月30日是最新)系统上默认自带的Python是2.6.6版本,可能是出于安全的原因,导致现有发行版本Python严重落后。在使用部分应用时,会有更高版本需求。这里特别需要注意的是由于多个关键的系统应用依赖于自带python,如果替换系统的python环境可能会导致很多难以预见的错误,比如yum等。本文讲述如何在CentOS上使用新路径(/usr/local)安装最新版本的Python。

本文即讲述如何在CentOS 6上安装Python 2.7和Python 3.4:

0、安装前预准备

1、查看版本

2、下载解压

 3、修改setup.dist, 增加ssl支持

4、编译安装:


由于多个关键的系统应用依赖于自带python,不建议修改默认python

验证:

5、修改系统路径(可选)
编译安装完成后,要替换掉系统自带的Python,但CentOS的yum依赖于Python工作,为了保证yum的正常运行,在替换前,先将自带的Python更名备份,方法如下:

验证:

6、已知影响
修改yum的python版本

安装过程中的哪些报错:


编译报错:

解决办法:

AIX上的配置网络调优参数

验证网络调优参数设置如下表所示的值或者更高值:

Network Tuning Parameter Recommended Value
ipqmaxlen 512
rfc1323 1
sb_max 4194304
tcp_recvspace 65536
tcp_sendspace 65536
udp_recvspace 655360
备注:
推荐此参数值10倍于udp_sendspace参数。但此参数值必须小于sb_max参数值。
udp_sendspace 65536
备注:此值适用于默认数据库安装。对于生产库,此参数最小值:(DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT) + 4 KB

查看这些参数的当前值,如果有必要则修改:
1、检查网络调优参数的当前值,使用以下命令:

2、如果你需要改变参数的值,然后输入以下命令来确定系统是否运行在兼容模式:

如果系统运行在兼容模式,那么输出类似于以下,表明pre520tune属性值已开启。
3、如果系统运行在兼容模式,然后按照以下步骤修改参数值:
使用以下类似命令来修改每个参数值:

例如:

上述步骤需要修改的每个参数,添加类似如下条目到/etc/rc.net文件:

添加这些行到/etc/rc.net文件,值需要系统重启生效。
4、如果系统未运行在兼容模式,那么输入类似以下命令来改变参数值:
ipqmaxlen 参数

其他参数

注意:如果修改ipqmaxlen 参数,那么你必须重启系统。
这些命令修改/etc/tunables/nextboot文件,在系统重启后属性值持续有效。

5、如果需要修改参数,而为重启系统。在修改非全局设置后,那么使用ifconfig命令来检查每块网卡属性:
例如:

对于ISNO参数tcp_sendspace,使用以下命令来设置:

 

在Linux上配置HugePages

有时候在Linux上使用Oracle的时候,为了提高性能,往往会配置HugePages。这里仅说明如何配置HugePages,至于对HugePages的用处和为什么需要配置有兴趣的同学可以参考MOS:HugePages on Linux: What It Is… and What It Is Not… (文档 ID 361323.1)

配置步骤如下:
1、编辑/etc/security/limits.conf文件并设置menlock。memlock是以kb为单位,设置的值一般小于安装的内存。例如,在安装时使用64GB 内存,增加以下语句锁定最大内存限制:

2、重新登陆oracle用户并运行以下语句验证memlock设置:

运行以下命令显示Hugepagesize 值:
3、如果你使用的是Oracle 11g或之后的版本,默认在建库时是采用Automatic Memory Management(AMM)特性,这是和HugePages冲突的,如果需要使用HugePages,则必须先禁用AMM。设置参数MEMORY_TARGET和MEMORY_MAX_TARGET为0。
4、确保所有数据库实例(包含ASM实例)都已经是开启,使用下述脚本计算当前共享内存段hugepages推荐值:
创建脚本hugepages_settings.sh

Continue reading 在Linux上配置HugePages

Data Guard–物理主备库切换

近期因为工作的需要,研究了一些DG的东西,以下是:
Performing a Switchover to a Physical Standby Database的操作步骤
主要是参考官方文档和网上一些资料,整理而成。

1、减少实例

在切换之前必须把数据库减少为一个实例,即RAC的话,只留一个节点。
shutdown immediate
或(紧急时在辅助实例执行)
shutdown abort

2、首先在主库确认没有日志缺口:

SQL> select STATUS, GAP_STATUS from V$ARCHIVE_DEST_STATUS where DEST_ID = 2;
应该返回 VALID 和 NO GAP。
删除 LOG_ARCHIVE_DEST_N 参数中的所有延迟应用(delay)重做日志设置,你要确认所有变化都在备库应用,才能确保无数据丢失。
确认所有重做日志都已在备库应用,查询备库:
SQL> select NAME, VALUE, DATUM_TIME from V$DATAGUARD_STATS;
不应该返回 transport lag 或 apply lag, finish time 应该为0.

3、检查先决条件

检查完这些先决条件后,确认主库可以进行角色切换,查询主库:
SQL> select SWITCHOVER_STATUS from V$DATABASE;
如果返回 TO STANDBY 或 SESSIONS ACTIVE,那么主库就可以进行切换。
切换主库为备库命令为:
alter database commit to switchover to physical standby with session shutdown;
shutdown immediate
startup mount

4、备库切换为主库

查询备库是否可以切换为主库
select SWITCHOVER_STATUS from V$DATABASE;
如果返回 TO PRIMARY 或 SESSIONS ACTIVE,就可以切换。
如果返回 SWITCHOVER LATENT 或 SWITCHOVER PENDING,就要去检查告警日志,看有什么问题,一般是需要应用一些日志。
如果是需要应用日志的话,在备库执行如下命令:
recover standby database using backup controlfile;
在应用日志前应该是 SWITCHOVER PENDING 状态,完成应用后,会变成 TO PRIMARY 或 SESSIONS ACTIVE状态。
切换备库为主库:
alter database commit to switchover to  primary with session shutdown;
打开新主库:
alter database open;

5、在原主库(现备库)启用日志应用

如果其他物理备库被停止,也需要启用日志应用
alter database recover managed standby databse using current logfile disconnect from session;

RAC环境下SYSDATE返回错误时间

某客户反馈说,在11.2.0.3的RAC下,使用sqlplus连接时查询sysdate返回的时间是正确的,但是使用PL/SQL等通过Listener方式连接的时候,则返回错误的时间。

其实造成这个问题的原因是11.2.0.2后的新特性:

11.2.0.1的时候TZ变量取决于grid和root用户的shell环境变量TZ。

但是从11.2.0.2开始,Oracle的集群(GI)开始拥有自己的时区和配置,即TZ参数存在$GRID_HOME/crs/install/s_crsconfig_<nodename>_env.txt中设置的time zone。

一般集群的时区是在安装GI时从系统获取的。经过沟通后,客户确实在前段时间更改过系统时区,至此造成的sysdate返回错误的原因就是因为当操作系统的时区发生改变时,但是GI的时区未改变。解决方:修改TZ值,重启节点。

具体修改可以参考MOS:How To Change Timezone for 11gR2 Grid Infrastructure (Doc ID 1209444.1)

RAC安装节点2执行root.sh报CRS-5005和CRS-2632错

在某客户处,AIX 6.1上安装11.2.0.3的RAC,在节点2执行root.sh时出现以下报错:

初期由于分配IP存在不确定因素,一致以为是IP导致,但是实际不是。

从正常的安装来说,OCR盘在节点1执行时已经创建成功,节点2只需要应用即可。从此思路推断,是存储问题导致安装失败。

验证节点1和节点2存储是否划盘一致:

节点1:

节点2:

果然两个节点的存储划盘是不一致的,至此问题已经很清楚,是由于存储划盘不一致导致节点2执行root.sh报CRS-5005和CRS-2632错。

行链接和行迁移

众所周知造成Oracle数据库性能低下的原因有很多,但是行链接和行迁移也很可能是其中原因之一。

 什么是行链接和行迁移?

1)该行太大,在它第一次插入时,无法放入一个数据块。

在行链接中,Oracle数据库将数据存储在为段保留的一个或多个被链接的数据块中。行链接最经常出现在大行中。例如包括包含LONG或LONG RAW数据类型列的行,或在2KB块中的VARCHAR2(4000)列,或具有大量列的行。在这些情况下出现链接行是不可避免的。

2)原先的行本来可以放入到一个数据块的,但是在更新后整体行长增加了,又没有足够可用空间来容纳更新的行。

在行迁移中,假设行可以容纳在一个新块中,Oracle数据库将会把整个行移动到一个新的数据块。原来的被迁移走的行块会包含一个指针或“转发地址”指向迁移到新块中的行。已迁移行的rowid不会改变。

3)超过255个列的行。

Oracle数据库在一个块行中只可以存储255的列。因此,如果你在具有1000个列的表中插入行,则数据库将创建4个快行,通常会链接多个块。

那么到底什么是行链接和行迁移呢?

行链接

如下图描述:向数据块中插入大行,行出入左边的块太大,所以数据库通过将第一个行块(row piece)放在左边的块,而将第二个行块(row piece)放入到右边的块中,这样就形成了行链接。

cncpt316

 

行迁移

如下图所示:左边的块包含的行被更新,但现在导致该行太大而不能放入块中。数据库将整个行移动到右边的块中,并在左边的块中保留一个指向被迁移行的指针。

cncpt306

根据上述概念总结:行链接一般发生在insert阶段(因数据块无法容纳过大数据);行迁移一般发生在update阶段(原数据块无法容纳增长的数据)

当行被链接或迁移时,检索数据所需的I/O灰增加。导致这种情况是因为Oracle数据库必须扫描更多块以检索行信息。例如,如果数据库执行一个I/O读取索引或者读取一个未迁移的表行,则需要额外的I/O才能获取迁移的数据行。

参考文档:
Chained and Migrated Rows
http://docs.oracle.com/cd/E11882_01/server.112/e40540/logical.htm#CNCPT1055