1911g新特性弹性.docx

1、1911g新特性弹性Oracle 数据库 11g： 面向 DBA 和开发人员的重要新特性弹性特性了解运行情况监视如何自动监视某些数据库组件的运行情况然后将其发现记录到自动诊断信息库中，如何创建在出现问题时发送到 Oracle Support 的程序包，以及如何读取警报日志、监听器日志以及其他日志的新版本。下载 Oracle 数据库 11g 自动运行情况监视您如何知道您的数据库是否正在顺畅地运转？一种方法是进行“全面”检查，这个过程既耗时又容易出错。在某些机构是由专门的 DBA 反复执行相同的任务来评估和报告数据库的运行情况，但是大多数机构没有能力雇佣全职员工专门从事此项工作。另一种方法是由 D

2、BA 员工定期执行运行情况检查，但结果往往不尽如人意。一个人的注意力分散到太多的事情上会导致遗漏某些可能危险的东西。在 Oracle 数据库 11g 中，由于引入了自动运行情况监视而使这项工作变得简单一些。与 Oracle 数据库 10g 中引入的某些顾问工具类似，自动运行情况监视“检查器”（在故障后自动或根据需要）监视各种组件（如数据文件和字典）以确保它们在物理或逻辑上没有受到损 坏。当检查器发现情况时，会向各种恢复顾问工具报告和提供信息。至少新的事件打包服务（稍后介绍）允许您将所有问题和支持文件打包到一起以便向 Oracle Support 报告。与 Oracle 数据库 11g 的许多其

3、他特性一样，可以通过命令行或 Oracle 企业管理器 GUI 管理此过程。下面将向您介绍如何使用后者管理该过程。在主 Database 页面上，向下一直滚动到 Related Links 部分，如下所示。在该超链接列表中，单击 Advisor Central。显示 Advisors 和 Checkers 屏幕。单击 Checkers 选项卡。屏幕的顶部显示如下。 这是一个非常重要的屏幕，它显示多个可用的检查器以及已经执行的自动检查器运行。 首先，我们关注多个可用的检查器。DB Structure Integrity Check。 该检查器可以通过一个示例得到很好的解释。首先，单击 DB St

4、ructure Integrity Check。出现一个小屏幕，例如，您可以在该屏幕中将此运行命名为“DB_Struct_Int1”。您在此处所做的另一个输入是为了限制该运行的时间，您可以忽略它们以表明实际没有限制。运行情况检查成功运行后，屏幕顶部将出现确认信息，如下所示：屏幕底部也显示刚刚运行的检查。名称是您在前面输入的：DB_Struct_Int1。重要的区别是 Run Type 列，它针对此运行显示“Manual”，而针对其他运行则显示“Reactive”。可通过选中左侧的单选按钮然后单击 Details 按钮来选择该运行。结果屏幕显示该运行的详细信息，如检测到的损坏类型等等。 在本例中

5、，数据文件由于某种原因受到损坏，该检查器将对此进行识别。该信息随后提供给 Data Recovery Advisor（在有关 RMAN 的部分中讨论）以采取相应的措施。您可以随时调用该检查器以检查数据文件的完整性。这个检查器很可能是您最喜欢的。在显示以往运行的屏幕上，选择该类型的任一运行并单击 Details 按钮，您将看到如下所示的屏幕：该屏幕显示关于此问题的所有发现：7 号数据文件已损坏。如果您想获得有关接下来所需采取的措施的建议，可以启动 Recovery Advisor。 Data Block Integrity Check。 Data Block Integrity Check 与

6、DB Structure Integrity Check 类似，但它只检查特定的块而不是整个文件。和前面一样，您为它指定名称和其他相关的详细信息。此屏幕如下所示：注意，您需要输入数据文件编号和块编号。（我分别输入了 7 和 20。）输入详细信息后，按 OK。这将启动检查过程，屏幕底部将反映该运行的状态，如下所示： 同样，如果该块存在问题，检查器应该会发现。使用超链接，您可以导航到详细信息页面以了解问题的相关信息。 Redo Integrity Check。 该检查器扫描重做日志和存档日志的内容是否可以访问以及是否受到损坏。Undo Segment Integrity Check。 该检查发现逻

7、辑撤消损坏，在回滚操作期间有时会发现该损坏。找到撤消损坏的位置后，该检查使用 PMON 和 SMON 尝试恢复损坏的事务。如果该恢复失败，则自动运行情况监视将有关损坏的信息存储在 V$CORRUPT_XID_LIST 中。大多数撤消损坏可以通过强制提交进行恢复。Transaction Integrity Check。 Transaction Integrity Check 与 Undo Segment Check 基本相同，只是它仅检查作为输入参数传递给该检查的特定事务。找到撤消损坏的位置后，该检查使用 PMON 和 SMON 尝试恢复损坏的事务。如果该恢复失败，则自动运行情况监视将有关损坏的

