早上就接到个电话，说是美国的快件，问我送到哪里，有点紧张的告诉快递公司我的地址，放下电话就开始琢磨，美国。。。。谁给我快递东西了。。。。难道是。。。。她。。。。不可能不可能。。。
中午吃饭，又收到电话，DHL送的快递，说快到了，突然一个机灵，想起来会不会是上次Oracle的ACE发东西了，可是寄个衣服还需要从美国寄过来，成本高了点吧，还是有点犹豫。。。
收到东西，果然是美国。。。。的Oracle寄来的，一个挺大挺扁的盒子，看上去应该是衣服了，打开一看，果然，好像是抓绒的衣服，夏天是不能穿的了，不然非得被送进安定医院去，质量还不错，看来秋天有新衣服穿了，另外，还有个玻璃牌牌，跟pub发的差不多，好像质量比pub的那个好点。。。
LP看到后说了一句，我们家狗狗小便缺少个立柱，这个不错。。。。倒

周末，夜，放松了一天，周末的夜晚无所事事，本打算吃完了看看片，看完了睡睡觉，晃晃悠悠过周末。时近晚上10点，突然接到一个客户电话，一看号码，心说这可不好，肯定出问题了，希望不是大事。。。
电话里，客户看样子还挺着急，原来是数据库起不来了，不过听上去问题不算太严重。客户下午本来要换UPS，结果正在备份呢，突然停电，这还没换掉的UPS再加上停电，结果服务器带存储一起就咔嚓了，等来电了把服务器都起来，结果发现，服务器上的三个库，其中有一个起不来了，故障呢，是open数据库的时候出现了SQL递归调用失败，访问undo表空间的文件有问题了。客户环境是9i rac，文件存储在raw上，有备份、有归档（一听这个就放心了，哈哈）。
开始远程电话指导，首先mount数据库，查询v$recover_file，发现2号文件和12号文件在里面出现，并且这两个文件状态都为offline,而且error字段为空。然后查询v$datafile和v$tablespace，发现这两个文件分别是undo表空间和另一个用户数据表空间的。既然刚才看到error字段为空，那应该是介质还在，但文件不一致拉，所以让客户直接recover datafile，再查询v$recover_file，发现里面已经没有任何信息了，这就说明文件的介质恢复已经完成了，那就打开数据库吧。
本以为接下来用户打开数据库，然后在电话里向我表达一下谢意，俺就可以挂了电话睡觉去了，结果没想到，用户open数据库的时候还是出了同样的错误，数据库仍然没有打开！ 奇怪了。。。难道存储有问题了？ 跟客户确认了一下，emc的存储厂商说存储没有问题，操作系统也没有做任何改动。。。奇怪，算了，先不想那么多，反正有备份嘛。于是我让客户把主机整个重起，然后用备份再作一次恢复。。。半小时后，电话再次响起，客户的声音有点颤抖，说道，还是出现了刚才的错误。。。晕
我心里也有点紧张了，这可奇怪了，不会半夜把我搞过去给他们现场解决吧，而且从现象上看，也跟正常恢复的情况有些不一样啊，问题出在哪儿了呢。。。。。。抓了抓头皮，点了一下鼠标，让手中正在打的游戏暂停。。。突然，一个想法出现在脑子里，靠，一个基本的常识性问题忘了，其实根本就不需要恢复！
什么问题呢，很简单，在讲表空间状态的时候，我们一般都会强调有些表空间是不能offline的，其中就包含了在用undo表空间，那么刚才已经在v$recover_file查看到了2号（undo表空间的文件）文件的状态正好是offline的，虽然随着日志的应用，2号和12号文件已经不出现在v$recover_file里了，但他们offline的状态并没有改阿！ 赶紧让用户再查询一下v$datafile，发现果然状态都是offline的，出了口大气，原来是这么个小问题在作怪，让客户把2号和12号文件都online了，然后直接open数据库，ok了。。。果然听到客户接下来一连串的感谢之声，呵呵，问题搞定。
现实中很多问题看似复杂，其实就是我们最基础的知识，对这些知识的消化吸收和灵活运用，才能够在出现问题的时候在最短的时间内确定清晰可行的解决方法，所以，基础真是很重要。

