早上就接到个电话，说是美国的快件，问我送到哪里，有点紧张的告诉快递公司我的地址，放下电话就开始琢磨，美国。。。。谁给我快递东西了。。。。难道是。。。。她。。。。不可能不可能。。。
中午吃饭，又收到电话，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这两个参数将不再被使用，块状态由数据库自动进行管理。

我捐了，捐的不多，1000元，但这是第一次，以后，还会有第二次，第三次，第四次。。。。

每天打开电视，看得第一个节目，就是地震灾区的救灾直播，打开电脑，关注的第一个页面，就是地震救灾中又救了多少人，与朋友的聊天，第一句话，就是，你捐了了嘛。。。

看着灾区那么多受灾的人，尤其是那一个个受伤的孩子，废墟中伸出的一双双手，心很难受。。。

捐吧，捐了的钱我们还能挣，而这些钱对于灾区的人民，也许就是他们温饱的饭，避寒的衣，挡雨的伞，或者是减少他们痛苦的药，对于生命和享受，你还有什么可选择的，捐。。。

震灾晚会在进行着，人们都在捐款，钱越来越多，灾区的人民生存的希望也就越大，看着那些画面，泪满了眼。。。

这两天最关心的莫过于数字——一个大地震的伤亡数字，一个在不断递增，不断在人们心上、身上刻着、刺着、划着，带来巨大伤痛的数字，从7000到8000多，到11000多，现在，已经12000多，而从报道的情况看，可能还会有更多，也许是2万，或者。。。
看着心疼，尤其是看到那些照片，原本还天真活泼的孩子，没有了可爱的笑容，只剩下一本书放在脸上，遮盖着已经没有任何生气地脸，而那些父母，哭天喊地的悲痛欲绝，这不是人间惨剧，还是什么。为什么倒塌了那么多学校，为什么伤亡了那么多孩子，为什么这么大的地震居然一点前期预报都没有，只剩下心疼地感觉，慢慢的心痛的都麻木了。。。
早上翻看着报纸，一篇篇的报道，一串串的数字，当看到无数的企业、组织、个人都在捐款，无数的人在组织者捐血捐钱捐物，无数的人群在关心着这个事件，眼眶不禁的湿了，虽然还没有哭出来，但心已经感动。灾难中，我们更需要同心。。。

今天，最大的事情看来就是地震了
正在上网，一个消息从朋友的MSN发了过来，说西安地震了，而且在震中，让我赶紧跟家里联系一下。。。开始并没有太在意，在网上看了一下，震中不是在西安，而是在四川汶川县，不过地震等级确实挺高的。想了想，四川离西安还是有一定距离的，应该没事。
没过多久，突然发现几乎所有的QQ群里都出现了大量的地震信息，北京地震。。。重庆地震。。。杭州地震。。。山西地震。。。连大老远的上海都有地震了，靠，那西安肯定也会震阿，赶紧打个电话吧。
这一打不要紧，结果我们家3个手机没一个能打通的，从3点多一直打到5点，这可急死我了，也没啥心情干活了，着急啊，还好从西安的朋友口中得到消息，西安那边震得并不严重，应该没什么问题。。。
网上看到消息，2008年05月12日14时28分04.0秒，在四川汶川县发生M7.8级地震，震中位于北纬31.0度，东经103.4度。12日14时35分左右，北京、上海等地区明显感觉到有地震发生。
5点15分，终于打通了电话，全家没有任何问题，仅仅是西安市移动、联通的线路全忙，无法拨通，连市内自己也无法拨打电话，看来这次虽然人员损失不大，但整体影响还是非常夸张的。
今年看，真是个大灾年阿，希望全家人都平平安安，也希望朋友们都一切顺利，这样的灾难最好别发生了，老天保佑。

在帮客户进行数据库巡检时发现，客户的库是从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;

表已更改。

北京飞上海，特意没带刀具，没带打火机，没带易燃易爆危险品，枪也没带，连洗漱用品都基本省略，就带了毛巾、牙刷、牙膏（80毫升），离京没事，一切顺利。上海虹桥被要求放弃牙膏，理由：疑似危险品。。。旁边mm携带数瓶洗面奶、擦脸油之类，被放行，问官之，官曰：洗漱用品小于100毫升可带，牙膏无论多少毫升，不可带！ 靠，后来一捉摸，估计牙膏类似塑胶炸药了

北京飞南京，这次牙膏也不带了，带了空水瓶，这样过了安检还可以接点水喝，登机无碍，一切顺利。 南京机场，临安检前特意大灌了几口水，应把瓶子水放空，刚灌爆肚子，旁边机场地勤mm过来说了一句话，请把瓶子抛弃。。。我很疑惑的问了一句，空瓶子也不能带吗。。。mm很蔑视的看了我一眼，就挤出两个字：当然。。。晕倒，我又很不好意思地低声问了一句。。。那我要渴了怎么办，人家很不情愿的说了一句，我们里面给你们准备水了，进去就能喝。。。。。。你说我还能说什么。。。。。。可问题是，我丢了水瓶，过了安检，进去找了半天，果然有水。。。不过没有水杯

怪事年年有，今年特别多，这不，又碰上件怪事。
本来只是去给客户做个巡检，结果巡检顺利完成，客户顺便让我帮他们看个问题，说导出有问题，看看就看看吧。
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>