8、信息存储在 V$CORRUPT_XID_LIST 中。大多数撤消损坏可以通过强制提交进行恢复。Dictionary Integrity Check。 该检查将检查核心字典对象（如 tab$ 和 col$）的完整性。它验证每个字典对象的字典条目内容是否符合以下条件：字典中行的逻辑约束为强制，并且字典对象间的父子关系为强制。自动运行情况检查还记得检查器主屏幕？ 注意页面底部的 Checker Runs 列表，它显示已经发生的各种检查器运行及其 Run Type。如果您手动运行了一个检查器（如在本部分前面所做的那样），Run Type 将显示“Manual”。作为“Reactive”列出的检查器运行

9、表明它们是在某处检测到错误时自动运行的。如果运行发现情况，将进行记录，您可以单击 这些超链接来访问相关发现。例如，单击第一个运行 HM_RUN_140013 将显示该检查器运行的详细信息： 该屏幕清楚地显示了故障原因。实际上，至少有两种类型的故障：损坏的联机重做日志文件和数据文件。您首先需要单击 Launch Recovery Advisor 按钮寻求建议。显示一个基于向导的界面后，您将看到一个屏幕，其中的顾问工具指导您执行一个特定操作： 该操作应为运行 /home/oracle/diag/rdbms/odel11/ODEL11/hm 目录中的 SQL 文件 reco_767216331.hm

10、。如果您打开该文件，将看到以下内容： begin/*Clear the Log Group*/execute immediate ALTER DATABASE CLEAR LOGFILE GROUP 3;end;损坏的日志文件属于一个未激活的组，因此最好将其清除 这是来自 Recovery Advisor 的建议。如果您决定采纳该建议，按 Continue 按钮，恢复将继续。完成后，如果您返回 Support Workbench，您将看到重做损坏已经不见，但是在存档日志中已检测到一个新的损坏。 与往常一样，您可以启动建议工具来修复这些错误。 自动诊断信息库当检查器发现情况时，它们需要将它记录到

11、某个地方以便进一步的分析和后续的处理。所有相关元数据都记录在一个称为自动诊断信息库的新工具中，该工具记录所 有重要事件而不只是检查器检测到的事件。它类似于数据库中重要事件的 SYSTEM 表空间。下面我们来看看如何通过企业管理器使用它。 在 Enterprise Manager 主 Database 页面 中，单击 Software and Support 选项卡，然后单击 Support Workbench，将显示一个类似如下所示的屏幕。该屏幕只显示了检查器报告的情况汇总：出现了 ORA-603 错误。单击错误左侧的 + 号将显示这些错误的详细信息。 如果单击 Incidents 标题下每个

12、事件 id 对应的链接，您可以查看这些事件。例如，单击事件 14435 对应的链接将在如下所示的屏幕中显示该事件的详细信息： 屏幕顶部显示的详细信息可能具有自我说明性。屏幕底部显示该事件的支持详情（如跟踪文件）。这些文件将发往 Oracle Support 进行分析（但仅当您使用事件打包服务将它们打包到一起并且 Oracle 配置管理器配置了合适的证书时）。单击第一个跟踪文件旁边的眼镜图标将显示该跟踪文件，如下所示： 注意文件中的行如何以十分用户友好的方式进行分析和显示的。企业管理器读取每行，识别每行，然后以适当的缩进显示它们。如果单击文件中的超链接，您将看到跟踪文件中的原始部分。 您可以将事

13、件组成一个“信封”发往 Oracle Support，这也是您下一步应该做的：将它们打包到一起。为此，在 Select 下的复选框中单击并单击 Package 按钮。这将显示一个类似如下所示的屏幕：此时，忽略 Custom Packaging。单击 Quick Packaging 并按 Continue，将显示一个如下所示的屏幕： 输入所有详细信息并按 Next。 后续的屏幕确认正在打包的事件、程序包清单等等。这里，您会看到所有与该错误相关的跟踪文件都已发现并添加到程序包中。该过程使您从识别特定错误的正确跟 踪文件集这一容易出错的任务中解放出来，同时该工具还具有将相关错误的跟踪文件收集到同一程