从oracle9i开始，oracle提供了web方式的sqlplus界面，通过isqlplus，用户可以不需要安装任何oracle客户端，就能够通过浏览器方式的sqlplus进行数据操作与数据库管理。普通的数据库用户可以直接通过isqlplus的网址http://ip:port/isqlplus登陆,进入该网址后会直接进入数据库用户登陆界面，使用数据库中的普通用户即可登陆；但如果是DBA用户登陆isqlpus，则需要首先配置isqlplus dba的用户和口令，然后输入网址http://ip:port/isqlplus/dba，进入该网址后首先会弹出一个登陆框，要求先输入iSQL*Plus DBA的用户和密码，注意这里不是数据库用户，而是isqlplus应用服务器要求的用户和密码，也就是前面配置的isqlplus dba的用户名和口令，然后才能出现isqlplus登陆界面，此时可以输入sys或者system用户，登陆数据库进行管理。
要以DBA身份登陆isqlplus，必须先配置好oc4j用户。oc4j可以使用两种身份认证方式：基于xml配置文件(jazn-data.xml) 或者基于LDAP(Oracle Internet Directory) 。通常采用xml配置文件认证的方式较多，这种方式使用的该配置文件位于$ORACLE_HOME/oc4j/j2ee/isqlplus/application-deployments/isqlplus/config，但是该配置文件中的密码是加密过的，所以无法手动修改该文件，配置用户密码需要通过JAZN(Java AuthoriZatioN)来配置，JAZN是oracle提供的一个JASS(Java Authentication and Authorization Service)工具。
通过JAZN，可以完成以下任务：Create user / List user / Grant the webDba role / Remove users / Revoke the webDba role / Change user passwords
上述任务既可以先进入JAZN命令环境后再执行，也可以直接直接在命令行中实现。

下面是Oracle 10g上配置isqlplus dba的方法，注意unix和windows上稍有不同。
unix:
$ isqlplusctl stop
$ JAVA_HOME=$ORACLE_HOME/jdk
$ export JAVA_HOME
$ cd $ORACLE_HOME/oc4j/j2ee/isqlplus/application-deployments/isqlplus
$ $JAVA_HOME/bin/java Djava.security.properties=$ORACLE_HOME/oc4j/j2ee/home/config/jazn.security.props -jar $ORACLE_HOME/oc4j/j2ee/home/jazn.jar -user "iSQL*Plus DBA/admin" -
password welcome –shell
JAZN:> adduser "iSQL*Plus DBA" oracle oracle
JAZN:> grantrole webDba "iSQL*Plus DBA" oracle
JAZN:> exit
$ isqlplusctl start

windows:
set ORACLE_HOME=...
set JAVA_HOME=%ORACLE_HOME%/jdk
cd %ORACLE_HOME%/oc4j/j2ee/isqlplus/application-deployments/isqlplus
%JAVA_HOME%/bin/java Djava.security.properties=%ORACLE_HOME%/oc4j/j2ee/home/config/jazn.security.props -jar %ORACLE_HOME%/oc4j/j2ee/home/jazn.jar -user "iSQL*Plus DBA/admin" -
password welcome –shell

注意：
1、admin虽然是默认的管理员，但初始并没有真正被授权
2、必须在$ORACLE_HOME/oc4j/j2ee/isqlplus/application-deployments/isqlplus目录中执行命令，否则会出现下面的错误：
oracle.security.jazn.JAZNRuntimeException: Configuration file "configjazn.xml" does not exist. Check your JAAS configuration settings.
或者
Realm [iSQL*Plus DBA] does not exist in system.
3、在windows中注意目录的书写，不能使用''，而要像unix一样使用'/'
4、iSQL*Plus DBA的默认管理员admin的默认口令是 'welcome'，为了安全起见，最好修改口令

一直在高强度的运转，突然停下来休息，非常不适应，因此，病了。

从初期的身体有点发冷，到后来喉咙痛，眼睛痛，头痛，现在还能动，不过非常的没有精神，看来忙得过度了，也是会得病的。

还好，还年轻，熬过这几天，继续为了oracle的事业而奋斗。

