DBARoad：我的DBA之路

3D－阿凡达

OoNiceDream — Sat, 06 Feb 2010 21:54:04 +0800

阿凡达口碑不错，看过的同志都说好。我这个土人也趁着影院打折，赶紧去凑个热闹。

的确挺不错，画面很精彩，植物的3D效果最明显了，感觉就在眼前，影片中有个扔催泪弹的镜头，吓我一跳，还以为是真扔过来了。

看完后，眼睛没啥感觉，但头好晕，晃晃都痛。。。。

这还是我第一次看3D电影，OUT了。回来搜了下3D历史，发现第一部3D电影，在1922年就出来了，叫《爱的力量》：

3D电影年代记：1839–2009

1839年，英国科学家查理-惠斯顿爵士根据“人类两只眼睛的成像是不同的”发明了一种立体眼镜，让人们的左眼和右眼在看同样图像时产生不同效果，这就是今天3D眼镜的原理。

19世纪末，英国威廉姆-弗莱斯-格林发明了世界上第一套放映和观看3D电影的装置，但因繁杂缺乏实用推广性，所以并没有戏院采用。

1900年，弗雷德里克-尤金-艾维斯发明了模仿人眼原理的立体摄像机。

1915年6月10日，埃德温-波特和威廉-瓦德尔在纽约阿斯特戏院试验他们的红绿立体电影，放映了包括田园风光在内的多段测试片段，现场仅一位观众。

1922年9月27日，哈利-费尔奥和摄像师罗伯特-艾尔德制作世界上第一部3D电影《爱的力量》，采用了红绿立体电影模式，在洛杉矶大使饭店戏院放映的，同样只有一名观众，院线没人愿买。

20年代末30年代初，法国路易斯-卢米埃尔把他1895年的《火车进站》制作成了3D电影。

1936年，雅各布-莱温赛尔和约翰-诺林为米高梅公司拍摄了短片《Audioscopiks》系列，入场观众都被发了一副红绿眼镜，效果在当时极其震撼，该片获得了当年奥斯卡最佳短片奖的提名。

转自：http://yule.sohu.com/s2009/0623/s269228614/index.shtml

历史够悠久的。

阿凡达是挺精彩的，不过3D的，如果让我看第二遍，想想还是算了，比起精彩的画面，还是让脑袋轻松点的好

— The End —

记一次DUL恢复

OoNiceDream — Sat, 30 Jan 2010 21:33:01 +0800

前段时间有一个用DUL恢复的案例，记录一下：
由于某些原因，该库无备份，归档5分钟清一次。recyclebin没打开，一张分区表，有46个分区被DROP了，最终采用DUL工具来恢复。

使用DUL恢复，关键在于找到表的data object id，而归档被清，也无法使用LogMiner来查找。
还好有建表语句，最终根据表字段个数来匹配找到了一些 data object id，而且找到data object id都是连续的，前五条数据也与被删数据有些相似。

但还有10几个分区无法找到。由于表的分区键是一个年份月份的字段，根据正常情况下，分区表的data object id应该是连续，把缺失的10个分区的data object id补齐，如下所示，猜测缺失分区的data_object_id(加粗部份)：

DATA_OBJECT_ID	PARTITION NAME
   374552	          200603
   374553	          200604
   374554	          200605
   374555	          200606
   374556	          200607
   374557	          200608
   374558	          200609
   374559	          200610
   374560	          200611
   374561	          200612
   374562	          200701
   374563	          200702
   374564	          200703
   374565	          200704

再把找到的data object id到 scan tables时的输出中去查找，发现原来有如下报错：

Analyzing segment: data object id 374559 segment header at ( file 82 block 5659)
  heap organized table
DUL: Error: hi water extent does not exist
  No rows found in this table

但这一报错信息没有影响表的unload，挺奇怪，表数据成功恢复。

第一次使用这种工具，没经验，总结了一下，如果再有类似的情况发生，应该先做好以下两步：
1、首先应尝试使用flashback找到data object id（sys.obj$的dataobj#字段），这个是最省力的。
2、归档日志要保存好。

后来用DUL做了一些恢复实验，感觉挺强的，真佩服写这些工具的人，d.c.b.a和熊哥真是强啊！

— The End —

遭遇enq: RO - fast object reuse BUG

OoNiceDream — Mon, 25 Jan 2010 20:01:46 +0800

