老熊的三分地-Oracle及数据恢复

这篇文章看起来有点标题党的感觉。

昨天一位网友管理的数据库（版本9iR2，平台Windows），由于存储阵列问题，挂了，再也起不来了。

数据库本来有RMAN做的备份，但不幸的是，备份数据与数据库放在同一台服务器，同一个硬盘上，备份文件不幸地变成了0字节。

数据库在打开时，报ORA-1578错误，错误块为系统表空间文件号1的第417块。这可是系统在自举（bootstrap）时非常重要的一个数据块，具体可以参见eygle的文章《Oracle中独一无二的Cache对象》

使用dbv检查数据文件，发现很多很多的坏块。

我让网友对现有的数据库中的所有文件（数据文件，在线日志文件等）做一个冷备份。然后使用我开发的ODU，dump 文件1的第417块，”神奇的“事情出现了，dump出来的结果显示，这个块头显示这个块的地址居然是文件号1，块号为425，相差了8个块。继续检查发现，这个块附近的连续8个块，都偏移了8个块（均是向后偏移了），而这8个块之后的8个块，又向前偏移了8个块的位置。说的更清楚的就是，这连续的16个块，前8个块和后8个块，他们在磁盘上交换了位置。

My God，这个系统疯了，是存储阵列的问题？还是操作系统的。看起来阵列的问题其可能性更大。

我花了大约20几分钟的时间，修改了一下ODU程序，对copy datafile命令加上了修正数据块交错的功能。网友用copy datafile将SYSTEM表空间的数据文件复制成一个新的文件后，用dbv检查，仍然还是有很多的坏块，不过已经比之前的少很多了。不过从dbv检查的结果来看，有很多的坏块，显示的是全0字节，也就是说，这个块中的所有数据全为0。这样的块，彻底地坏了。

不过用ODU修正块的交错之后，至少能导出一部分数据字典了，有了一线希望。

网友仍然在尝试恢复中。

这是一个惨痛的教训，系统一定要做备份，备份的数据一定不要放在与系统同一台服务器上，也一定不要放在同一个硬盘或阵列上，阵列也是不可靠的。

最近有两次Oracle数据库故障与防火墙有关。这里的防火墙是硬件网络防火墙，而不是软件防火墙。

先说说简单的。一个运行在Windows系统上的Oracle 9i，客户端不能连接数据库，但是用tnsping测试没有问题。解决问题的办法很简单，但是我们仍然需要了解一下引起这个问题的原因。

这个问题首先得从客户通通过监听连接数据库的整个过程说起，此处指专用服务器连接模式：