最近正好有朋友问起了块空间参数对性能的影响，简单写了几句，记录一下。 db_block_size是数据块的大小，也是数据库I/O的最小大小，对数据访问时的I/O性能影响大，而且创建好数据库后就不能修改了，所以最好在创建数据库之前确定 好，通常建议尽量使用较大的块，另外，块的大小也跟经常执行的并发事务数有关，过大的块也可能出现热点块竞争。对数据块的考虑通常从下面这几个方面考虑： 1、对查询来说数据块要足够大以减少I/O 2、对查询来说尽可能在块中放入更多的数据以减少I/O 3、对查询来说尽可能数据在最少的块中得到（减少行链、行迁移） 4、对DML操作来说应该减少并发事务带来的块头竞争这几点分别对应着块大小的初始化参数和数据块上设置的空间参数，块的空间参数主要有四个：INITRANS，MAXTRANS，PCTFREE，PCTUSED，下面列出了这四个空间 参数的含义以及对性能的影响： initrans是块头的初始事务槽数，每一个访问块的事务都必须首先获得数据块头的一个事务槽，所以如果块中数据的并发事务多，那么就需要准备更多的事务槽。如 果初始事务槽太小，那么在需要的时候就会动态扩展，动态扩展会导致事务槽等待分配，降低DML的速度；但是如果事务槽太大，没有那么多的并发事务，那么会浪 费块的空间，使块中的可用空间降低，块中容纳的行数减少，那么在查询数据时需要访问更多的块，增加了I/O，也会降低性能。所以设置的initrans应该能够满足 正常业务的需求，也就是与并发事务相关。 maxtrans是在事务槽不够的情况下，最大可以扩展的事务槽数。如果不够大，无法扩展，需要事务槽的事务则等待。 pctfree决定了为update保留的空间百分比，如果太小会产生大量的行迁移，造成单行的访问不得不读取多个块，做无谓的I/O；如果太大会造成空间浪费，一个块只 能容纳少量的数据，就需要更多的块存放数据，全表扫描和索引访问将需要扫描更多的数据块。 pctused决定了数据块合适回到可用状态。可用的块就是可以执行插入的块，不可用状态的块则只能执行删除和修改，所有处于可用状态的块被放 在freelist中，freelist是存放在段头的一个数据结构。pctused不能和pctfree离得太近，如果两个标记太紧的话，也就意味和pctused设置太大，例 如pctfree=20,pctused=75，两个只相差5%，这时候如果在块中发生大量的数据删除和插入时，数据块的状态可能会发生非常频繁的更改，而块状态被纪录 在freelist中，块被频繁的从freelist中插入和删除，会造成freelist的争用。当然，如果pctused设置太小，会使块长时间处于不可用状态，也就意味着这个块的 空闲空间无法使用，造成空间浪费，I/O的增多。所以这些空间参数的设置对数据块的访问性能有很大的关系，必须仔细设置这些参数。顺便说一句，如果段所在的表空间已经是ASSM（自动段空间管理）表空间了， 那么PCTFREE和PCTUSED这两个参数将不再被使用，块状态由数据库自动进行管理。

在帮客户进行数据库巡检时发现，客户的库是从8i升级到9i的，因此，很多表空间仍然使用了原有的字典管理表空间模式，而这种模式的空间管理性能很差，因此建议客户将这些表空间全部换成本地管理的表空间，经过沟通，客户也认可此建议，因此，今晚开始实施。
实施之前，对整个数据库进行了备份，这是传统，也是本能（希望以后做dba的朋友们也能养成这样的习惯，当然，这次的备份倒是没派上什么用处）
丢弃字典管理表空间换成本地管理倒也不难，新创建本地管理表空间，然后把原来字典管理表空间上的存储对象移动过来就是了，对于表可以使用move，对于索引可以使用rebuild。
一切都很顺利，直到遇到了long类型字段。在move一个table时遇到了一个错误，这个表包含了long类型字段，因此无法直接move到新的位置，此时的处理方式大概有下面几个：
1、如果表中没有数据，呵呵，最简单的情况，可以直接将该表的定义用dbms_metadata.get_ddl取出，然后将表删除，修改刚才取出的ddl语句中的表空间名称定义，然后重新创建表在新的表空间上即可。当然，有数据这样作就不一定合适了
2、用exp导出，然后将原表删除，创建表到本地管理表空间上，然后导入数据，在导入的时候使用选项ignore=y(因为表已经存在)
也可以在导入之前将用户的默认表空间指向新的本地管理表空间，并且将原字典管理表空间的quota设置为0，导入也会将表生成在新的表空间上
3、在新表空间上创建出新表，使用sqlplus中的copy命令将原表数据插入新表，然后删除原表，再将新表名改为原表名（当然表上相关的索引、约束、触发器的定义要事先保存好，以便重建）。例如：
SQL> create table test(c1 varchar2(20),c2 long);

表已创建。

SQL> insert into test values('abc','abc');

已创建 1 行。

SQL> commit;

提交完成。

SQL> create table test1
2 as
3 select * from test;
select * from test
*
ERROR 位于第 3 行:
ORA-00997: 非法使用 LONG 数据类型

SQL> create table test1
2 (c1 varchar2(20),c2 long)
3 tablespace users;

SQL> copy from hr/hr@ora9i INSERT test1 using select * from test;

数组读取/结合的大小为15。（数组大小为15）
将在完成时提交。（提交的复本为 0）
最长为80。（长度为80）
1行选自hr@ora9i。
1行被插入TEST1。
1行已提交至TEST1（位于DEFAULT HOST连接）。

