数据工人

挥手一般就是要说再见啦，但这里的挥手显然是不要再见的意思。

国庆后，oliver多次在QQ上跟我说，你最近真的很忙么，怎么不见你更新blog。HI,现在终于更新了，那是因为，终于可以借着元旦前夕，又可以胡乱说一通了。

2009年，

对于个人来说，基本上没有任何闪光点。找到了自己的一个缺点—-轻易相信他人，但没找到克服的方法。

对于家庭来说，也没有。女儿的成长主要靠母亲和老婆。

对于公司来说，只是协助其他部门完成公司年初的quota。其他方面略有进步。

所以，2009，过去吧，几乎没有值得留念的。

明年怎么样呢？谁知道!

没有人知道，做几点期望，到明年底来回顾一下吧：

1.看10本非计算机方面的英语书籍（这个应该很容易）

2.非节假日带女儿到国内旅游（最好是桂林）一次（应该不是太难，还得听取老婆的意见）

3.读点股市方面的书，解除“maiden”的状态

4.回老家一次

5.再学点我今天仍然不会的东西

over，在元旦前想到再补充。

这是个挺极端的话题，因为标题中问题的前提是：没有任何备份。

不要抱怨，“命苦不能怪政府，点背不能怨社会” ^_^

而我一个同事，就真正碰上这样的问题。当然，最后也成功恢复了。

有人会想到logminer和archive log，但是sp被删除时archive log并不记录sp的文本内容。当然logminer有用处，起码能定位到准确的删除时间。

存储过程的文本内容通常被记录在source$中。

SQL> conn blue/blue

Connected.

SQL> create or replace procedure sp_test2

2     is

3     begin

4       dbms_output.put_line(‘procedure restore’);

5     end;

6     /

Procedure created.

SQL> conn / as sysdba

Connected.

SQL> select s.obj#,s.source from source$ s,obj$ o

2  where s.obj#=o.obj#

3  and o.name=’SP_TEST’;

OBJ# SOURCE

———- ————————————————–

53258 procedure sp_test

53258    is

53258    begin

53258      dbms_output.put_line(‘procedure restore’);

53258    end;

不过可惜的是，当sp或整个schema被drop后，source$中对应的内容也一并被删除。

21:56:42 SQL> drop procedure blue.sp_test;

Procedure dropped.

21:56:54 SQL> select s.obj#,s.source from source$ s,obj$ o

21:57:20   2  where s.obj#=o.obj#

21:57:20   3  and o.name=’SP_TEST’;

no rows selected

我们想要得到的，是过去某个时间点里source$中的内容。

然而，sys schema下不支持flashback table，Oracle不允许你这么干，如果部分数据字典表被回退到过去的时间点，这全乱套了。

有人用flashback database，没错，这确实可以实现，只是，这也太小题大作了吧？辛辛苦苦几十年，一下回到解放前。

so，why not flashback query？

21:59:53 SQL> select obj#,name from obj$ as of timestamp  sysdate-5/1440

21:59:55   2  where name =’SP_TEST’;

OBJ# NAME

———- ——————————

53258 SP_TEST

22:00:22 SQL> select obj#,source from source$ as of timestamp sysdate-6/1440

22:00:24   2  where obj#=53258;

OBJ# SOURCE

———- ————————————————–

53258 procedure sp_test

53258    is

53258    begin

53258      dbms_output.put_line(‘procedure restore’);

53258    end;

回到最开始的话题，2点警示：

1、制订完善的备份策略并实施

2、规划日常操作

隐式转换是DBA们所不愿意看到的，有人说“I believe implicit conversion to be bad. Badder. Evil. A serious no-no!”

举个例子：

有一条SQL

select * from t_table where id=:1;

说明：t_table记录量在数万条，id varchar2类型，主键。

1.用户用pl/sql等工具执行非常快。

2.在应用中执行该语句非常慢，通过statspack,awr等发现，并且发现是全表扫描。

这种情况很有可能是绑定变量类型不匹配而导致的。

某些情况下，隐式转换会让数据库性能变得很糟糕。有同事处理过这样的案例，在消灭隐式转换后，原本一个需要2小时的业务操作可以在6秒内便可完成。
Oracle也强烈建议使用explicit conversion而不是implicit conversion，explicit conversion相比implicit conversion有如下的好处：