半夜被叫醒，唉，最近真是没休息好。。。
说是表分析很慢，检查了一下，发现表分析的进程等待事件是enq: RO - fast object reuse。TYPE为RO的，p这个真没见过。检查持有锁的会话，居然是CKPT进程。查看CKPT进程的等待事件，一般都是rdbms ipc message，也正常啊。

查询了v$locked_object、v$lock看看在分析的表是否有被锁住，发现没有。

既然跟CKPT进程有关，尝试了一些相关操作：
checkpoint、archivelog current、flush buffer cache

其中flush buffer cache似乎有一些作用，flush完后，enqueue消失，可过会又出现了。。。

当时还杂七杂八做了些查询，记不清了。最后还是到metalink上查了查，看看是不是有什么BUG。找到一个类似的：

Applies to: 
Oracle Server - Enterprise Edition - Version: 10.2.0.4
This problem can occur on any platform.
 
Symptoms
* Database has been recently upgraded from 10.2.0.1 to 10.2.0.4.
* There is 'enq: RO - fast object reuse' contention when gathering 
  schema/table statistics in parallel using DBMS_STATS package (with DEGREE>1).
 
 
Cause
Bug 7385253 10.2.0.4 RDBMS 10.2.0.4 BUFFER CACHE PRODID-5 PORTID-59
Abstract: DBWR IS CONSUMING HIGH CPU
 
The system state dumps shows that the CKPT background process is the one 
holding the needed RO enqueue although it is actually doing nothing.

版本相同，也是使用DBMS_STATS进行分析，DEGREE 10，看来是遇上了。将脚本里的DEGREE去掉,继续分析，正常了。

跟这个等待事件相关的BUG还挺多，什么truncate、drop partition table都有可能遇到。

后记：
分析脚本是一个表一个表地分析，等待是在分析到其中一个表时出现的。其间杀掉重启分析过几次，无效。去掉该表的分析，其它表的分析不受影响。后来，应用人员向我反应，他们当时也在分析这张表，不过后来停了，汗，没发现。检查他们分析的会话，僵死在那了。不过单进程分析该表还是不受影响的。

— The End —

如何对listener进行跟踪

OoNiceDream — Fri, 15 Jan 2010 21:39:07 +0800

对listener进行跟踪，产生trace文件，是诊断listener问题不错的手段。可以在listener.ora中添加以下内容来进行跟踪：

TRACE_LEVEL_LISTENER_T = 16
TRACE_FILE_LISTENER_T = LISTENER.TRC
TRACE_DIRECTORY_LISTENER_T = /app/oracle/product/9205/network/admin
TRACE_TIMESTAMP_LISTENER_T = ON

“LISTENER_T”是listenerd name，各个参数含义如下：

TRACE_LEVEL_LISTENER       批定TRACE级别
TRACE_FILE_LISTENER        指定TRACE文件名称
TRACE_DIRECTORY_LISTENER   指定TRACE文件目录
TRACE_TIMESTAMP_LISTENER   指定是否在TRACE文件中添加时间戳

启动监听时，就可以看到生成的TRACE文件了（Listener Trace File）：

STATUS of the LISTENER
------------------------
Alias                     listener_t
Version                   TNSLSNR for HPUX: Version 9.2.0.8.0 - Production
Start Date                31-OCT-2009 16:31:07
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               support
Security                  OFF
SNMP                      OFF
Listener Parameter File   /app/oracle/product/9205/network/admin/listener.ora
Listener Log File         /app/oracle/product/9205/network/log/listener_t.log
Listener Trace File       /app/oracle/product/9205/network/admin/listener.trc

这些参数中，最重要的TRACE_LEVEL_LISTENER，其它参数按照默认设置就可以了。要生成TRACE，最简单的设置如下：

TRACE_LEVEL_LISTENER_T = 6

默认情况下，TRACE文件就会生到：

Listener Trace File       /app/oracle/product/9205/network/trace/listener_t.trc

TRACE_LEVEL_LISTENER设定的level可以是从0－16,level越高，生成的信息越多，默认是0，也就是不生成TRACE。另外一些level还可以用相应的英文字符代替：

OFF (equivalent to 0) disabled - provides no tracing.
USER (equivalent to 4) traces to identify user-induced error conditions.
ADMIN (equivalent to 6) traces to identify installation-specific problems.
SUPPORT (equivalent to 16) trace information required by OSS for troubleshooting.