• 服务器上的监听进程在1521端口上进行侦听
• 客户端发起一个数据库连接请求
• 监听进程fork一个Oracle服务器进程（Server Process），也可称之为影子进程 (Shadow Process）。服务器进程选择一个大于1024的端口号进行侦听，监听进程把这个端口号发回到客户端，要求客户端重新连接这个指定的端口。
• 客户端重新连接监听指定的新端口，也就是重新进行连接。
• 客户端与Server Process直接对话，不再通过监听，进行会话认证（登录），执行SQL等等。

从上述过程可以看到，客户端最终连接的端口实际上并不是1521。由于防火墙一般只开放了几个端口，对Oracle数据库只开放了1521端口，这样在客户端进行第二次连接时，不能通过防火墙，导致连接数据库失败。

值得庆幸的是，只有Windows平台上的9i及以下版本的Oracle才会有这个问题。Oracle在Linux以及Unix平台下，多个进程间可以对端口进行复用，Oracle Server Process仍然使用的是跟监听进程一个端口（1521）。通过在linux使用strace跟踪客户端连接数据库的过程可以发现，客户端只连接了一次，并没有进行第二次连接，与上面描述的流程相比已经发生了变化。在Windows平台上，10g及以上版本的库，也同样利用端口复用，避免了这样的问题。

那么Windows上运行的Oracle 9i怎么解决这个问题呢？答案很简单，在Windows注册表的\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEn（这里n指Oracle Home的序号，只有一个Oracle Home时是0）键下面增加一项USE_SHARED_SOCKET，其值为TRUE。然后重启监听及Oracle服务（注意要重启Oracle的服务，而不仅仅是重启数据库），就可以解决此问题。实际上10g就是默认USE_SHARED_SOCKET为TRUE。

对于这种问题，或者是让防火墙打开针对数据库主机的所有端口访问，也能解决。但是这种方案往往会被负责安全的人否决。

下面这个由防火墙导致的问题，就相对复杂一点了。

Read the rest of this entry

大家都知道Oracle 10g的dbms_stats包与Oracle 9i相比，功能增强了很多，比如增加了display_cursor这个过程，能够查看V$SQL_PLAN视图中的执行计划，如果在statistics_level参数设置为ALL，或者执行的sql使用了gather_plan_statistics hint，则在sql执行后，会在v$sql_plan_statistics_all视图中查到SQL的执行统计信息，例如逻辑读，物理读等等。这些数据对于性能诊断有着非常大的帮助。同时v$sql_plan中的执行计划，与通过EXPLAIN PLAN得到的执行计划相比，前者是oracle执行sql时真正使用的执行计划，而后者则可能不是真正的执行计划；同时有的时候，执行过的sql使用了绑定变量，而oracle在解析sql时通常会进行绑定变量窥探，这个时候我们不能使用EXPLAIN PLAN来得到那个sql的执行计划，就算得到的跟那个sql的真实的执行计划是不一样的，所以有时我们更愿意直接从v$sql_plan中得到执行计划。

但是在oracle 9i中的dbms_xplan包没有display_cursor这个过程。不过，本文根据一个开源软件SQLT中得到的一段脚本，经过修改后，能够显示v$sql_plan和v$sql_plan_statistics中的执行计划和sql的执行统计数据。点击此处下载display_cursor_9i代码

下面是使用这个代码的示例：

SQL> select /*+ sqla */ count(*) from t1 where a<13;

  COUNT(*)
----------
     40000

在另一个会话中，得到这个SQL的hash_value , child_number以及在v$sql_plan中的执行计划。

SQL> select hash_value,child_number from v$sql where sql_text like '%sqla%' and sql_text not like '%v$sql%';

HASH_VALUE CHILD_NUMBER
---------- ------------
1742773495            0

SQL> @display_cursor_9i 1742773495 0
原值  268:   s_hash_value := &1;
新值  268:   s_hash_value := 1742773495;
原值  269:   s_child_num := &2;
新值  269:   s_child_num := 0;

HASH_VALUE: 1742773495   CHILD_NUMBER: 0
---------------------------------------------------------------------------------------------
select /*+ sqla */ count(*) from t1 where a<13

Plan hash value: 3724264953

------------------------------------------------------------
| Id   | Operation           | Name |  Rows | Bytes | Cost |
------------------------------------------------------------
|    0 | SELECT STATEMENT    |      |       |       |   25 |
|    1 |  SORT AGGREGATE     |      |     1 |     3 |      |
| *  2 |   TABLE ACCESS FULL | T1   | 44444 |  133K |   25 |
------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter("A"<13)

PL/SQL 过程已成功完成。

如果我们将statistics_level设置为ALL（注意：在oracle 9i中gather_plan_statistics这个hint无效），重新执行这个SQL：

SQL> alter session set statistics_level=all;

会话已更改。

SQL> select /*+ sqla */ count(*) from t1 where a<13;

  COUNT(*)
----------
     40000

在会话2中重新进行之前的查询，只不过由于参数的参数，这个SQL有两个子游标，这次执行的游标其child_number为1：

SQL> select hash_value,child_number from v$sql where sql_text like '%sqla%' and sql_text not like '%v$sql%';

HASH_VALUE CHILD_NUMBER
---------- ------------
1742773495            0
1742773495            1

SQL> @display_cursor_9i 1742773495 1
原值  268:   s_hash_value := &1;
新值  268:   s_hash_value := 1742773495;
原值  269:   s_child_num := &2;
新值  269:   s_child_num := 1;

HASH_VALUE: 1742773495   CHILD_NUMBER: 1
-------------------------------------------------------------------------------------------------------------------
select /*+ sqla */ count(*) from t1 where a<13

Plan hash value: 3724264953

----------------------------------------------------------------------------------------------------------------
| Id   | Operation          | Name | Starts | E-Rows | A-Rows | A-Time      | Buffers | OMem | 1Mem | Used-Mem |
----------------------------------------------------------------------------------------------------------------
|    1 | SORT AGGREGATE     |      |      0 |      1 |      0 | 00:00:00.00 |       0 |    0 |    0 |    0 (0) |
| *  2 |  TABLE ACCESS FULL | T1   |      0 |  44444 |      0 | 00:00:00.00 |       0 |    0 |    0 |    0 (0) |
----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("A"<13)

PL/SQL 过程已成功完成。

不幸的是，在另一个会话中查询v$sql_plan_statistics_all的一些结果并不正确。只有在那个执行SQL的会话（就是例子中的会话1）中，才能得到正确的结果：

----------------------------------------------------------------------------------------------------------------
| Id   | Operation          | Name | Starts | E-Rows | A-Rows | A-Time      | Buffers | OMem | 1Mem | Used-Mem |
----------------------------------------------------------------------------------------------------------------
|    1 | SORT AGGREGATE     |      |      1 |      1 |      1 | 00:00:00.39 |     155 |    0 |    0 |    0 (0) |
| *  2 |  TABLE ACCESS FULL | T1   |      1 |  44444 |  40000 | 00:00:00.21 |     155 |    0 |    0 |    0 (0) |
----------------------------------------------------------------------------------------------------------------

如果v$sql_plan_statistics_all有数据，则这个脚本会生成上面的第2个示例的结果，否则，会得到示例1的结果。从输出的结果来看，朋友们，是不是与dbms_xplan的输出惊人地相似啊！

在这里只是测试了最简单的SQL，实际上这个脚本对于并行，CPU成本，TEMP临时表空间使用等数据都能够显示。有兴趣的朋友可以自己试试。

前两篇文章（TAF PartI和TAF PartII）主要描述了在TAF发生故障转移时正在执行SELECT时的行为。本文将观察当故障转移发生时如果正在执行DML和DDL语句的行为。

本文将继续使用上一篇文章TAF PartII同样的测试环境。

我们先测试当会话update时，在另一个会话立即start force实例：

SQL> update t1 set object_name=lpad('x',40,'x'),created=sysdate;
update t1 set object_name=lpad('x',40,'x'),created=sysdate
*
ERROR 位于第 1 行:
ORA-25408: 无法安全重放调用

SQL> select * from dual;

D
-
X

SQL> select failed_over from v$session where sid=(select sid from v$mystat where rownum=1);

FAI
---
YES

可以看到，在数据库实例重启完成后，会话报“ORA-25408: 无法安全重放调用”错误。为什么会报这个错。我的猜测是，由于在FAILOVER后，会话实际上是重新来执行这个SQL，但是DML语句不像SELECT一样，前者是对当前时间点的数据进行修改，保证数据修改是最新的；而SELECT的机制是保证查询的时间点一致，DML语句在重新执行时，当前时间点的数据已经跟上次执行时的数据可能不相同了，不能保证是相同的，也就是“不安全”的。

从上面的输出可以看到，在会话报错之后，仍然可以执行查询，并且从结果来看表明会话是failover后的新会话。注意，ORA-25408这个错误是在failover之后才报的，并不是数据库实例DOWN下后马上就报错。

如果我们在数据库实例级别开启sql trace，在failover后我们可以从trace文件里面可以发现，UPDATE语句并没有再次被解析和执行，而不是在UPDATE重新执行然后报错。

下面我们来看看DDL语句的情况：

Read the rest of this entry