1911g新特性弹性.docx
《1911g新特性弹性.docx》由会员分享，可在线阅读，更多相关《1911g新特性弹性.docx（21页珍藏版）》请在冰豆网上搜索。
1911g新特性弹性
Oracle数据库11g：
面向DBA和开发人员的重要新特性
弹性特性
了解运行情况监视如何自动监视某些数据库组件的运行情况然后将其发现记录到自动诊断信息库中，如何创建在出现问题时发送到OracleSupport的程序包，以及如何读取警报日志、监听器日志以及其他日志的新版本。
下载Oracle数据库11g
自动运行情况监视
您如何知道您的数据库是否正在顺畅地运转？
一种方法是进行“全面”检查，这个过程既耗时又容易出错。
在某些机构是由专门的DBA反复执行相同的任务来评估和报告数据库的运行情况，但是大多数机构没有能力雇佣全职员工专门从事此项工作。
另一种方法是由DBA员工定期执行运行情况检查，但结果往往不尽如人意。
一个人的注意力分散到太多的事情上会导致遗漏某些可能危险的东西。
在Oracle数据库11g中，由于引入了自动运行情况监视而使这项工作变得简单一些。
与Oracle数据库10g中引入的某些顾问工具类似，自动运行情况监视“检查器”（在故障后自动或根据需要）监视各种组件（如数据文件和字典）以确保它们在物理或逻辑上没有受到损坏。
当检查器发现情况时，会向各种恢复顾问工具报告和提供信息。
至少新的事件打包服务（稍后介绍）允许您将所有问题和支持文件打包到一起以便向OracleSupport报告。
与Oracle数据库11g的许多其他特性一样，可以通过命令行或Oracle企业管理器GUI管理此过程。
下面将向您介绍如何使用后者管理该过程。
在主Database页面上，向下一直滚动到RelatedLinks部分，如下所示。
在该超链接列表中，单击AdvisorCentral。
显示Advisors和Checkers屏幕。
单击Checkers选项卡。
屏幕的顶部显示如下。
这是一个非常重要的屏幕，它显示多个可用的检查器以及已经执行的自动检查器运行。
首先，我们关注多个可用的检查器。
DBStructureIntegrityCheck。
该检查器可以通过一个示例得到很好的解释。
首先，单击DBStructureIntegrityCheck。
出现一个小屏幕，例如，您可以在该屏幕中将此运行命名为“DB_Struct_Int1”。
您在此处所做的另一个输入是为了限制该运行的时间，您可以忽略它们以表明实际没有限制。
运行情况检查成功运行后，屏幕顶部将出现确认信息，如下所示：
屏幕底部也显示刚刚运行的检查。
名称是您在前面输入的：
DB_Struct_Int1。
重要的区别是RunType列，它针对此运行显示“Manual”，而针对其他运行则显示“Reactive”。
可通过选中左侧的单选按钮然后单击Details按钮来选择该运行。
结果屏幕显示该运行的详细信息，如检测到的损坏类型等等。
在本例中，数据文件由于某种原因受到损坏，该检查器将对此进行识别。
该信息随后提供给DataRecoveryAdvisor（在有关RMAN的部分中讨论）以采取相应的措施。
您可以随时调用该检查器以检查数据文件的完整性。
这个检查器很可能是您最喜欢的。
在显示以往运行的屏幕上，选择该类型的任一运行并单击Details按钮，您将看到如下所示的屏幕：
该屏幕显示关于此问题的所有发现：
7号数据文件已损坏。
如果您想获得有关接下来所需采取的措施的建议，可以启动RecoveryAdvisor。
DataBlockIntegrityCheck。
DataBlockIntegrityCheck与DBStructureIntegrityCheck类似，但它只检查特定的块而不是整个文件。
和前面一样，您为它指定名称和其他相关的详细信息。
此屏幕如下所示：
注意，您需要输入数据文件编号和块编号。
（我分别输入了7和20。
）输入详细信息后，按OK。
这将启动检查过程，屏幕底部将反映该运行的状态，如下所示：
同样，如果该块存在问题，检查器应该会发现。
使用超链接，您可以导航到详细信息页面以了解问题的相关信息。
RedoIntegrityCheck。
该检查器扫描重做日志和存档日志的内容是否可以访问以及是否受到损坏。
UndoSegmentIntegrityCheck。
该检查发现逻辑撤消损坏，在回滚操作期间有时会发现该损坏。
找到撤消损坏的位置后，该检查使用PMON和SMON尝试恢复损坏的事务。
如果该恢复失败，则自动运行情况监视将有关损坏的信息存储在V$CORRUPT_XID_LIST中。
大多数撤消损坏可以通过强制提交进行恢复。
TransactionIntegrityCheck。
TransactionIntegrityCheck与UndoSegmentCheck基本相同，只是它仅检查作为输入参数传递给该检查的特定事务。
找到撤消损坏的位置后，该检查使用PMON和SMON尝试恢复损坏的事务。
如果该恢复失败，则自动运行情况监视将有关损坏的信息存储在V$CORRUPT_XID_LIST中。
大多数撤消损坏可以通过强制提交进行恢复。
DictionaryIntegrityCheck。
该检查将检查核心字典对象（如tab$和col$）的完整性。
它验证每个字典对象的字典条目内容是否符合以下条件：
字典中行的逻辑约束为强制，并且字典对象间的父子关系为强制。
自动运行情况检查
还记得检查器主屏幕？
注意页面底部的CheckerRuns列表，它显示已经发生的各种检查器运行及其RunType。
如果您手动运行了一个检查器（如在本部分前面所做的那样），RunType将显示“Manual”。
作为“Reactive”列出的检查器运行表明它们是在某处检测到错误时自动运行的。
如果运行发现情况，将进行记录，您可以单击这些超链接来访问相关发现。
例如，单击第一个运行HM_RUN_140013将显示该检查器运行的详细信息：
该屏幕清楚地显示了故障原因。
实际上，至少有两种类型的故障：
损坏的联机重做日志文件和数据文件。
您首先需要单击LaunchRecoveryAdvisor按钮寻求建议。
显示一个基于向导的界面后，您将看到一个屏幕，其中的顾问工具指导您执行一个特定操作：
该操作应为运行/home/oracle/diag/rdbms/odel11/ODEL11/hm目录中的SQL文件reco_767216331.hm。
如果您打开该文件，将看到以下内容：
begin
/*CleartheLogGroup*/
executeimmediate'ALTERDATABASECLEARLOGFILEGROUP3';
end;
损坏的日志文件属于一个未激活的组，因此最好将其清除—这是来自RecoveryAdvisor的建议。
如果您决定采纳该建议，按Continue按钮，恢复将继续。
完成后，如果您返回SupportWorkbench，您将看到重做损坏已经不见，但是在存档日志中已检测到一个新的损坏。
与往常一样，您可以启动建议工具来修复这些错误。
自动诊断信息库
当检查器发现情况时，它们需要将它记录到某个地方以便进一步的分析和后续的处理。
所有相关元数据都记录在一个称为自动诊断信息库的新工具中，该工具记录所有重要事件而不只是检查器检测到的事件。
它类似于数据库中重要事件的SYSTEM表空间。
下面我们来看看如何通过企业管理器使用它。
在EnterpriseManager主Database页面中，单击SoftwareandSupport选项卡，然后单击SupportWorkbench，将显示一个类似如下所示的屏幕。
该屏幕只显示了检查器报告的情况汇总：
出现了ORA-603错误。
单击错误左侧的+号将显示这些错误的详细信息。
如果单击Incidents标题下每个事件id对应的链接，您可以查看这些事件。
例如，单击事件14435对应的链接将在如下所示的屏幕中显示该事件的详细信息：
屏幕顶部显示的详细信息可能具有自我说明性。
屏幕底部显示该事件的支持详情（如跟踪文件）。
这些文件将发往OracleSupport进行分析（但仅当您使用事件打包服务将它们打包到一起并且Oracle配置管理器配置了合适的证书时）。
单击第一个跟踪文件旁边的眼镜图标将显示该跟踪文件，如下所示：
注意文件中的行如何以十分用户友好的方式进行分析和显示的。
企业管理器读取每行，识别每行，然后以适当的缩进显示它们。
如果单击文件中的超链接，您将看到跟踪文件中的原始部分。
您可以将事件组成一个“信封”发往OracleSupport，这也是您下一步应该做的：
将它们打包到一起。
为此，在Select下的复选框中单击并单击Package按钮。
这将显示一个类似如下所示的屏幕：
此时，忽略CustomPackaging。
单击QuickPackaging并按Continue，将显示一个如下所示的屏幕：
输入所有详细信息并按Next。
后续的屏幕确认正在打包的事件、程序包清单等等。
这里，您会看到所有与该错误相关的跟踪文件都已发现并添加到程序包中。
该过程使您从识别特定错误的正确跟踪文件集这一容易出错的任务中解放出来，同时该工具还具有将相关错误的跟踪文件收集到同一程序包中的智能。
这很重要，因为Oracle需要利用所有相关错误的跟踪文件来确定问题的根本原因；您决定打包的错误可能是一个症状而非根本原因。
最后，您可以按Submit将其发送到Oracle。
一旦提交，屏幕便会发生变化，如下所示：
注意Packaged列下现在是如何出现了一个条目（“Yes”）。
这确认事件已打包。
再注意一个部分：
这表明上载文件已生成并附带相应的详细信息，如生成时间、程序包中的主要问题等。
但是，文件并未上载到OracleSupport，因为您尚未安装配置管理器或尚未对其进行配置。
您将在以后了解该特性；现在，如果您单击该名称，您将看到有关该程序包的更多详细信息：
详细信息都具有自我说明性。
事件都以超链接的形式显示，单击它们将转至您在前面看到的事件页面。
单击Files选项卡将打开一个页面，显示程序包中包含的所有文件。
单击最右侧的小眼镜图标可以查看文件。
现在，单击ActivityLog选项卡将显示程序包的历史记录，如创建时间、发送到Oracle的时间（如果发送）等。
定制程序包
该工具最有用的特性之一是能够定制发往Oracle的程序包内容。
要实现该任务，单击Customize按钮。
单击该按钮将显示如下所示的屏幕：
注意右侧的PackagingTasks面板。
在该面板中，您将看到用于执行与该程序包相关的各种任务的超链接。
下面是一些主要的任务：
▪EditContents
▪
a.AddProblems：
允许您向同一程序包中添加更多问题。
当您认为这些问题相关时，该链接有用。
b.ExcludeProblems：
允许您删除问题；当您认为这些问题与程序包中的其他问题不相关时，该链接有帮助。
c.ViewPackageManifest：
清单是一个描述程序包内容（描述的内容、涉及的问题、包含的各种跟踪文档等）的文档。
这是一个文本文件。
单击该链接将显示清单。
▪ScrubUserData
▪
d.CopyoutFilestoEditContents：
通过该链接，您可以将程序包中包括的跟踪文件和其他文件复制到一个本地OS文件夹并对进行编辑（如果需要）。
如果文件包含敏感数据，您可能希望执行该任务。
e.CopyinFilestoReplaceContents：
编辑文件后，您可以用编辑的副本替换程序包中的副本。
▪AdditionalDiagnosticData
▪
f.GatherAdditionalDumps：
允许您添加几个其他尚未包含的转储（如设置sql_trace=true后生成的跟踪文件）和测试案例。
g.AddExternalFiles：
您可以向该程序包添加OracelSupport（或其他相关部门）要求的任何其他文件（如init.ora或listener.ora）。
▪SendtoOracleSupport
▪
h.FinishContentsPreparation：
顾名思义，您可以确认内容正常并可以发往OracleSupport。
i.GenerateUploadFile：
允许您再次生成上载文件，并附带您在文件列表中添加和删除的内容。
j.View/SendUploadFiles：
允许您将文件上载到OracelSupport（如果您已经配置了配置管理器）。
配置管理器
如果可以通过您的CSI和MetaLink用户ID等相关详细信息创建程序包并发往OracleSupport以及创建草拟的服务请求（TAR）该多好啊？
使用一个名为Oracle配置管理器的工具可以实现此目的。
在Oracle数据库11g安装期间，系统询问您是否希望安装和配置该工具。
如果您回答了“yes”，则已经安装并配置了该工具；如果您回答了“no”，您可以现在配置它。
转至Oracle主目录并使用cd命令进入ccr/bin。
然后，运行setupCCR文件对配置管理器进行首次设置。
它显示一个许可消息，最后系统将询问您是接受还是拒绝该许可。
随后，系统将询问您一些问题，如CSI编号、MetaLink用户ID等。
以下文本显示了交互式会话。
用户输入以粗体显示。
***Doyouacceptthislicenseagreement?
（Y/N）[Y]:
Y
Configurationrequiresthefollowingpiece（s）ofinformation.
CustomerSupportIdentifier（CSI）:
XXXXXXX
OracleMetaLinkUserName:
arup@
Thetwocharactercountrycode:
US
**Installingbasepackage**
Deployingcore-Version10.2.6.0.0
**RegisteringinstallationwithOracleConfigurationManagerserver（s）**
Deployingengines-Version10.2.2.0.3
Deployingmetricdata-Version10.2.4.0.2
Deployingscripts-Version10.2.6.0.0
**GettingpackageupdatesfromContentServer**
**StartingtheOracleConfigurationManagerScheduler**
OracleConfigurationManager-Release:
10.2.6.0.0-Production
Copyright（c）2005,2007,Oracle.Allrightsreserved.
------------------------------------------------------------------
StartingOracleConfigurationManager...
WaitingforstatusfromOracleConfigurationManager....
StartDate16-Oct-200709:
28:
46
LastCollectionTime-
NextCollectionTime17-Oct-200709:
28:
00
CollectionFrequencyDailyat09:
28
CollectionStatusscheduledcollectionrunning
LogDirectory/home/oracle/app/oracle/product/11.1/db_1/ccr/log
RegisteredAt16-Oct-200709:
28:
17
AutomaticUpdateOn
CollectorModeConnected
OracleConfigurationManagersuccessfullystarted.
设置完配置管理器后，您可以使用同一目录中的configCCR脚本更改参数。
ADR主目录
既然所有的焦点都集中于数据库的诊断能力，那么Oracle数据库是不是应该存储以结构化方式组织的所有跟踪文件、日志文件等等？
在Oracle数据库11g中确实如此。
自动诊断信息库（ADR）文件位于一个指定为诊断目标（或ADR基目录）的常用目录下的目录中。
该目录由初始化参数（diagnostic_dest）设置。
默认情况下，它设置为$ORACLE_BASE，但是您可以将其显式设置为某些独占目录。
（但是不建议这样做。
）该目录下有一个diag子目录，您将在这个子目录中发现存储诊断文件的子目录。
ADR存储所有组件（ASM、CRS、监听器等）的日志和跟踪文件，包括数据库本身的日志和跟踪文件。
这使您可以方便地在一个位置查找特定的日志。
在ADR基目录中，可以有多个ADR主目录，每个组件和实例一个。
例如，如果服务器有两个Oracle实例，则有两个ADR主目录。
下面是数据库实例的ADR主目录的目录结构。
目录名称
说明
<在DIAGNOSTIC_DEST参数中提到的目录>
→diag
→rdbms
→<数据库名称>
→<实例名称>
→alert
XML格式的警报日志存储在这里。
→cdump
核心转储存储在这里，相当于早期版本中的core_dump_dest。
→hm
运行情况监视对多个组件运行检查，它在这里存储某些文件。
→incident
所有事件转储都存储在这里。
→<所有事件目录存在这里>
每个事件存储在一个不同的目录中，这些目录都存储在这里。
→incpkg
当您打包事件时（在本文中可以了解打包），某些支持文件存储在这里。
→metadata
有关问题、事件、程序包等的元数据存储在这里。
→trace
用户跟踪文件和背景跟踪文件存储在这里，并附带警报日志的文本版本。
例如，如果您的数据库名称为ODEL11并且实例名称也为ODEL11（大写），则ADR主目录的路径为/home/oracle/diag/rdbms/odel11/ODEL11。
现在，您会在该ADR主目录下看到不同的子目录：
$ls
alertcdumphmincidentincpkgirlckmetadatastagesweeptrace
要支持这个新结构，忽略以前版本中的*_dest参数（background_dump_dest和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
$ls
alertcdumphmincidentincpkgirlckmetadatastagesweeptrace
对于监听器，diag下的目录为tnslsnr，在该目录下是另一个以主机名命名的目录，然后在该主机名目录下是另一个以监听器名称命名的目录。
在该监听器名称目录下，您会看到其他目录。
<在DIAGNOSTIC_DEST参数中提到的目录>
→diag
→tnslsnr
→<服务器的主机名>
→<监听器名称>
→alert
→trace...
例如，如果主机名为oradba3并且监听器名称为“listener”（默认名称），则该目录为/home/oracle/diag/tnslsnr/oradba3/listener。
在该目录下创建所有其他目录（alert、trace、metadata等）。
与警报日志一样，监听器日志文件也作为XML条目存储在alert子目录下。
普通的文本监听器日志文件仍然在trace目录下创建。
新视图V$DIAG_INFO显示有关ADR主目录的所有详细信息。
在我的RDBMS主目录中，它显示如下：
SQL>select*fromv$diag_info;
INST_IDNAMEVALUE
-------------------------------------------------------------------------------------------------------
1DiagEnabledTRUE
1ADRBase/home/oracle
1ADRHome/home/oracle/diag/rdbms/odel11/ODEL11
1DiagTrace/home/oracle/diag/rdbms/odel11/ODEL11/trace
1DiagAlert/home/oracle/diag/rdbms/odel11/ODEL11/alert
1DiagIncident/home/oracle/diag/rdbms/odel11/ODEL11/incident
1DiagCdump/home/oracle/diag/rdbms/odel11/ODEL11/cdump
1HealthMonitor/home/oracle/diag/rdbms/odel11/ODEL11/hm
1DefaultTraceFile/home/oracle/diag/rdbms/odel11/ODEL11/trace/ODEL11_ora_3908.tr
升级会员 