SQL> drop table test;

表已丢弃。

SQL> rename test1 to test;

表已重命名。

4、将long类型数据修改为lob类型（Oracle也建议以后用lob取代long，但需要考虑对应用是否有影响），然后再执行move
SQL> alter table test move tablespace users;
alter table test move tablespace users
*
ERROR 位于第 1 行:
ORA-00997: 非法使用 LONG 数据类型

SQL> alter table test modify(c2 clob);

表已更改。
SQL> create table test2
2 as
3 select * from test;

表已创建。
SQL> alter table test move tablespace users;

表已更改。

怪事年年有，今年特别多，这不，又碰上件怪事。
本来只是去给客户做个巡检，结果巡检顺利完成，客户顺便让我帮他们看个问题，说导出有问题，看看就看看吧。
10g的数据库，命令行下作exp果然出错，报了一堆莫名的错误，居然还有600错误，参数值为BqmxtrScalarIsRewritable，查metalink吧，没有这个错误参数，

查google吧，只有一个老外的blog提到了，但也只是他遇到了错误，没解决错误。。。啥问题呢，看其他提示信息，有点像数据库系统内部的问题。尝试

做dbms_metadata.get_ddl，结果报错，看来的确系统上出问题了。没啥说的，调脚本重建数据字典和系统包吧。
冷备份了数据库（千万可得记得备份阿），startup restrict 以限制模式启动数据库，然后开始调用脚本catalog.sql,catproc.sql，开始还没注意，正执行

呢，突然发现运行中报了个特别的错误：不能给dba角色授权，没有相关的角色。。。 立马觉得不对了，怎么还会没有dba角色？停了脚本，查了一

下dba_roles，果然真没有dba角色。。。难道被人删除了，问问用户，说没人删。。。唉，一到这时候一准是说没有，也没所谓了，重建dba角色就是了。还好

我机器上还有个10g的数据库，跟客户的版本相同，那就查询dba_sys_privs，dba_tab_privs，dba_col_privs等等，把该给dba角色的权限全部授予，然后再把

dba授予那些用户，应该可以了吧。。。导一把。。。还不行，忘了重建那些数据字典了，赶紧创建吧。
执行了那些脚本，记得再把失效的对象都编译了一把，重起数据库，终于，导数据成功了。。。客户说了，赶紧喝口水吧，看给累得。。。倒

过程篇：
今天准备给客户做一个数据库升级，aix5L平台上的9201升级到9206，这种事情做得也多了，本来没觉得会遇到什么问题，结果还是遇到了，幸好，问题不大。
客户的数据库不大，不过比较特别的是，这一台主机上运行着多个数据库，所以升级之前需要先关闭所有的数据库。于是以正常的方式shutdown了所有的数据库，然后准备好升级的文件包并且准备好所有的目录。
根据建议，打算重起一下主机，以确保彻底释放资源占用。按照我平时的习惯，直接reboot主机。
现象篇：
等了一会，估摸着主机起来了，连接上去，果然已经成功启动，这就打算动手升级数据库了，就在这时，su - oracle 报错了，说找不到oracle用户的主目录。奇怪啊，怎么会找不到呢，察看了一下，果然没看到那个目录，使用df -k根本没看到放那个目录的盘区，怎么回事？
想了一下，会不会是没有mount这个盘，用mount命令看了一下，果然没有mount上，难道是必须手动mount吗？问客户，客户说应该是可以自动mount的，看来还是有问题，不管怎样，先手动mount吧，结果在挂载存储的时候报错了，说该存储的superblock出现异常，需要修复。。。
还好问题不严重，用fsck对坏块进行校验修复，问题解决，存储可以mount上了。
分析篇：
以前习惯性的用reboot重起，是因为过去处理过大量saloris和linux系统的数据库，这种os上是可以直接reboot的，但是在aix上，reboot的执行方式不太一样，在aix系统中reboot并不等于shutdown+startup，而是等于shutdown abort+startup，也就是说，reboot这种方式在关闭主机的时候，并没有完整的将缓存中的数据写入磁盘，因此在启动主机后，有些存储上会出现逻辑块故障或者不完整的os块，如果出现故障的块是superblock，还可能造成无法挂载存储的情况。
解决篇：
正确重起主机的方法应该是shutdown -Fr，其他的相关命令如下：
# shutdown -m +5 系统五分钟后关闭至单一使用者模式
# shutdown -r 关机后重新开机
# shutdown now 立即关机
# shutdown -k 放弃关机
如果os上没有重要数据，而需要快速重起，那么是可以选择reboot的。