14、序包中的智能。这很重要，因为 Oracle 需要利用所有相关错误的跟踪文件来确定问题的根本原因；您决定打包的错误可能是一个症状而非根本原因。最后，您可以按 Submit 将其发送到 Oracle。一旦提交，屏幕便会发生变化，如下所示： 注意 Packaged 列下现在是如何出现了一个条目（“Yes”）。这确认事件已打包。再注意一个部分： 这表明上载文件已生成并附带相应的详细信息，如生成时间、程序包中的主要问题等。但是，文件并未上载到 Oracle Support，因为您尚未安装配置管理器或尚未对其进行配置。您将在以后了解该特性；现在，如果您单击该名称，您将看到有关该程序包的更多详细信息： 详细

15、信息都具有自我说明性。事件都以超链接的形式显示，单击它们将转至您在前面看到的事件页面。单击 Files 选项卡将打开一个页面，显示程序包中包含的所有文件。单击最右侧的小眼镜图标可以查看文件。 现在，单击 Activity Log 选项卡将显示程序包的历史记录，如创建时间、发送到 Oracle 的时间（如果发送）等。 定制程序包该工具最有用的特性之一是能够定制发往 Oracle 的程序包内容。要实现该任务，单击 Customize 按钮。单击该按钮将显示如下所示的屏幕： 注意右侧的 Packaging Tasks 面板。在该面板中，您将看到用于执行与该程序包相关的各种任务的超链接。下面是一些主要

16、的任务： Edit Contents a. Add Problems：允许您向同一程序包中添加更多问题。当您认为这些问题相关时，该链接有用。b. Exclude Problems：允许您删除问题；当您认为这些问题与程序包中的其他问题不相关时，该链接有帮助。c. View Package Manifest：清单是一个描述程序包内容（描述的内容、涉及的问题、包含的各种跟踪文档等）的文档。这是一个文本文件。单击该链接将显示清单。 Scrub User Data d. Copy out Files to Edit Contents：通过该链接，您可以将程序包中包括的跟踪文件和其他文件复制到一个本地 O

17、S 文件夹并对进行编辑（如果需要）。如果文件包含敏感数据，您可能希望执行该任务。e. Copy in Files to Replace Contents：编辑文件后，您可以用编辑的副本替换程序包中的副本。 Additional Diagnostic Data f. Gather Additional Dumps：允许您添加几个其他尚未包含的转储（如设置 sql_trace = true 后生成的跟踪文件）和测试案例。g. Add External Files：您可以向该程序包添加 Oracel Support（或其他相关部门）要求的任何其他文件（如 init.ora 或 listener.or

18、a）。 Send to Oracle Support h. Finish Contents Preparation：顾名思义，您可以确认内容正常并可以发往 Oracle Support。i. Generate Upload File：允许您再次生成上载文件，并附带您在文件列表中添加和删除的内容。j. View/Send Upload Files：允许您将文件上载到 Oracel Support（如果您已经配置了配置管理器）。配置管理器如果可以通过您的 CSI 和 MetaLink 用户 ID 等相关详细信息创建程序包并发往 Oracle Support 以及创建草拟的服务请求 (TAR) 该多

19、好啊？使用一个名为 Oracle 配置管理器的工具可以实现此目的。 在 Oracle 数据库 11g 安装期间，系统询问您是否希望安装和配置该工具。如果您回答了“yes”，则已经安装并配置了该工具；如果您回答了“no”，您可以现在配置它。转至 Oracle 主目录并使用 cd 命令进入 ccr/bin。然后，运行 setupCCR 文件对配置管理器进行首次设置。它显示一个许可消息，最后系统将询问您是接受还是拒绝该许可。随后，系统将询问您一些问题，如 CSI 编号、MetaLink 用户 ID 等。以下文本显示了交互式会话。用户输入以粗体显示。* Do you accept this licen

20、se agreement? (Y/N) Y: YConfiguration requires the following piece(s) of information. Customer Support Identifier (CSI): XXXXXXX Oracle MetaLink User Name: arup The two character country code: US* Installing base package *Deploying core - Version 10.2.6.0.0 * Registering installation with Oracle Con

21、figuration Manager server(s) *Deploying engines - Version 10.2.2.0.3Deploying metricdata - Version 10.2.4.0.2Deploying scripts - Version 10.2.6.0.0 * Getting package updates from ContentServer * * Starting the Oracle Configuration Manager Scheduler *Oracle Configuration Manager - Release: 10.2.6.0.0

22、 - ProductionCopyright (c) 2005, 2007, Oracle. All rights reserved.-Starting Oracle Configuration Manager.Waiting for status from Oracle Configuration Manager.Start Date 16-Oct-2007 09:28:46Last Collection Time -Next Collection Time 17-Oct-2007 09:28:00Collection Frequency Daily at 09:28Collection S

