阻止Oracle数据库中的损坏

拼搏现实的明天。 2023-10-08 08:29 39阅读 0赞

介绍

当我们处理任何存储数据的软件时，块损坏是一个常见的话题。在Oracle数据库中，有几种类型的逻辑结构映射到名为“数据文件”的物理文件，该文件分为多个文件系统块。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsbHdheTI_size_16_color_FFFFFF_t_70][]

块可以具有逻辑或物理损坏。损坏的块是已更改的块，因此与Oracle期望找到的块不同。逻辑损坏是具有有效校验和但其内容已损坏的块。例如，由不存在的事务锁定的行，使用的空间量不等于块大小，avsp错误等。逻辑损坏会导致ORA-600，具体取决于块内的内容是否损坏。物理损坏也称为媒体损坏；数据库根本无法识别障碍，这种问题与内容无关，而与物理位置或结构本身有关；例如，错误的标题，损坏的/不完整的块，块校验和无效，块放错位置，块被清零，块的页眉和页脚不匹配，检测，监视和修复损坏的块是我们定期且经常处理的重要任务。损坏的块不仅意味着该块有问题，而且还意味着可能会丢失数据，这对业务非常重要。

**问题**

损坏的块的问题在于，在尝试使用它们之前，我们不知道它们已损坏。当然，这适用于我们不执行主动活动来检测损坏的块的情况。例如，一个表块可能已损坏，除非有人执行SELECT或读取该块的任何其他DML，否则无法知道它。读取该块后，Oracle将知道该块已损坏，然后将ORA-0600，ORA-27047或ORA-01578返回给用户。

很久以前，有一位客户打电话给我，说他们试图从应用程序中执行SELECT，并且每当执行SELECT时，应用程序就会得到ORA-01578。我检测到块＃和数据文件＃并对其进行修复。那时，用户可以在一天的其余时间继续工作。但是，第二天，同一位客户打电话给我，说他们收到了更多的ORA-01578。这次，我确认损坏的块与前一天修复的块位于不同的数据文件中。这使我认为可能会有更多损坏的块。我对整个数据库执行了dbverify，发现数据库有几个损坏的块。但是，上次rman备份未报告任何损坏的块。我们聘请了一名系统管理员，他当天检测到存储设备出现问题。幸运的是，我们迅速发现了存储问题，并且没有数据丢失。但是，如果无法正确检测到此类问题，则可能会破坏数据。在此示例中，我们一直在谈论物理问题，但是在其他一些情况下，发现问题更加困难，尤其是在逻辑损坏的情况下。

**如何避免**

**使用****Oracle ASM****：** Oracle建议使用ASM作为数据库的存储。ASM具有三种类型的冗余：外部，常规和高级。如果我们使用“普通”或“高级”，则Oracle会为每个块保留一个副本（“普通”）或两个副本（“高”）。该块称为“镜像块”，每当找到损坏的块时，它将自动从其镜像副本之一中还原损坏的块。我写了一篇文章，其中详细解释了Oracle如何从其镜像副本恢复块，以防万一，您需要阅读以下内容：[使用Normal Redundancy的数据块恢复过程][Normal Redundancy]

**使用参数****db\_block\_checking**：此参数用于控制是否对事务管理的块进行块检查。由于尽早发现损坏是有用的，并且对性能的影响很小。但是，在某些类型的应用程序中，参数DB\_BLOCK\_CHECKING = TRUE会产生可观的开销，所有开销都取决于应用程序，建议在测试环境中测试更改。立即开销是每次更改后检查块内容的CPU开销，但是第二个效果是，这意味着将块保留更长的时间，因此需要当前块映像的其他会话可能不得不等待更长的时间。任何系统上的实际开销在很大程度上取决于应用程序配置文件和数据布局。

**使用参数****db\_block\_checksum****：**确定DBWn和直接加载程序是否将校验和（从存储在块中的所有字节计算得出的数字）并将其写入磁盘时存储在每个数据块的高速缓存头中。读取块时，将校验和–仅在该参数为TYPICAL或FULL并且块的最后写入存储了校验和的情况下，才对校验和进行校验。在FULL模式下，Oracle还会在更改之前（例如更新/删除语句）验证校验和，并在应用更改后重新计算校验和。此外，Oracle在将每个日志块写入当前日志之前为其提供一个校验和。校验和使Oracle可以检测由基础磁盘，存储系统或I / O系统引起的损坏。如果设置为FULL，DB\_BLOCK\_CHECKSUM还将捕获内存中的损坏并阻止其损坏到磁盘。在“典型”模式下打开此功能只会导致额外的1％到2％的开销。在全模式下，它将导致4％到5％的开销。

**Dbfsize****：**可用于检查块0的一致性。

**Dbverify****：**可用于检查Oracle数据文件是否存在损坏迹象，并在一定程度上确定数据文件没有损坏。它以只读模式打开文件，因此无法更改所检查文件的内容。它检查数据文件是否具有有效的头。文件中的每个数据块都有一个特殊的“包装器”，用于标识该块–检查该“包装器”的正确性。Dbverify还检查DATA（TABLE）和INDEX块在内部是否一致。并且，从8.1.6开始，它将检查各种其他块类型在内部是否一致（例如回滚段块）。

**RMAN VALIDATE****命令**：可以使用VALIDATE命令来手动检查数据库文件中的物理和逻辑损坏。此命令执行与BACKUP VALIDATE相同的检查类型。默认情况下，RMAN不检查逻辑损坏。但是，如果在BACKUP命令上指定CHECK LOGICAL，则RMAN会测试数据和索引块是否存在逻辑损坏，例如行段或索引条目的损坏。

RMAN> validate check logical database;

RMAN > validate database;

RMAN > validate backupset 11;

RMAN > validate datafile 2 block 11;

我还写了其他一些与RMAN和损坏的块有关的文章，以防您想了解更多有关该问题的信息。

*  [块损坏：具有高或正常磁盘组的RMAN][RMAN]
 *  [使用前验证备份][Link 1]

**结论**

执行主动任务以检测或避免物理和逻辑损坏，如果及时发现损坏，则可以轻松地执行解决方案。Oracle提供了几种工具，可用于检测，监视和修复块中的损坏。注意这些类型的问题很重要，这样我们的数据就不会受到损害。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsbHdheTI_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20191019174132898.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FsbHdheTI=,size_16,color_FFFFFF,t_70
[Normal Redundancy]: https://blog.toadworld.com/data-block-recovering-process-using-normal-redundancy
[RMAN]: https://blog.toadworld.com/block-corruption-rman-with-high-or-normal-diskgroup
[Link 1]: https://blog.toadworld.com/validating-the-backup-before-using