下午正在给客户干活，一个朋友突然发了个message过来，说要问我个奇怪的问题。好像有不少人都问过我“奇怪”的问题，看看吧。朋友发过来一些信息：

CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND 0

? 12940 oracle 241 20 2755M 3380K run 23:44 64.87 64.76 oracleDYKMESV2 3

? 29298 oracle 154 20 2756M 4468K sleep 13549:54 21.25 21.21 oracleDYKMESV2 1

? 6762 oracle 154 20 2756M 4300K sleep 2934:19 13.59 13.57 oracleDYKMESV2

他试图查找这些OS进程在数据库中对应的会话进程，通过下面的语句：

SQL> select pid,spid from v$process 2 where pid in ('12940','29298','6762');

未选定行

结果是一无所获，没有找到任何进程，奇怪吧。。。其实也不奇怪，搞错了v$process中字段的含义了。在v$process中，真正对应服务进程的是spid字段，也就是system process id，而他则习惯性的使用了pid字段，当然找不到拉，呵呵，如下：

CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND 2

? 8193 oracle 154 20 4375M 8060K sleep 0:07 4.79 4.78 oraclepepsi 2

? 8041 oracle 154 20 4375M 7804K sleep 0:28 3.47 3.46 oraclepepsi 2

? 25132 oracle 154 20 4359M 7932K sleep 0:43 3.33 3.32 oraclepepsi

SQL> select USERNAME,PID,SPID from v$process where spid=8193;

USERNAME PID SPID --------------- ---------- ------------

oracle 25 8193

SQL> select USERNAME,PID,SPID from v$process where spid=8041;

USERNAME PID SPID

--------------- ---------- ------------

oracle 58 8041

告诉他这个答案，他也想起来是搞错了，呵呵，不过问题还没结束，当他把错误纠正过来再次执行的时候，奇怪的事情出现了，还是没找到。。。有点问题，想了想，是不是进程已经断开了？ 不是，他回答道。。。难道是死进程？不对，该进程还在不断消耗着空间。。。有点意思啊，确实有点“奇怪” 。。。就在我绞尽脑汁，充分发挥想象力的时候，这个哥们很不好意思的发过来一个消息，我直接晕倒——他们这台机器有多个库，他查错库了！。。。呵呵，从这个事情看，有时候问题并不一定是那么复杂，答案也许就在转念之间，同时也提醒我们，谨慎而行永远是减少错误的第一要素。周末我要搞得库正 好也是单机多库，看来正好给自己了一个提醒阿。

上一次，测试了一下reset incarnation的作用，朋友又提出下一个问题，能不能跨多个实体进行恢复呢，理论上是可以的，不过没实践过，还是测试一下吧。

--首先在实体5上进行全库备份
RMAN> backup database format='c:bak%U.bak';

启动 backup 于 26-3月 -08
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=142 devtype=DISK
通道 ORA_DISK_1: 启动全部数据文件备份集
通道 ORA_DISK_1: 正在指定备份集中的数据文件
输入数据文件 fno=00001 name=E:ORACLEPRODUCT10.2.0ORADATAORCLSYSTEM01.DBF
输入数据文件 fno=00002 name=E:ORACLEPRODUCT10.2.0ORADATAORCLUNDOTBS01.DBF
输入数据文件 fno=00003 name=E:ORACLEPRODUCT10.2.0ORADATAORCLSYSAUX01.DBF
输入数据文件 fno=00004 name=E:ORACLEPRODUCT10.2.0ORADATAORCLUSERS01.DBF
通道 ORA_DISK_1: 正在启动段 1 于 26-3月 -08
通道 ORA_DISK_1: 已完成段 1 于 27-3月 -08
段句柄=C:BAKQJC96UQ_1_1.BAK 标记=TAG20080326T235922 注释=NONE
通道 ORA_DISK_1: 备份集已完成, 经过时间:00:01:05
通道 ORA_DISK_1: 启动全部数据文件备份集
通道 ORA_DISK_1: 正在指定备份集中的数据文件
备份集中包括当前控制文件
在备份集中包含当前的 SPFILE
通道 ORA_DISK_1: 正在启动段 1 于 27-3月 -08
通道 ORA_DISK_1: 已完成段 1 于 27-3月 -08
段句柄=C:BAKRJC970R_1_1.BAK 标记=TAG20080326T235922 注释=NONE
通道 ORA_DISK_1: 备份集已完成, 经过时间:00:00:04
完成 backup 于 27-3月 -08