23、tatus scheduled collection runningLog Directory /home/oracle/app/oracle/product/11.1/db_1/ccr/logRegistered At 16-Oct-2007 09:28:17Automatic Update OnCollector Mode Connected Oracle Configuration Manager successfully started. 设置完配置管理器后，您可以使用同一目录中的 configCCR 脚本更改参数。 ADR 主目录既然所有的焦点都集中于数据库的诊断能力，那么 Orac

24、le 数据库是不是应该存储以结构化方式组织的所有跟踪文件、日志文件等等？在 Oracle 数据库 11g 中确实如此。自动诊断信息库 (ADR) 文件位于一个指定为诊断目标（或 ADR 基目录）的常用目录下的目录中。该目录由初始化参数 (diagnostic_dest) 设置。默认情况下，它设置为 $ORACLE_BASE，但是您可以将其显式设置为某些独占目录。（但是不建议这样做。）该目录下有一个 diag 子目录，您将在这个子目录中发现存储诊断文件的子目录。 ADR 存储所有组件（ASM、CRS、监听器等）的日志和跟踪文件，包括数据库本身的日志和跟踪文件。这使您可以方便地在一个位置查找特定的

25、日志。在 ADR 基目录中，可以有多个 ADR 主目录，每个组件和实例一个。例如，如果服务器有两个 Oracle 实例，则有两个 ADR 主目录。下面是数据库实例的 ADR 主目录的目录结构。目录名称说明diag rdbms alertXML 格式的警报日志存储在这里。 cdump核心转储存储在这里，相当于早期版本中的 core_dump_dest。 hm运行情况监视对多个组件运行检查，它在这里存储某些文件。 incident所有事件转储都存储在这里。 每个事件存储在一个不同的目录中，这些目录都存储在这里。 incpkg当您打包事件时（在本文中可以了解打包），某些支持文件存储在这里。 meta

26、data有关问题、事件、程序包等的元数据存储在这里。 trace用户跟踪文件和背景跟踪文件存储在这里，并附带警报日志的文本版本。例如，如果您的数据库名称为 ODEL11 并且实例名称也为 ODEL11（大写），则 ADR 主目录的路径为 /home/oracle/diag/rdbms/odel11/ODEL11。现在，您会在该 ADR 主目录下看到不同的子目录： $ lsalert cdump hm incident incpkg ir lck metadata stage sweep trace要支持这个新结构，忽略以前版本中的 *_dest 参数（background_dump_dest

27、和 user_dump_dest）。（core_dump_dest 未被忽略；实际上，Oracle 建议您将其设置为很大的核心转储。）如果您要 10g 升级到 11g，则根本不应设置它们，应该将它们从初始化参数文件中删除以免以后发生冲突。 其他组件的 ADR 目录结构与此相似。例如，对于 ASM 实例，“diag”下的目录名为 asm 而不是 rdbms。目录结构的其他部分保持不变。asm 的目标名称为 +asm。例如，我的 ASM 的 ADR 主目录如下所示：$ pwd/home/oracle/diag/asm/+asm/+ASM$ lsalert cdump hm incident inc

28、pkg ir lck metadata stage sweep trace对于监听器，diag 下的目录为 tnslsnr，在该目录下是另一个以主机名命名的目录，然后在该主机名目录下是另一个以监听器名称命名的目录。在该监听器名称目录下，您会看到其他目录。 diag tnslsnr alert trace .例如，如果主机名为 oradba3 并且监听器名称为“listener”（默认名称），则该目录为 /home/oracle/diag/tnslsnr/oradba3/listener。在该目录下创建所有其他目录（alert、trace、 metadata 等）。与警报日志一样，监听器日志文件

29、也作为 XML 条目存储在 alert 子目录下。普通的文本监听器日志文件仍然在 trace 目录下创建。新视图 V$DIAG_INFO 显示有关 ADR 主目录的所有详细信息。在我的 RDBMS 主目录中，它显示如下：SQL select * from v$diag_info; INST_ID NAME VALUE- - - 1 Diag Enabled TRUE 1 ADR Base /home/oracle 1 ADR Home /home/oracle/diag/rdbms/odel11/ODEL11 1 Diag Trace /home/oracle/diag/rdbms/odel1

30、1/ODEL11/trace 1 Diag Alert /home/oracle/diag/rdbms/odel11/ODEL11/alert 1 Diag Incident /home/oracle/diag/rdbms/odel11/ODEL11/incident 1 Diag Cdump /home/oracle/diag/rdbms/odel11/ODEL11/cdump 1 Health Monitor /home/oracle/diag/rdbms/odel11/ODEL11/hm 1 Default Trace File /home/oracle/diag/rdbms/odel11/ODEL11/trace/ODEL11_ora_3908.tr