例如：

TRACE_LEVEL_LISTENER_T = admin

— The End —

关于JOB的两个小问题

OoNiceDream — Wed, 13 Jan 2010 11:56:04 +0800

1、INTERVAL设置错误引起的ORA-12005错误
INTERVAL函数写得不对，常会引起ORA-12005的报错，alter log中会出现以下报错信息：

Errors in file /app/oracle/admin/DBA/bdump/dba_j000_28406.trc:
ORA-12012: error on auto execute of job 2
ORA-12005: may not schedule automatic refresh for times in the past

这个报错提示的是：JOB根据INTERVAL函数算出来的NEXT_DATE时间，是一个过去的时间，也就是比当前的时间还要早。
这个报错比较容易模拟：
将INTERVAL设成trunc(SYSDATE)+635/1440，计算出来的NEXT_DATE也就是2010-01-13 10:35:00。
JOB执行时间是10:32，需执行5分钟。
这样，等JOB执行完后，再去更新NEXT_DATE时，已经过了10:35，自然就报错了。

sys@ORCL>create or replace procedure proc_time
  2  as
  3  begin
  4  insert into t values(sysdate);
  5  commit;
  6  dbms_lock.sleep(300);
  7  end;
  8  /
 
过程已创建。
 
sys@ORCL>select trunc(SYSDATE)+635/1440 time,sysdate from dual;
 
TIME                SYSDATE
------------------- -------------------
2010-01-13 10:35:00 2010-01-13 10:31:57
 
 
sys@ORCL>DECLARE
  2    jobno number;
  3  BEGIN
  4    sys.DBMS_JOB.SUBMIT
  5      ( job       => jobno ,
  6        what      => 'proc_time;',
  7       next_date => sysdate,
  8       interval  => 'trunc(SYSDATE)+635/1440');
  9    commit;
 10  END;
 11  /
 
PL/SQL 过程已成功完成。
 
sys@ORCL>select * from t;
 
TIME
-------------------
2010-01-13 10:32:16
 
sys@ORCL>select job,LAST_DATE,NEXT_DATE,INTERVAL,FAILURES from dba_jobs;
 
JOB LAST_DATE           NEXT_DATE           INTERVAL                         FAILURES
--- ------------------- ------------------- ------------------------------ ----------
 22                     2010-01-13 10:32:13 trunc(SYSDATE)+635/1440
 
sys@ORCL>select job,LAST_DATE,NEXT_DATE,INTERVAL,FAILURES from dba_jobs;
 
JOB LAST_DATE           NEXT_DATE           INTERVAL                         FAILURES
--- ------------------- ------------------- ------------------------------ ----------
 22 2010-01-13 10:32:16 2010-01-13 10:39:21 trunc(SYSDATE)+635/1440                 1
 
sys@ORCL>select job,LAST_DATE,NEXT_DATE,INTERVAL,FAILURES from dba_jobs;
 
JOB LAST_DATE           NEXT_DATE           INTERVAL                         FAILURES
--- ------------------- ------------------- ------------------------------ ----------
 22 2010-01-13 10:32:16 2010-01-13 10:51:31 trunc(SYSDATE)+635/1440                 3
 
sys@ORCL>select * from t;
 
TIME
-------------------
2010-01-13 10:32:16

alter log里的报错信息：

Errors in file d:\oracle\product\10.2.0\db_1\admin\orcl\bdump\orcl_j000_3428.trc:
ORA-12012: 自动执行作业 22 出错
ORA-12005: 不能安排过去时间的自动刷新

这里需要注意的是，JOB第一次执行时，是成功的，虽然也报错了。其后再去执行JOB，报错，但JOB是执行失败的。

2、JOB的执行时间与比interval的间隔长
比如JOB的执行时间是2分钟，间隔是1分种，那JOB的执行情况是怎么呢？这个问题被问到几次，记录一下：

SQL> create table t (time date);
 
Table created.
 
SQL> create or replace procedure proc_last_two
  2  as
  3  begin
  4  insert into t values(sysdate);
  5  commit;
  6  dbms_lock.sleep(120);
  7  end;
  8  /
 
Procedure created	.
 