--关闭数据库，删除当前日志文件，强制open resetlogs打开数据库
RMAN> shutdown immediate

数据库已关闭
数据库已卸载
Oracle 实例已关闭

RMAN> startup

已连接到目标数据库 (未启动)
Oracle 实例已启动
数据库已装载
数据库已打开

系统全局区域总计 314572800 字节

Fixed Size 1248768 字节
Variable Size 79692288 字节
Database Buffers 226492416 字节
Redo Buffers 7139328 字节

RMAN> shutdown immediate

数据库已关闭
数据库已卸载
Oracle 实例已关闭

RMAN> startup mount

已连接到目标数据库 (未启动)
Oracle 实例已启动
数据库已装载

系统全局区域总计 314572800 字节

Fixed Size 1248768 字节
Variable Size 79692288 字节
Database Buffers 226492416 字节
Redo Buffers 7139328 字节

RMAN> recover database;

启动 recover 于 27-3月 -08
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=157 devtype=DISK

正在开始介质的恢复
无法恢复介质

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: recover 命令 (在 03/27/2008 00:08:47 上) 失败
ORA-00283: recovery session canceled due to errors
RMAN-11003: 在分析/执行 SQL 语句期间失败: alter database recover if needed
start
ORA-00283: 恢复会话因错误而取消
ORA-19909: 数据文件 1 属于孤立的原型
ORA-01110: 数据文件 1: 'E:ORACLEPRODUCT10.2.0ORADATAORCLSYSTEM01.DBF'

RMAN> alter database open resetlogs;

数据库已打开

--打开数据库后，形成实体6
RMAN> list incarnation;

数据库原型列表
DB 关键字 Inc 关键字 DB 名 DB ID STATUS 重置 SCN 重置时间
------- ------- -------- ---------------- --- ---------- ----------
1 1 ORCL 1176767170 PARENT 1 10-3月 -08
2 2 ORCL 1176767170 PARENT 472611 25-3月 -08
3 3 ORCL 1176767170 PARENT 474163 25-3月 -08
4 4 ORCL 1176767170 PARENT 488631 26-3月 -08
5 5 ORCL 1176767170 PARENT 490308 26-3月 -08
6 6 ORCL 1176767170 CURRENT 506067 27-3月 -08

--再次关闭数据库，删除当前日志文件，通过sqlplus做open resetlogs，形成实体7
RMAN> shutdown immediate

数据库已关闭
数据库已卸载
Oracle 实例已关闭

RMAN> quit

恢复管理器完成。

D:>rman target / nocatalog

恢复管理器: Release 10.2.0.1.0 - Production on 星期四 3月 27 00:18:13 2008

Copyright (c) 1982, 2005, Oracle. All rights reserved.

连接到目标数据库: ORCL (DBID=1176767170)
使用目标数据库控制文件替代恢复目录

RMAN> list incarnation;

数据库原型列表
DB 关键字 Inc 关键字 DB 名 DB ID STATUS 重置 SCN 重置时间
------- ------- -------- ---------------- --- ---------- ----------
1 1 ORCL 1176767170 PARENT 1 10-3月 -08
2 2 ORCL 1176767170 PARENT 472611 25-3月 -08
3 3 ORCL 1176767170 PARENT 474163 25-3月 -08
4 4 ORCL 1176767170 PARENT 488631 26-3月 -08
5 5 ORCL 1176767170 PARENT 490308 26-3月 -08
6 6 ORCL 1176767170 PARENT 506067 27-3月 -08
7 7 ORCL 1176767170 CURRENT 506961 27-3月 -08

--发现有对象丢失，需要进行基于时间的恢复，但丢失对象是发生在实体5的运行过程中，因此使用实体5的备份进行不完全恢复
RMAN> shutdown immediate

数据库已关闭
数据库已卸载
Oracle 实例已关闭

RMAN> startup mount

已连接到目标数据库 (未启动)
Oracle 实例已启动
数据库已装载

系统全局区域总计 314572800 字节

Fixed Size 1248768 字节
Variable Size 79692288 字节
Database Buffers 226492416 字节
Redo Buffers 7139328 字节

--直接执行恢复命令报错，因为当前是实体7，实体7的时间在需要被恢复的时间之后
RMAN> run{
2> sql 'alter session set nls_date_format="yyyy-mm-dd hh24:mi:ss"';
3> set until time='2008-3-27 00:02:00';
4> restore database;
5> recover database;
6> alter database open resetlogs;
7> }

sql 语句: alter session set nls_date_format="yyyy-mm-dd hh24:mi:ss"

