2007年9月20日，我从四川的一个小城市来到了成都，来到了这个熟悉又陌生的地方。说这个地方熟悉，是因为我在这里读了四年书，工作的时候偶尔也会出差到这里，每次出远门也要路过这里。说这个地方陌生，则是对于我来说，不太爱动。这里读了四年书，生活了几年，去的地方少得可怜。
想想一年之前，毅然告别了生活、工作了八年多的地方，那时心里面是非常复杂的。徬徨、紧张、憧憬……不过还好，没多久就适应了新的生活和新的工作环境，也很喜欢新的工作，我想这是令我非常高兴的一件事。
成都是一个悠闲的城市，在这样一个地方，一年内体重也增加了好几斤。不过我本来就偏瘦，增加体重说明身体更好了^_^
我喜欢平淡而又充实的生活，所以没什么大喜大悲的事情。我喜欢这样的生活。
谈不上抒情，也没有抒情的文笔，简单记录之。
在Oracle的备份恢复过程中，需要注意数据文件的unrecoverable，不适当的操作很容易造成恢复后有大量的坏块。在视图v$datafile中，UNRECOVERABLE_CHANGE#和UNRECOVERABLE_TIME分别表示数据文件最后一个unrecoverable操作的change#和时间。unrecoverable通常就是指不记录日志的操作（nologging），这样当用一个旧的数据文件还原后，用日志进行恢复时，由于日志文件没有记录unrecoverable的操作时的日志，导致那些操作的数据块为逻辑坏块（实际上在日志文件中为这样的操作产生了一些重做日志项，在恢复时，根据这些重做日志项，直接将相应的数据块标记为坏块）。常见的以下几种情况：
1. 非归档模式下的create table as 操作和直接路径插入（如加了append hint的insert语句和直接路径装载）
2. 归档模式下的create table xxx nologging（即创建表时为表指定了nologging）和nologging表的直接路径插入。
在数据库（或表空间）为force logging时，任何操作都会记录日志。不会有unrecoverable操作。
下面先做个实验（数据库版本为9.2.0.1）来看看这两列：
数据库当前处于非归档模式;
SQL> select name,checkpoint_time,unrecoverable_time from v$datafile where file#=10;
NAME CHECKPOINT_TIME UNRECOVERABLE_TIME
---------------------------------------- ------------------- -------------------
D:\ORACLE\ORADATA\XJ\TEST01.DBF 2008-09-23 09:28:22SQL> create table t tablespace test nologging as select * from dba_objects where rownum< =10;
表已创建。
SQL> select name,checkpoint_time,unrecoverable_time from v$datafile where file#=10;NAME CHECKPOINT_TIME UNRECOVERABLE_TIME
---------------------------------------- ------------------- -------------------
D:\ORACLE\ORADATA\XJ\TEST01.DBF 2008-09-23 09:28:22
可以看到，unrecoverable_time为空。想一想就可以理解，unrecoverable操作都是将数据直接写入了数据文件，没有经过SGA的缓存，非归档模式下的物理备份都是一致的冷备份，不需要日志来进行恢复，因此对于非归档模式下并不存在unrecoverable操作。unrecoverable只是针对归档模式的。下面将数据库置为归档模式后，重复上述过程，进行验证：
SQL> create table t tablespace test nologging as select * from dba_objects where rownum< =10;
表已创建。
SQL> select name,checkpoint_time,unrecoverable_time,unrecoverable_change# from v$datafile where file#=10;
NAME CHECKPOINT_TIME UNRECOVERABLE_TIME UNRECOVERABLE_CHANGE#
---------------------------------------- ------------------- ------------------- ---------------------
D:\ORACLE\ORADATA\XJ\TEST01.DBF 2008-09-23 09:45:03 2008-09-23 09:45:41 1298047可以看到，v$datafile视图中unrecoverable_time和unrecoverable_change#已经有了值。
下面来看看unrecoverable_time是最后一次unrecoverable操作的开始时间还是结束时间？
创建一个具有延时功能的函数：create or replace function f_cdate return date
as
begin
dbms_lock.sleep(10);
return sysdate;
end;SQL> create table t (d date) nologging tablespace test;
表已创建。
SQL> begin
2 dbms_output.put_line(’start test:’||sysdate);
3 insert /*+ append */ into t select f_cdate from dba_objects where rownum< =10;
4 dbms_output.put_line('after insert:'||sysdate);
5 dbms_lock.sleep(60);
6 commit;
7 dbms_output.put_line('end test:'||sysdate);
8 end;
9 /
start test:2008-09-23 10:31:50
after insert:2008-09-23 10:33:33
end test:2008-09-23 10:34:34PL/SQL 过程已成功完成。
SQL> select name,checkpoint_time,unrecoverable_time,unrecoverable_change# from v$datafile where file#=10;
NAME CHECKPOINT_TIME UNRECOVERABLE_TIME UNRECOVERABLE_CHANGE#
---------------------------------------- ------------------- ------------------- ---------------------
D:\ORACLE\ORADATA\XJ\TEST01.DBF 2008-09-23 09:45:03 2008-09-23 10:33:33 1299032
SQL> begin
2 dbms_output.put_line(’start test:’||sysdate);
3 insert /*+ append */ into t select f_cdate from dba_objects where rownum< =10;
4 dbms_output.put_line('after insert:'||sysdate);
5 dbms_lock.sleep(60);
6 rollback;
7 dbms_output.put_line('end test:'||sysdate);
8 end;
9 /
start test:2008-09-23 10:37:59
after insert:2008-09-23 10:39:42
end test:2008-09-23 10:40:43PL/SQL 过程已成功完成。
SQL> select name,checkpoint_time,unrecoverable_time,unrecoverable_change# from v$datafile where file#=10;
NAME CHECKPOINT_TIME UNRECOVERABLE_TIME UNRECOVERABLE_CHANGE#
---------------------------------------- ------------------- ------------------- ---------------------
D:\ORACLE\ORADATA\XJ\TEST01.DBF 2008-09-23 09:45:03 2008-09-23 10:39:42 1299157可以看到unrecoverable_time为unrecoverable操作完成的那个时间，不管事务是否提交。
对于数据库备份后的恢复，需要注意查询v$datafile视图中关于unrecoverable操作时间，如果unrecoverable操作时间在数据文件备份之后（更精确的比较是通过change#，比较文件的checkpoint_change#和unrecoverable_change#），则恢复会产生坏块。
建议重要的数据库，将数据库置为force logging（当然数据库应当是归档模式），避免无意的产生了unrecoverable操作。或者在做了unrecoverable操作之后立即进行数据文件的备份。
PS：关于不产生日志的操作，请参见metalink NOTE:269274.1 CHECK FOR LOGGING/NOLOGGING ON DB OBJECT(S)
无辜的孩子，无辜的伤心的家长……
我也是一个孩子的父亲，每天看着1岁多的宝贝儿子，不由会发自内心的高兴。
居然会有那么多种品牌的奶粉，有那种称之为“三聚氰胺“的东西。
网上的评论多如牛毛，我也不想再说什么，只是感到气愤，悲痛….
以前的模板，不太适合于写技术类文章，左边内容部分太窄，现在换一个。页面基调为绿色，但上去比较轻爽，似乎不太适合于技术类，不过自己的地盘，自己作主，自己喜欢就行。^_^
先说说这个数据库的环境：
Oracle 9.2.0.4 RAC，只不过这个RAC只运行了一个节点，另一节点没有开启。
AIX 5.3 TL04
主机为p550，4CPU，16G内存
应用为部署在Weblogic下的WEB应用。
故障现象：
首先是客户端的操作没有响应，从weblogic上看连接数非常高，其日志里面不停报超出连接池的最大连接数。在主机上用sqlplus “/ as sysdba”，在显示sqlplus的banner后，停止响应。
从故障现象来看，是数据库hang住了。
由于sqlplus不能操作，那么这个时候没办法通过oracle来dump system state。先看看操作系统里面，用topas命令观察，发现一个oracle进程占用了26%左右的CPU资源，IO等待几乎为0，可用的物理内存还比较多。根据那个占用CPU的进程号用ps命令查看，是一个普通的Server Process。
看来起这个进程陷入死循环了，26%的CPU资源正好是1个CPU（因为系统共4个CPU）。如果一个oracle进程拿到比较重要的资源，比如shared pool latch、library cache latch等，然后陷入了死循环（SPIN）后，其他进程没法解析SQL等，也就只有挂起了。
用kill命令杀掉那个进程，系统恢复正常，看来前面对故障的推断是正确的，不过没过几分钟，又出现了此故障现象。
只有找到oracle当时正在干什么，才能进行处理。用dbx来dump system state：
# dbx -a 446910
Waiting to attach to process 446910 …
Successfully attached to oracle.
Type ‘help’ for help.
reading symbolic information …
stopped in iosl.select at 0×9000000000c94d8 ($t2)
0×9000000000c94d8 (select+0xfffffffffff06318) e8410028 ld r2,0×28(r1)
(dbx) print ksudss(10)Segmentation fault in slrac at 0×100083aa0 ($t2)
0×100083aa0 (slrac+0xe4) 88030000 lbz r0,0×0(r3)
(dbx) detach
经常遇到客户和其他一些Oracle开发与维护人员，问我为啥使用了RAC，没有感受到业务系统有明显的性能提升，有时反而觉得性能有所下降。这种认为RAC一定能够提高性能的想法，有着广泛的“群众基础”。可以说，使用RAC来提高性能是一种存在于广大ORACLE数据库使用者之间的误解。
这里我不想过多于技术上去解答这个问题，而是从下面这个类比来说明这个问题：
这里我们要谈论的是大部分的业务系统类型，事务处理型，也就是OLTP。虽然很多OLTP类型的系统还兼有生成一些报表和统计数据的功能，但那只是一部分小的功能，主要还是事务处理。
大家都去过银行，假设一个银行营业厅有6个业务窗口，来这个营业厅办理业务的客户一般为3至5个人，最多6个人。由于每个人办理业务的时间，是跟他（她）的业务类型有关的，比如取款2分钟，存款2分钟，开户要5分钟等等，不会以窗口数的增多而减少时间。以这个例子来说，6个窗口已经足够了，因为6个窗口数大于同时办理业务的客户数，而一个客户只会在一个窗口办理业务，就算再多的业务处理窗口，也不会对每个客户办理业务有速度上的提升。
现在假设银行的业务有了很大的发呢，银行营业厅里面的客户比较多了，同时来办理业务的常常超过10人，这个时候就是银行营业厅的窗口不够了（资源不足），客户存在了排队，严重影响了客户办理业务的效率。而营业厅由于受面积的限制，不能增加窗口了（对于机器来说，不能扩容了），这个时候银行在附近又开了一个新的营业厅（增加了一个新的结点），那样部分客户分流到了新的营业厅，这样消除了客户的排队，客户又能够高效率地在银行办理业务了。
使用RAC类似于上面提到的银行，如果业务系统能够在单台机器上跑，这个时候由于资源足够，增加新的结点不会带来性能上的提升，而如果随着业务的发展，机器资源受限，不能为更多的用户服务，这个时候增加新的结点，能够使业务系统能够为更多的用户服务。
然而在现实生活中，很多业务系统并没有为RAC进行一些优化，同时RAC的结点之间由于数据同步的代价比较高，因而使用RAC后往往感受到业务系统并没有更快，有时感觉反而更慢。
RAC的作用更体现于高可用性、水平可扩展性，其次才是某些条件下的性能提升（比如针对于某些DSS系统）。
到成都工作以来，最漫长的一次出差。为了处理一个故障，已经出差10来天了，有达到半个月的趋势。不可控的因素，导致这么长时间的出差，虽然比项目实施出差的时间短，但以我们这种工作性质来说算是比较长的了。
看看什么时候会再次打破这个记录。
下面一条SQL能够使用索引吗？
select object_id,object_name,object_type from t1 where object_id is null;
有人会说，索引不存储null值，所以这个SQL不会使用索引；也有人会说，能够使用索引啊，只要在object_id列上建位图索引就可以使用索引了，另外对于CLUSTER表的KEY列，null值也可以存储在索引中（也就是能够进行索引）。
本文要探讨的是，null值不能进行索引的真正含义：
实际上对于null值，除了位图索引、CLUSTER表的KEY列，也是有可能索引的。那就是复合索引，也就是多列索引。对于普通的索引，null值不能进行索引的正确理解应该是，对于某一行，索引的所有列的值都是null值时，该行才不能被索引。
那么对于上面的SQL语句，我们就可以想办法让它走索引。下面举例说明：
SQL> desc t1
名称 是否为空? 类型
----------------------------------------- -------- --------------
OWNER VARCHAR2(30)
OBJECT_NAME NOT NULL VARCHAR2(128)
SUBOBJECT_NAME VARCHAR2(30)
OBJECT_ID NUMBER
DATA_OBJECT_ID NUMBER
OBJECT_TYPE VARCHAR2(18)
CREATED DATE
LAST_DDL_TIME DATE
TIMESTAMP VARCHAR2(19)
STATUS VARCHAR2(7)
TEMPORARY VARCHAR2(1)
GENERATED VARCHAR2(1)
SECONDARY VARCHAR2(1)SQL> create index t1_idx on t1(object_id,object_name);
SQL> analyze table t1 compute statistics for table for all indexes for all indexed columns;表已分析。
SQL> select object_id,object_name,object_type from t1 where object_id is null;OBJECT_ID OBJECT_NAME OBJECT_TYPE
---------- ------------------------------ ------------------------------
XTY DATABASE LINKExecution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1 Bytes=38)
1 0 TABLE ACCESS (BY INDEX ROWID) OF ‘T1′ (Cost=3 Card=1 Bytes
=38)2 1 INDEX (RANGE SCAN) OF ‘T1_IDX’ (NON-UNIQUE) (Cost=2 Card
=1)
我们可以看到，这个SQL语句走了我们建的那个索引T1_IDX。
然而，如果我们把object_name列改为允许NULL值，那么情况就发生了变化：
SQL>alter table t1 modify (object_name null);
SQL> select object_id,object_name,object_type from t1 where object_id is null;OBJECT_ID OBJECT_NAME OBJECT_TYPE
---------- ------------------------------ ------------------------------
XTY DATABASE LINKExecution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=128 Card=1 Bytes=38)
1 0 TABLE ACCESS (FULL) OF ‘T1′ (Cost=128 Card=1 Bytes=38)
把object_name列改为允许NULL值后，object_id和object_name列 有可能同时为NULL值，这个时候就存在着不被索引的行（就是有可能存在object_id值为null的行没有被索引），这样就只能走全表扫描了。
我们也有一种更简便的方法，不需要与其他列建立复合索引，而是与一个常量值建立复合索引：
SQL> create index t1_idx on t1(object_id,0);
SQL> analyze table t1 compute statistics for table for all indexes for all indexed columns;
SQL> explain plan for select object_id,object_name,object_type from t1 where object_id is null;
已解释。
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 81 | 3 |
| 1 | TABLE ACCESS BY INDEX ROWID| T1 | 1 | 81 | 3 |
|* 2 | INDEX RANGE SCAN | T1_IDX | 1 | | 2 |
---------------------------------------------------------------------------Predicate Information (identified by operation id):
---------------------------------------------------PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------2 - access(”T1″.”OBJECT_ID” IS NULL)
Note: cpu costing is off
引申开来，如果有类似于col_name is null这样的条件的SQL语句，希望能够使用索引，那么将col_name与其他NOT NULL的列或一个常量值建一个复合索引，也是一个可能的选择。
大家在管理ORACLE数据库时，通常使用PROFILE对用户密码设置期限，但是需要注意应用系统连接的用户，对于密码期限设置，应谨慎处理。
首先我们看看怎么样为用户设置密码有效期：
在测试例子中，我们使用TEST用户进行测试，密码为TEST，先看看用户的状态。
SQL> select account_status,lock_date,expiry_date,created,profile from dba_users where username=’TEST’;
ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE CREATED PROFILE
-------------- ---------- ----------- ------------------- -------
OPEN 2008-03-27 15:29:18 DEFAULTSQL> select ctime,ptime,exptime,ltime,spare6 from user$ where name=’TEST’;
CTIME PTIME EXPTIME LTIME SPARE6
------------------- ------------------- ------------------- ------------------- -------------------
2008-03-27 15:29:18 2008-03-27 15:29:18
在user$数据字典中，有几个字段是dba_users中看不到的。比如PTIME（应该就是密码设置或修改的时间），这里PTIME=CREATED（因为用户创建后没有改变过密码）
下面我们将创建profile，将密码有效期设置为10天，并将用户TEST的PROFILE设置为创建的test_profile：
SQL> create profile test_profile limit password_life_time 10 password_grace_time 0;
配置文件已创建
SQL> alter user test profile test_profile;
用户已更改。
再看看用户数据：
SQL> select account_status,lock_date,expiry_date,created,profile from dba_users where username=’TEST’;
ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE CREATED PROFILE
------------------------------ ------------------- ------------------- ------------------- ------------
OPEN 2008-04-06 15:29:18 2008-03-27 15:29:18 TEST_PROFILESQL> select ctime,ptime,exptime,ltime,spare6 from user$ where name=’TEST’;
CTIME PTIME EXPTIME LTIME SPARE6
------------------- ------------------- ------------------- ------------------- -------------------
2008-03-27 15:29:18 2008-03-27 15:29:18
注意到除了PROFILE列从DEFAULT变为了TEST_PROFILE，EXPIRY_DATE改变了，正好是PTIME+10。注意在USER$表中，EXPTIME为空，DBA_USERS中的EXPIRY_TIME是通过PTIME和PROFILE计算出来的。因此EXPIRY_TIME为密码将要到期的时间。
现在为用户设置好了PROFILE，新开一个SQLPLUS会话，用TEST用户登录：
SQL> connect test/test
ERROR:
ORA-28001: the password has expired更改test的口令
新口令:
这个时候可以修改用户的密码。但是如果是应用软件没有对ORA-28001错误进行处理，则不能进行连接。这个时候我们看看用户的状态：
SQL> select account_status,lock_date,expiry_date,created,profile from dba_users where username=’TEST’;
ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE CREATED PROFILE
------------------------------ ------------------- ------------------- ------------------- ------------
EXPIRED 2008-03-27 15:29:18 TEST_PROFILE
SQL> select account_status,lock_date,expiry_date,created,profile from dba_users where username=’TEST’;ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE CREATED PROFILE
------------------------------ ------------------- ------------------- ------------------- ------------
EXPIRED 2008-03-27 15:29:18 TEST_PROFILE
可以看到用户状态为EXPIRED。这个状态是记录在数据字典USER$中的，如果此时把用户的PROFILE改回为DEFAULT，这个状态仍然不会改变。
SQL> alter user test profile default;
用户已更改。
SQL> select account_status,lock_date,expiry_date,created,profile from dba_users where username=’TEST’;
ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE CREATED PROFILE
------------------------------ ------------------- ------------------- ------------------- ------------
EXPIRED 2008-03-27 15:29:18 DEFAULT
用户状态仍然为EXPIRED。这个时候，如果应用连接不上数据库，只有DBA手工干预了。对于状态为LOCKED的用户，使用alter user user_name account unlock即可。对于EXPIRED状态的用户，没有UNEXPIRE的命令，只有通过修改用户密码来重设状态：
SQL> alter user test identified by test;
用户已更改。
SQL> select account_status,lock_date,expiry_date,created,profile from dba_users where username=’TEST’;
ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE CREATED PROFILE
------------------------------ ------------------- ------------------- ------------------- ------------
OPEN 2008-03-27 15:29:18 DEFAULT可以看到用户状态已经恢复正常。
SQL> select ctime,ptime,exptime,ltime,spare6 from user$ where name=’TEST’;
CTIME PTIME EXPTIME LTIME SPARE6
------------------- ------------------- ------------------- ------------------- ------------------
2008-03-27 15:29:18 2008-08-13 23:16:42
用户的密码设置时间也发生了变化。
如果在某些情况下，不知道用户的密码，可以通过下面的办法来设置密码：
SQL> select password from dba_users where username=’TEST’;
PASSWORD
------------------------------
7A0F2B316C212D67SQL> alter user test identified by values ‘7A0F2B316C212D67′;
用户已更改。
总结：对于为用户设置了密码有效期限的用户，应用软件应能够处理ORA-28001错误，或者DBA应定期对密码进行重设。否则不要为用户密码设置期限，当然对于DBA帐号，为安全起见，通过PROFILE强制要求用户定期修改密码，并且可以要求每次使用的密码不能使用以前使用的密码。
虽然大部分时候都是在用Oracle9i，就算用10g，新特性也用得不多，但现在连11g都出来一年了，再这样下去就成老古董啦。所以如今从头把concepts来看，不过这次是10g的版本。数年之前，曾经看过两遍8i的concepts，9i的concepts也读过两遍，看来这10g的concepts只需要一遍就够了。
Oracle的经典书籍何其多，我也仔细看过数本，但我觉得最实在的还是Oracle的官方文档。不管怎么忙，一天至少要看10页，不是简单的看，而是要真正理解。希望从concept这本最经典的书中挖掘出以往不曾注意到的价值。
Recent Comments