SQL> DECLARE
  2    jobno number;
  3  BEGIN
  4    sys.DBMS_JOB.SUBMIT
  5      ( job       => jobno ,
  6        what      => 'proc_last_two;',
  7       next_date => sysdate,
  8       interval  => 'SYSDATE+1/1440'
  9      );
 10    commit;
 11  END;
 12  /
 
PL/SQL procedure successfully completed.
 
 
SQL> alter session set nls_date_format='YYYY-MM-DD HH24:MI:SS';
 
Session altered.
 
 
SQL> select * from t;  
 
TIME
-------------------
2010-01-10 17:10:08
2010-01-10 17:12:09
2010-01-10 17:14:09
2010-01-10 17:16:09
 
SQL> select job,LAST_DATE,NEXT_DATE,INTERVAL from dba_jobs;
 
       JOB LAST_DATE           NEXT_DATE           INTERVAL           FAILURES
---------- ------------------- ------------------- ---------------- ----------
         1 2010-01-10 17:14:09 2010-01-10 17:16:09 SYSDATE+1/1440            0

从结果来看，这种情况下，JOB是正常执行的，而间隔变成了2分钟，也就是JOB执行完了，马上又开始执行了。

— The End —

分析函数lag over使用一例

OoNiceDream — Tue, 05 Jan 2010 19:24:45 +0800

常常需要从statspack中取一些数据做分析，比如找出SQL的执行次数、逻辑读等等做一些图表。这些数据都是累加的，所以需要找出两个时间点的差值，这时候 lag over分析函数就显得很有用了。

使用方法很简单，看看就明白了：

SYS@ORCL> select instance_number,
  2         hash_value,
  3         snap_id,
  4         executions,
  5         lag(executions) over(partition by instance_number order by snap_id) executions_2
  6    from stats$sql_summary
  7   where instance_number = 1
  8     and hash_value = 1631115727
  9     and rownum < 10;
 
INSTANCE_NUMBER HASH_VALUE    SNAP_ID EXECUTIONS EXECUTIONS_2
--------------- ---------- ---------- ---------- ------------
              1 1631115727     171805  391763480
              1 1631115727     171806  391777907    391763480
              1 1631115727     171807  391785841    391777907
              1 1631115727     171808  391789826    391785841
              1 1631115727     171809  391820963    391789826
              1 1631115727     171810  391823499    391820963
              1 1631115727     171811  391842421    391823499
              1 1631115727     171812  391865972    391842421
              1 1631115727     171823  391942698    391865972
 
 
SYS@ORCL> select a.instance_number,
  2         a.hash_value,
  3         a.snap_id,
  4         a.executions,
  5         lag(a.executions) over(partition by a.instance_number order by a.snap_id) executions_2,
  6         b.snap_time
  7    from stats$sql_summary a, stats$snapshot b
  8   where a.instance_number = b.instance_number
  9     and a.snap_id = b.snap_id
 10     and a.instance_number = 1
 11     and a.hash_value = 1631115727
 12     and b.snap_time between
 13         to_date('2009-11-20 09:00:00', 'YYYY-MM-DD HH24:MI:SS') and
 14         to_date('2009-11-20 10:00:00', 'YYYY-MM-DD HH24:MI:SS');
 
INSTANCE_NUMBER HASH_VALUE    SNAP_ID EXECUTIONS EXECUTIONS_2 SNAP_TIME
--------------- ---------- ---------- ---------- ------------ ----------------
              1 1631115727     172613     605418              2009-11-20 09:03
              1 1631115727     172614     828542       605418 2009-11-20 09:18
              1 1631115727     172615    1065701       828542 2009-11-20 09:33
              1 1631115727     172616    1307154      1065701 2009-11-20 09:48
 
 
SYS@ORCL> select a.instance_number,
  2         a.hash_value,
  3         a.snap_id,
  4         (a.executions - lag(a.executions)
  5          over(partition by a.instance_number order by a.snap_id)) executions,
  6         b.snap_time
  7    from stats$sql_summary a, stats$snapshot b
  8   where a.instance_number = b.instance_number
  9     and a.snap_id = b.snap_id
 10     and a.instance_number = 1
 11     and a.hash_value = 1631115727
 12     and b.snap_time between
 13         to_date('2009-11-20 09:00:00', 'YYYY-MM-DD HH24:MI:SS') and
 14         to_date('2009-11-20 10:00:00', 'YYYY-MM-DD HH24:MI:SS');
 