正在执行命令: SET until clause

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: set 命令 (在 03/27/2008 00:28:18 上) 失败
RMAN-20207: UNTIL TIME 或 RECOVERY WINDOW 在 RESETLOGS 时间之前

--重置数据库实体为5，然后进行基于时间的恢复
RMAN> reset database to incarnation 5;

将数据库重置为原型 5

RMAN> run{
2> sql 'alter session set nls_date_format="yyyy-mm-dd hh24:mi:ss"';
3> set until time='2008-3-27 00:02:00';
4> restore database;
5> recover database;
6> alter database open resetlogs;
7> }

sql 语句: alter session set nls_date_format="yyyy-mm-dd hh24:mi:ss"

正在执行命令: SET until clause

启动 restore 于 27-3月 -08
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: sid=157 devtype=DISK

通道 ORA_DISK_1: 正在开始恢复数据文件备份集
通道 ORA_DISK_1: 正在指定从备份集恢复的数据文件
正将数据文件00001恢复到E:ORACLEPRODUCT10.2.0ORADATAORCLSYSTEM01.DBF
正将数据文件00002恢复到E:ORACLEPRODUCT10.2.0ORADATAORCLUNDOTBS01.DBF
正将数据文件00003恢复到E:ORACLEPRODUCT10.2.0ORADATAORCLSYSAUX01.DBF
正将数据文件00004恢复到E:ORACLEPRODUCT10.2.0ORADATAORCLUSERS01.DBF
通道 ORA_DISK_1: 正在读取备份段 C:BAKQJC96UQ_1_1.BAK
通道 ORA_DISK_1: 已恢复备份段 1
段句柄 = C:BAKQJC96UQ_1_1.BAK 标记 = TAG20080326T235922
通道 ORA_DISK_1: 恢复完成, 用时: 00:01:05
完成 restore 于 27-3月 -08

启动 recover 于 27-3月 -08
使用通道 ORA_DISK_1

正在开始介质的恢复

存档日志线程 1 序列 3 已作为文件 E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREAOR
CLARCHIVELOG2008_03_27O1_MF_1_3_3YNWZ1KL_.ARC 存在于磁盘上
存档日志文件名 =E:ORACLEPRODUCT10.2.0FLASH_RECOVERY_AREAORCLARCHIVELOG200
8_03_27O1_MF_1_3_3YNWZ1KL_.ARC 线程 =1 序列 =3
介质恢复完成, 用时: 00:00:02
完成 recover 于 27-3月 -08

数据库已打开

--恢复完成，由于再次使用open resetlogs打开数据库，因此现在实体为8，而实体8的scn低于实体6、7
RMAN> list incarnation;

数据库原型列表
DB 关键字 Inc 关键字 DB 名 DB ID STATUS 重置 SCN 重置时间
------- ------- -------- ---------------- --- ---------- ----------
1 1 ORCL 1176767170 PARENT 1 10-3月 -08
2 2 ORCL 1176767170 PARENT 472611 25-3月 -08
3 3 ORCL 1176767170 PARENT 474163 25-3月 -08
4 4 ORCL 1176767170 PARENT 488631 26-3月 -08
5 5 ORCL 1176767170 PARENT 490308 26-3月 -08
8 8 ORCL 1176767170 CURRENT 505314 27-3月 -08
6 6 ORCL 1176767170 ORPHAN 506067 27-3月 -08
7 7 ORCL 1176767170 ORPHAN 506961 27-3月 -08

RMAN>

上午刚处理完客户的一个问题，正在发呆，一个哥们在msn上跟我发了个链接，问起我Oracle里incarnation的问题，本来也没想那么多，回答了几个问题，后来觉得这么说说不明白，干脆做个演示好了，于是就在这两天，作了一些incarnation的测试。
先解释一下我对incarnation的理解吧，incarnation，我把这个叫做数据库实体，不知道其他人怎么个叫法，从含义上看，它指的是一个重置scn后的数据库场景。一个数据库在刚开始被创建出来时，scn号为1，随着运行，scn不断单调递增，Oracle就是根据scn描述数据库的整个发展进程，可以说scn就是数据库的时间轴。当数据库正常运行，或者执行完全恢复时，scn只会单调递增直到最新的scn，这样数据库中所有的数据都按照时间的顺序改变着，但如果数据库出现了人为误操作，需要执行不完全恢复，这时候就得用以前备份的所有数据文件将数据版本回到以前，然后从那个起点开始应用日志，直到出现人为故障之前的那一刻，但这时，scn并未到达最新的scn，而是到了之前的某个scn，在这一刻，人为故障还未发生。在完成recover .. until .. 的操作后，所有的数据文件通过应用日志到了统一的一点，但数据库暂时还不能正常打开，因为控制文件中记录的是最新的scn，与应用日志后的数据文件并不一致，因此无法直接打开数据库回到原始的状态，必须通过resetlogs的方式强制控制文件、重做日志文件以及数据文件的scn一致，此时新打开的数据库中第一个scn等于应用日志到的最后一条日志的scn号+1（在告警日志文件中可以看到RESETLOGS after incomplete recovery UNTIL CHANGE 145936 这样的信息，打开数据库后的scn则为145937）。数据库每次resetlogs之后，scn和日志序列号都被重置，因此每次resetlogs都会产生一个新的incarnation，而incarnation的信息存储在控制文件中，在rman中可以通过list incarnation看到实体信息。 查看全文