SQL statements are easier to understand when you use explicit datatype conversion functions.

Implicit datatype conversion can have a negative impact on performance, especially if the datatype of a column value is converted to that of a constant rather than the other way around.

Implicit conversion depends on the context in which it occurs and may not work the same way in every case. For example, implicit conversion from a datetime value to a VARCHAR2 value may return an unexpected year depending on the value of the NLS_DATE_FORMAT parameter.

Algorithms for implicit conversion are subject to change across software releases and among Oracle products. Behavior of explicit conversions is more predictable.

在发生隐式转换SQL的诊断过程中，我们使用一些第三方的工具看到的执行计划往往没有异常。因为在使用这些工具的时候，解释的是用户手工输入的而不是应用程序产生的SQL.

那么，如何确定应用程序的SQL是不是发生了隐式转换呢？

在Oracle 10g提供过滤谓词的信息当中，包含了是否发生转换。

查看过滤谓词的方式较多，比如autotrace  、explain plan、utlxpls、dbms_xplan等。

前面3种方法需要手工输入SQL文本，所以看到的同样不是我们需要的结果。而10g中dbms_xplan可以通过指定SQLID来查看用户关心的特定SQL。

SQL> select /*+ hint1 */hiredate from scott.emp where    hiredate between ’17-DE

C-80′ and ’20-FEB-81′ ;

HIREDATE

———

17-DEC-80

20-FEB-81

SQL> col sql_id for a20

SQL> select sql_id,sql_text from v$sql where sql_text like ‘%hint1%’;

SQL_ID

——————–

SQL_TEXT

——————————————————————————–

2k4kk1zvp8jz1

select /*+ hint1 */hiredate from scott.emp where    hiredate between ’17-DEC-80′

and ’20-FEB-81′

28n8kr51sv6s6

select sql_id,sql_text from v$sql where sql_text like ‘%hint1%’

SQL> select * from table(dbms_xplan.display_cursor(‘&SQLID’));

Enter value for sqlid: 2k4kk1zvp8jz1

old   1: select * from table(dbms_xplan.display_cursor(‘&SQLID’))

new   1: select * from table(dbms_xplan.display_cursor(’2k4kk1zvp8jz1′))

PLAN_TABLE_OUTPUT

——————————————————————————-

SQL_ID  2k4kk1zvp8jz1, child number 0

————————————-

select /*+ hint1 */hiredate from scott.emp where    hiredate between

’17-DEC-80′ and ’20-FEB-81′

Plan hash value: 3896240783

—————————————————————————

| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |

—————————————————————————

|   0 | SELECT STATEMENT   |      |       |       |     3 (100)|          |

PLAN_TABLE_OUTPUT

——————————————————————————-

|*  1 |  FILTER            |      |       |       |            |          |

|*  2 |   TABLE ACCESS FULL| EMP  |     1 |     8 |     3   (0)| 00:00:01 |

—————————————————————————

Predicate Information (identified by operation id):

—————————————————

1 – filter(TO_DATE(’17-DEC-80′)<=TO_DATE(’20-FEB-81′))

2 – filter((“HIREDATE”<=’20-FEB-81′ AND “HIREDATE”>=’17-DEC-80′))

21 rows selected.

SQL>

然而9i的过滤谓词没这么详细的信息，v$sql 视图中不包含SQLID信息，dbms_xplan中也不提供display_cursor这样的function。就是说，9i不能用以上的方法来辅助判断。

那Oracle 9i下怎么办呢？

试试10046吧，部分级别的10046 trace内容中包含了绑定变量及其变量类型dty信息。

Trace文件可能会包含类似内容：

bind 3: dty=180 mxl=11(11) mal=00 scl=00 pre=00 oacflg=01 oacfl2=0 size=0 offset=72

bfp=ffffffff7f5500f0 bln=11 avl=11 flg=01

value=

Dump of memory from 0xFFFFFFFF7F5500F0 to 0xFFFFFFFF7F5500FB

FFFFFFFF7F5500F0 78640101 0A353619 08B10000           [xd...56.....]

bind 4: dty=180 mxl=11(11) mal=00 scl=00 pre=00 oacflg=01 oacfl2=0 size=0 offset=88

bfp=ffffffff7f550100 bln=11 avl=11 flg=01

value=

下表为Oracle内部的数据类型代码