INSTANCE_NUMBER HASH_VALUE    SNAP_ID EXECUTIONS SNAP_TIME
--------------- ---------- ---------- ---------- ----------------
              1 1631115727     172613            2009-11-20 09:03
              1 1631115727     172614     223124 2009-11-20 09:18
              1 1631115727     172615     237159 2009-11-20 09:33
              1 1631115727     172616     241453 2009-11-20 09:48

— The End —

新域名dbaroad.me

OoNiceDream — Mon, 04 Jan 2010 22:44:09 +0800

杯具！真是杯具啊！以前的域名dbaroad.com被注册走了，俺苦苦等待两个多月，居然白搭了。

1月2号那天，我还特地看过，不能注册，结果1月4号一看，发现人家1月2号就把域名注册走了，真是不服不行啊。

不过还好，dbaroad基本没人注册，换个.me域名也挺有意思的。

嗯，博客一关，都好久没有写点东西了，要多多更新，多多交流了！

— The End —

写博一年了

OoNiceDream — Mon, 26 Oct 2009 15:23:47 +0800

写博一年了，抓了点数据保存下：

算上这篇，应该有115篇博文了，大部份都是关于Oracle数据库的，当然质量很一般，没有什么很深入的研究，都是一些平时学习的笔记，就当备忘录一样。

博客人气还是比较差的，一般都是自娱自乐，没有起到交流的作用。通过写博，也认识了不少朋友，收获还是挺大的。

刚开始几个月，一般没什么人访问，后来慢慢多了一点，大部份来自google,百度，还有一些来自好友链接。现在工作日一般有五十几个IP：

订阅数人FeedSky里抓的，按这样算，应该在60个左右，看得不是很明白：

接下来，希望在人气方面能有所提高，与大家多交流，多认识一些圈子里的朋友。

— The End —

如何禁止搜索引擎收录

OoNiceDream — Sun, 25 Oct 2009 20:56:34 +0800

过两天这个.com域名就不能用了，空间也快到期了，今天抽空把数据都备份到了dbaroad.cn下。空间是半瓶赠送的，感觉速度还是比较快的。

今后就把dbaroad.cn当作一个备份站点，WP的升级、插件的更新都可以先到这测试一番。因而.cn站点上的内容不需要被搜索引擎收录。

要禁止搜索引引擎收录，可以在网站根目录下添加一个robots.txt文件，内容如下：

User-agent: * 
Disallow: /

什么是robots.txt文件?
搜索引擎使用spider程序自动访问互联网上的网页并获取网页信息。spider在访问一个网站时，会首先会检查该网站的根域下是否有一个叫做robots.txt的纯文本文件，这个文件用于指定spider在您网站上的抓取范围。您可以在您的网站中创建一个robots.txt，在文件中声明该网站中不想被搜索引擎收录的部分或者指定搜索引擎只收录特定的部分。

请注意，仅当您的网站包含不希望被搜索引擎收录的内容时，才需要使用robots.txt文件。如果您希望搜索引擎收录网站上所有内容，请勿建立robots.txt文件。

更多内容可以参考：http://www.baidu.com/search/robots.html

— The End —

VI常用命令及快捷键

OoNiceDream — Wed, 21 Oct 2009 16:40:52 +0800

VI常用命令及快捷键太多了，摘抄几个常用的、自己又容易忘记的，加粗的几个忘了好几次了，特别是替换命令：

Shift+g | G             移至文件最后一行
:1                      移至文件第一行
L                       移到屏幕的最后一行
M                       移到屏幕的中间一行
H                       移到屏幕的第一行
0或|                    移到当前行的第一列
$                       移到当前行的最后一个字符

dG                      删除行，直到文件结束
ndd                     删除当前行及其后n-1行

n                       在同一方向重复上一次搜索命令
N                       在反方向上重复上一次搜索命令
：s/p1/p2/g             将当前行中所有p1均用p2替代
：n1,n2s/p1/p2/g        将第n1至n2行中所有p1均用p2替代
：g/p1/s//p2/g          将文件中所有p1均用p2替换

u                       撤消最后一次修改
U                       撤消当前行的所有修改
.                       重复最后一次修改

:set all                打印所有选项
:set nu                 每行前打印行号
:set showmode           显示是输入模式还是替换模式
:set noic               查找时忽略大小写

其中有几个也是第一次用到，挺实用的，以后有好的再更新。

— The End —