平台：HP-UX B.11.23 ia64
数据库：Oracle9i Enterprise Edition Release 9.2.0.2.0 - 64bit Production

故障现象：客户SQL语句出现性能问题，本来想收集SQL跟踪信息，发现user_dump_dest无法写入，修改到其他路径下只能产生一次trace文件
经过查找，发现background_dump_dest也无法写入trace文件，怀疑权限有问题，决定创建新的目录，并赋予合适属组及权限，将udump和bdump指向新的目录，经过测试，发现只能在每次指定新目录后产生一次trace文件，以后在其他会话启用跟踪也无法产生新的跟踪文件，重新切换新目录后又再次可以产生一个文件，然后再另一个会话中开启跟踪无法产生新的跟踪文件，很奇怪。
进一步查找，发现/home/oracle/app/oracle/product/9.2.0/rdbms/log 产生大量trace文件，产生的trace文件与会话连接有关，在trace文件中出现了Ioctl ASYNC_CONFIG error, errno = 1的错误信息，经过确认，发现这是HP安腾机器异步I/O的错误。
解决方法：
经查询，在hp机器上不论disk_asynch_io如何设置，Oracle总是尝试开启异步I/O，而系统异步I/O默认Oracle是不能使用的，因此只需要禁用掉Oracle的异步I/O或者开启系统的异步I/O，就可解决问题。使用下面的语句重新设置权限后故障解决：
chown bin:bin /dev/async
chmod 660 /dev/async

参照Metalink：Note:302801.1 How to disable asynch_io on HP to avoid Ioctl Async_config Error Errno = 1

另外，也可以通过完成系统对异步I/O的设置来解决问题，如下：
1、创建/etc/privgroup文件,内容为：
dba MLOCK
2、执行命令/usr/sbin/setprivgrp -f /etc/privgroup
3、执行完毕，再用sqlplus登陆发现没有再生成上述的trace文件。

今天，天气晴朗，心情也不错
早上一大早就赶到客户现场，今天客户的主机终于到了，可以装数据库了，装好了经过验收，俺的那份￥就到手了，想想就觉得兴奋阿
来到机房，客户已经上班了，人家比我来得早，已经把小机就位，准备好了网络环境，就等我开装了
ok，保持着高度的兴奋感，开始工作。。。

 查看全文

很久没有写blog了，最后一次动笔要追溯到04年了，这几年工作上、生活上都发生了一系列变化，事情越来越多，心情越来越浮躁，动笔写点东西就成了一件不可完成的任务。终于有一天，朋友的一句话惊醒了我，让我一下子从每天碌碌的快速奔跑中暂停了下来，停下来想这段时间发生的那些事，也许是该让一切恢复正常了，真正的生活也许应该重新开始了。
屈指一算，做DBA已经6年多了，在这六年里，经历了很多事情，认识了很多朋友，逐渐从一个菜鸟成长为一个老鸟，对Oracle数据库的认识也越来越深刻。能够达到现在的水平，跟很多朋友的帮助是分不开的，所以这次开始动笔，也是想通过自己的经历，对初入Oracle大世界的朋友们提供一些指点和帮助，能够少走一些弯路，更快的加入到DBA大家庭里，也希望我的blog确实能对大家有一些帮助。

在监控、诊断、处理数据库性能问题的时候，时间信息往往是非常重要的判断依据。有时候可能我们会使用一些比例来判断性能，但是使用比例而不使用时间往往会将我们带向错误的方向。在Oracle9i的第一版中关于时间的信息被进行了增强，提供了更多更有益的时间信息。除了9i的外貌发生了变化，在一些并没有被我们注意或者不为人知得一些v$视图的相关字段也发生了变化。这里提到的主要是他们发生了那些改变以及对DBA有什么帮助。这里也列出了零星的一些Oracle内部的未公开的信息。

 查看全文