深入解析Oracle：数据库的初始化

今天，也即2013年6月26日，Oracle数据库的最新版本 12c 终于正式发布了，这是一个全新的数据库版本，是 Oracle向云计算领域开拓的坚定体现，这一版本中最引人瞩目的新技术是多租户选件（Multitenant Option），这一选件的实现基础是插接式数据库（Pluggable Database），通过这一特性，Oracle可以将以前Schema级别的用户隔离上升到PDB级别的数据库隔离，这一特性是为云计算而生的，现在不同的用户共享一个大的容器（Container），而在容器中作为独立的个体存在，不论从管理、安全和易用性上都得到了提升。更重要的是，这个特性可以大大简化数据库的整合与迁移。

随着这一版本发布，Oracle新的关键词被推出“Plug into the Cloud（插入‘云’端）”，通过Oracle 12c发布前与微软和SalesForce确立的合作关系，甲骨文已经在两大系统上嵌入了云平台，由此可见Oracle公司的布局与决心。

根据Gartner公司的调查数据，在2012年的关系数据库市场，Oracle的市场份额为48.3%，稳居第一。但是我们早已注意到，关系数据库的市场份额已经没有悬念，而且也不会发生太大的变化，战场已经转移。现在看起来，云计算正是一个兵家必争的新战场。

早在Oracle 12c推出之前，Oracle公司已经推出了自己的云数据库平台，试水公众云数据库服务，但是该服务仅仅是试水而已，现在联手微软、SalesForce 等云平台与云服务厂商，Oracle的云理念才显得咄咄逼人。不论如何，云技术以各种形式走到我们技术人的面前。

这意味又一个变革的时代来临了。

这于我是一个契机和动力，我决定修订出版多年的《深入解析 Oracle：DBA 入门、进阶与诊断案例》（简称为《深入解析 Oracle》，该书第 1 版的书名为《深入浅出Oracle：DBA入门、进阶与诊断案例》）一书，加入12c的新技术内容，梳理多年间积累的一些经验和想法，再度与我的读者们分享；《深入解析Oracle》一书已经绝版多年，时至今日仍然不断有读者像我询问该书，这间接地成为我修订这本书的另一个动力泉源。

根据我的设想，这本书会和《循序渐进Oracle：数据库管理、优化与备份恢复》（简称《循序渐进 Oracle》）一书进行整合。这两本书虽然写作年份不同，但是内容是相辅相成的，由于两本书写作时间和规划原因，章节的学习顺序在两本书中是交叉的，现在我决定重新梳理两本书，整合成一个更加合理的顺序，以方便读者的阅读和学习。

我的计划是整合为3本书，分别从数据库的初始化、管理和优化三个方面进行阐述。现在这第一本正是从数据库的初始化开始。我不知道自己的这个规划是否能够如愿完成，但是只要读者支持，并且我分享的内容对大家还有价值，我就会坚持下去。

所以，这本书中包含了来自《循序渐进Oracle》一书中的两个章节，如果你手上还有这本书，其中的一部分内容是重合的。如果你不确信是否需要本书，请先从网上阅读本书的相关内容再做决定。

另外，我的写作方式仍然是一如既往的秉承“由浅入深，定点发散”的原则，我认为从任何一个知识点不断深入下去再出来，必然如同“拔起萝卜带起泥”一样触发一个系列的知识点的学习和研究，深入到最底层，再回到最初，我希望大家都能达到“看山还是山”的进阶状态。

在Oracle 12c发布之后，很多基于新特性的研究也可以和大家在本书中分享，如第3章中关于PDB的讨论就是全新的内容，也是Oracle 12c最重要的技术变革，而其他数十个新特性也散见于各章节的相应位置，希望这些内容和我之前从 Oracle 10g、Oracle 11g的内容一脉相承，能够带给读者一以贯之的技术理解。

在本书的写作修订过程中，得到了云和恩墨同事们的支持与协助，在此表示感谢；我尤其要感谢由迪同学，他在环境准备、测试验证等方面为我提供了大量帮助；我还要把本书献给我的家人，正是他们的支持与理解，才让我有了更多的时间来完成本书的内容，感谢我的妻子和儿子们，你们是我不停歇的爱的源泉。

我还要特别感谢我的编辑杜洁，我和她相识于2004年，那时我刚到北京1年，她大约也刚刚毕业加入人民邮电出版社，我和她的合作就是从那时开始的，到现在转眼10年，我仍然在做技术，她也还是特立独行地做她喜欢的书，10年光阴流逝，我们都步入了人生的另一个阶段。感谢她 10 年来给予我的帮助和支持，如若没有她的督促，也决然不会有这本书的修订和再版了。

最后，虽然我在写作和修订的过程中付出了不懈的努力，但是由于个人能力所限，书中难免错谬与不足，敬请读者在阅读中能够给予指正和谅解。

2013年6月26日于北京

我和国强兄相识于 2006 年首届中国杰出数据库工程师评选，彼时一见如故，惺惺相惜，大有一见倾心，相见恨晚之意。

国强兄与我性格类似，都是勤奋、努力、踏实和真诚之类性情中人。忆初见时坐而论道，由东方不败起，纵论天下风云，国强兄侃侃而谈，旁征博引，一直论及数据库之江湖，皆有独到之见解，令吾辈同侪叹为观止！

近几载来，数据库江湖王国人才辈出，但环顾国内，在技术上能让我服膺者少之又少，国强是其中之一，窃以为，堪执国内数据库界执牛耳者，国强或可勉力为之，国强对数据库的精通应已达举重若轻、大巧不工之境。古人有“术”“道”之论，以数据库技术而论，国强应近乎道矣！

本书非仅对数据库管理员来说非常实用，对数据库爱好者也是登堂入室的宝典秘籍，国内数据库书籍，或强调概念，或强调经验，能把复杂的概念用深入浅出的方式讲解得如此之通透者，吾之所识，惟国强尔，古有白居易诗妇孺能解，大约国强兄之良苦用心意在老少咸宜，对应不同程度之读者，可入门，可进阶，可深入，皆可有所裨益。所谓经典，应该用时间来检验，本书初版时，已洛阳纸贵，依然在国内热卖，我对本书深具信心，对新版的面世更怀有热烈的期待。

中国民生银行总行科技部副总经理

Oracle这几年新功能的推出和改变挺多，相应的书籍也自然与时俱进。写书说起来容易，真到落笔的时候却是考验自己毅力的事情。Eygle 一向是能长期坚持的人，这么多年不断地学习、不断地分享。独乐乐不如众乐乐，开放、分享是互联网的精神，可以说我们这一代人成长于互联网又回馈于互联网，本书则是Eygle回馈内容的升华。

现在Eygle已经借着多年的积累开始闯荡自己的事业，这是对技术从业人员的一种鼓舞。一个行业要打通成长之路，必然需要无数的人为之辛苦努力，营造良好的环境，树立榜样，为后来者指明方向。

希望本书能帮助到正在这个方向上努力着的数据库从业者，同时也希望大家能将这种分享精神，传递给正要从事这个行业的人。

支付宝数据平台负责人

盖国强（Eygle）是我认识的DBA中，较早开始做Oracle，而且又能持之以恒、坚持不懈地做研究的人，非常值得敬佩。在我们相识的多年中，他积累并撰写了大量的技术文章，连续出版了几本非常不错的书籍，其中也包括本书。

登录他的个人网站（www.eygle.com），或者是看他的书，就能发现不少特点。

细致专业：作者这几年几乎把他的全部心思都扑到了Oracle上，看看他的文章，或者是他写的书就可以发现这个特点，比如他在Oracle内部结构、一些参数（包括隐含参数）的研究中，发现了很多别人没有发现的问题，给广大的Oracle爱好者提供了非常大的帮助。包括我自己，也是他的网站的忠实读者，因为可以经常在这里找到一些好东西。而他的新书，则是长期以来这些经验的积累与汇总。

经验总结：我曾经看过作者很多实际的诊断案例，可以看到其思维非常严谨，在实践中能从一点点蛛丝马迹中发现问题的所在，这种功底同样反映到他的新书上面，对于一些别人不曾注意的角落，他都可以挖掘出很有用的信息，并最终诊断出问题的所在。在本书中，收录了作者作为资深 DBA所遇到的大量实际案例，我相信，这种实战经验总结能给大家非常大的帮助。

本书是基于《深入解析Oracle》的修订和扩展，继承了浅显易懂，也不缺乏深入研究的传统。对于初级读者，可以从作者的新书中马上获得很多有用的信息；对于中高级读者，也可以从书中获得很多深入的研究信息；对于实际工作中的 DBA，则可以从中获得很多有价值的案例分析方法与实际的处理技巧。

淘宝生活服务事业部资深总监，Oracle ACE Director

《构建Oracle高可用环境》作者

对于很多初学者来说，安装数据库软件、创建数据库通常是Oracle学习的开始。

在完成软件安装之后，就可以开始创建数据库。数据库的创建可以通过 DBCA（Database Configuration Assistant）工具或者手工方式来完成，通常我们习惯使用DBCA，但是我建议大家都能够尝试一下使用手工的方式进行数据库创建，因为那将使你更加了解Oracle数据库的创建过程。

如果从数据库创建进行深入，你会发现相关知识会延展到各个层面，由这一个点开始，广阔的Oracle知识会逐渐展现在你面前，本书就从这样一个起点开始。

从这样一个起点开始，我试图将所有的相关知识点拓展剖析，以扩大和加深读者对于Oracle数据库技术的理解和认知，全面了解数据库的功能和特性，并恰如其分的应用到合适的场景，就是一个DBA的使命。

本章内容主要以主流版本Oracle 11g为讲解模板，同时涵盖Oracle 12c的主要变化，在实际建库的过程中，不管是在Linux/UNIX还是Windows上，不管是Oracle 12c还是Oracle 11g，创建数据库的步骤都是基本相同的。现在企业级数据库应用，Oracle 11g已经成为主流，DBA的学习应该以11g为核心，兼顾12c的新特性。

在学习和接触Oracle数据库时，首先需要获取相关软件并安装创建数据库，本节简要介绍一下Oracle软件的获取与安装。

Oracle的软件可以从官方网站上下载，主要的网址链接为：http://www.oracle.com/us/products/database/overview/index.html。

在这里可以找到Oracle数据库产品的详细信息（这个页面经常更新，目前Oracle 12c是主推的产品之一），如图1-1所示。

注册一个OTN的账户后，就可以下载Oracle最新的软件版本，目前Oracle数据库的最新版本为12.1.0.1.0，率先发布的是Linux和Solaris平台版本，如图1-2所示，OTN提供下载的数据库软件企业版在非商业应用中，不存在任何功能上的限制。Oracle 12c的关键词是“Plug into the Cloud”，这是Oracle将数据库推进到云平台的重要举措，而在Oracle 12c版本正是发布之前，Oracle 公司已经宣布了和微软公司和 Salesforce 的合作，通过两者的平台来推广云数据库。

除了12cR1之外，目前最为广泛采用的版本是11gR2，下载页面上可以看到一个2011年11月 10日添加的重要提示：Oracle Patch Set 11.2.0.3已经发布，该Patch Set是一个完整的安装版本，不需要预先安装11.2.0.1，该Patch Set需要从 support.oracle.com站点下载，如图1-3所示。

注意：Support站点仅对Oracle付费用户开放，对于常规的测试目的，11.2.0.1通常已经足够。

为了推广 Oracle 11g 产品，Oracle 公司还注册了一个独立的站点（http://www. oracledatabase11g.com/），从这里可以找到大量的关于Oracle 11g的相关文档信息。

在安装Oracle软件的过程中，有一个类似如图1-4所示的界面（以下两图可以比较从Oracle10gR2到Oracle 11gR2安装界面的变化），Oracle 11gR2列表式的安装步骤显示更加直观，并被一直延续到Oracle 12c版本。

在这个页面中，可以选择在安装软件结束后同时创建数据库，也可以选择“仅安装数据库软件”，建议大家选择“仅安装数据库软件”项，该选项可以将软件安装和数据库创建分离开来，这样既可以将独立的两个过程分步进行，又可以在安装软件后进行从容的检查、配置和补丁应用等。

部署生产环境时，在安装完成数据库软件之后，需要安装和软件版本相关的最新补丁包，目前Oracle 10gR2最新的补丁包为Oracle 10.2.0.5，这也是Oracle 10gR2的最终补丁包；对于Oracle 11gR2，目前最新的补丁集是 11.2.0.4版本。Oracle的补丁软件通过Metalink支持站点（http://support.oracle.com）发布，该站点仅对购买了Oracle服务的用户开放。

在Oracle 11gR2之前，补丁集以一个修正包的形式发布，安装补丁包，覆盖原有数据库安装的相关文件后完成升级，如果需要升级已有的数据库，还需要按照指定的步骤运行一系列的脚本文件，完成升级；从Oracle 11gR2的第一个补丁集开始（也即 11.2.0.2），Oracle修改了补丁发布策略，现在发布的补丁文件是一个完整的数据库版本，可以独立安装，在安装时建议选择独立的安装目录，保持原有的安装不变，安装完成之后，可以调用 DBUA（Database Upgrade Assistant）来完成既有数据库的升级。

目前11gR2广泛采用的11.2.0.3的补丁集，其Patch号为10404530，共包含7个压缩包，前两个为安装数据库的软件，如果仅安装数据库，这两个就够了；第三个是Grid的安装包；7个文件大约5GB左右，以下列出了压缩包及其内容：

Oracle 11.2.0.3.0在Linux X86-64平台上的补丁信息如图 1-5所示。

以下通过Oracle 11g 11.2.0.2的补丁集安装过程，简要介绍一下Oracle补丁集的这一重要变化。在初始的步骤中，如果是在软件安装过程中，请选择“仅安装数据库软件”即可，如果需要升级数据库，则选择“升级现有的数据库”选项，如图1-6所示。

在图1-7中，如果安装路径选择了现有的Oracle 11g安装目录，安装程序会给出重要提示，建议安装11.2.0.2 到不同于11.2.0.1的目录，独立安装的好处是，当升级过程出现异常时，原有的软件目录未有丝毫改变，可以无损的启动原有数据库，这是独立安装带来的重要好处。

安装数据库软件的过程如图1-8所示。

补丁安装完成之后，会自动启动 DBUA 升级程序，可以选择要升级的数据库进行升级，如图1-9所示。

在升级之前，基于性能的考虑，DBUA 建议启用并行、关闭归档等，同时建议对数据库进行备份，这些以前需要DBA根据经验调整的内容，现在都可以通过DBUA来自动完成，如图1-10所示。

升级过程会较为缓慢，在生产数据库的升级中，尤其需要谨慎。

如果我们之前仅安装了数据库软件（或者也应用了补丁软件），在完成安装之后，可以通过运行DBCA（Database Configuration Assistant）来启动数据库创建过程。

DBCA可以通过命令行方式启动，在命令行键入“dbca”即可启动数据库创建助手界面，如图1-11所示。

在Oracle 12c中，DBCA的初始页面如图 1-12所示，其中增加的主要选项为“管理插接式数据库”，这是12c新增功能“插接式数据库”的对应选项（具体可以参考本书的第3章）。

在Windows系统上，通过命令行来运行dbca命令，实际上调用的是$ORACLE_HOME\bin\下的dbca.bat批处理文件，可以简略地看一下这个批处理文件的内容（省略了部分内容）：

D:\oracle\11.2.0\BIN>type dbca.bat

@set OH=D:\oracle\11.2.0

@set CLASSPATH=%DBCA_CLASSPATH%;%ORACLE_OEM_CLASSPATH%

@set PATH=%OH%\bin;%PATH%

"D:\oracle\11.2.0\jdk\jre\BIN\JAVA" -DORACLE_HOME="%OH%" -DJDBC_PROTOCOL=thin -mx128m oracle.sysman.assistants.dbca.Dbca

可以看到在设置了一系列的环境变量之后，通过调用 Java 运行时环境启动了 Java 工具DBCA。以下是Linux环境中，Oracle 12c的DBCA脚本执行代码，与其他版本基本相同：

[oracle@enmodb12c ~]$ which dbca

/u01/app/oracle/product/12.01/dbhome_1/bin/dbca

[oracle@enmodb12c ~]$ tail -2 /u01/app/oracle/product/12.01/dbhome_1/bin/dbca

exec $JRE_DIR/bin/java $JRE_OPTIONS $DEBUG_STRING -classpath $CLASSPATH

oracle.sysman. assistants.dbca.Dbca $ARGUMENTS

同样，最后一行命令启动了Java应用DBCA工具。以上就是DBCA的初始化及启动。

启动DBCA之后，就可以通过图形界面进行数据库各项参数的配置，下面对几个重要步骤进行一点说明。

在如图1-13所示的选择数据库模板界面中，可以选择使用模板来创建数据库或者通过自定义方式来创建。注意，图1-13中的（b）图来自Oracle 11gR2版本的相同界面，在这个界面上，已经带有明确的提示文字，指出“带数据文件的模板包含预先创建的数据库”，使用这样的模板可以在数分钟内创建完数据库，否则需要一个小时甚至更长时间。这些说明解释清楚了很多必要的问题。

我们选择通过自定义方式创建数据库，在界面中选择“定制数据库”即可。定制数据库不包含数据文件，需要实时创建，使用模板则会使用“种子数据库（Seed Database）”的备份集恢复出预先创建好的数据文件。

接下来的步骤3需要定义一个数据库名称和SID，步骤4则引入了自Oracle 10g开始的基于浏览器的Database Control项，此处通常选择缺省配置“使用Enterprise Manger配置数据库”复选框即可，如图1-14所示。

在Oracle 11gR2的步骤4中，增加了一个选项页，用于定义自动维护任务，在这个页面，用户可以选择是否启用自动维护任务，这些任务包括“优化程序统计信息收集和预防性指导报告”，如图1-15所示。

提示：Oracle的每一个小的改动都有其背后的深层原因，在Oracle 10g中，自动运行的维护任务影响了很多正常的业务运行，导致故障，所以在这里，Oracle 将选择权交给用户。观察Oracle的每个变动非常有助于我们理解数据库的变革。参考1.4小节可以获得相关诊断案例。

这些缺省启用的任务可以通过 dba_autotask_task 视图查询获得，以下是 Oracle 11gR2 11.2.0.2版本的自动任务定义：

SQL> select client_name,task_name,status from dba_autotask_task;

CLIENT_NAME　TASK_NAME　STATUS

-------------------------------------- ---------------------------------- ------------

sql tuning advisor　AUTO_SQL_TUNING_PROG　ENABLED

auto optimizer stats collection　gather_stats_prog　 ENABLED

auto space advisor　auto_space_advisor_prog　ENABLED

我们知道在Oracle 9i之前，数据库会为数据库用户指定缺省口令，SYS用户的缺省口令为change_on_install，SYSTEM的缺省口令为manager，但是由于很多用户经常忘记修改缺省口令，进而可能为数据库留下安全隐患，所以从Oracle 9i开始，Oracle要求用户在创建数据库时自行指定用户口令。

接下来是步骤5，在图1-16的（a）图中，可以简单地为所有初始用户定义一个缺省口令，但是这样显然不够安全，（b）图是Oracle 11gR2版本的界面，Oracle将（a）图中选项上下置换，缺省要求为所有用户指定不同的口令，小小的变化昭示着安全上的重视与增强。

在 12c版本中，Oracle将两个安全组件Database Vault和Label Security集成到了创建数据库的选项中。如果数据库软件包含了这些选件，那么在“Database Options”界面中就可以进行配置，如图1-17所示。这是Oracle在安全性方面的一项推进和整合增强。

步骤6是如图1-18所示的存储选项界面，该界面用于选择数据库的存储机制，通常可以选择文件系统存储，从 Oracle 10g开始 Oracle引入了自动存储管理（Automatic Storage Management）的新特性，我们将在后面章节详细介绍这一新特性。从Oracle 11gR2开始， Oracle 放弃了对于裸设备的支持，在选择存储选项时也就少了一个选项（仅有文件系统和ASM两个选项），以下（b）图来自Oracle 11gR2的安装截图。

注意，由于ASM技术主要是为RAC集群数据库开发的，所以在单机上使用ASM需要进行一些特殊的配置，在Oracle 10g中，需要启动CSS服务，在Oracle 11gR2中，需要安装Grid Infrastructure，图1-19中的（a）图是10g中的提示信息，而（b）图是11gR2中的提示信息。

步骤7和步骤8涉及空间位置的设置，如图1-20所示。其中步骤7指定数据库文件所在位置界面，数据库文件存储位置可以选择“使用Oracle管理的文件”选项，这实际上就是利用了Oracle 9i中引入的一个新特性OMF（Oracle Managed Files），在Oracle 11g的安装界面中，这个步骤被整合到了步骤 6 中；步骤 8 中恢复配置界面，该界面用于指定快速恢复区（Flash Recovery Area），这是Oracle 10g的一个新特性，用于简化用户的备份管理，快速恢复区可以是磁盘上的一个存储目录，也可以使用ASM存储，这里可以按照具体的需要设置；同时还可以在这个页面上选择是否启动数据库的归档模式。

单击“下一步”按钮，进入步骤 9，在如图 1-21 所示的选择数据库组件和定制脚本界面中，有很多Oracle数据库组件，如果没有特殊的需要，为了简化和快速安装，可以去除大部分选项（这要根据需要进行选择，如果为了构建一个简化的测试数据库，则可以去除多数选件）。

步骤10中包含了多个选项页，其中涵盖了大量重要的配置选项。

进入如图1-22所示的初始化参数界面，其中内存选项可以暂时接受数据库的初始推荐，这些参数可以在建库后再进行修改；其中（b）图是Oracle 11g的设置页面，变化不大。

在这个内存设置页面，实际上隐含了 Oracle 数据库从 10g 到 11g 的内存管理变化，在 10g中，通过设置 SGA_TARGET参数可以实现对于 SGA的自动管理，而在 11g中，通过设置 MEMORY_TARGET 参数可以实现对于 SGA+PGA 的统一内存调整和管理，这一变化隐藏在这一页面设置的背后，Oracle 的内存管理自动化在不同版本中在不断改进和增强。

在这个页面中可以为Oracle的内存使用选择一个比例，缺省值是40%，这是一个较为合理的开始，在数据库运行中，我们也可以根据需要对数据库的内存使用进行配置更改。

注意，数据块大小需要认真选择，如图1-23所示，一旦创建数据库之后，这个参数将不可修改（从Oracle 9i开始，Oracle支持在同一数据库中容纳不同block_size的表空间，但是初始定义的block_size将用于SYSTEM、UNDO等表空间，不可修改）。

字符集部分也需要认真选择，在中文的Windows平台上，缺省的字符集是ZHS16GBK，如图1-24所示，可以不需要修改，但是在Linux/UNIX下，如果系统语言环境缺省不是中文，那么这里就要根据需要进行调整；国家字符集用以存储NCHAR、NVARCHAR2、NCLOB等类型数据，作为数据库主字符集的补充，可以用来存储不同国家的特殊字符、特殊编码等内容，主要作用是为了增强Oracle的字符处理能力。国家字符集在Oracle 9i中进行了重新定义，只能在 Unicode 编码下的 AL16UTF16 和 UTF8 中选择，通常选择默认值AL16UTF16 即可；对于连接模式，可以选择默认的“专用服务器模式”选项，如图 1-24的（b）图所示。

国家字符集（AL16UTF16与UTF8）的主要不同如下。

AL16UTF16是宽度固定的、双字节Unicode字符集；而UTF-8是宽度可变的、一至三个字节的Unicode字符集。

欧洲字符在UTF8字符集中按一至两个字节存储，在AL16UTF16中按两个字节存储，相比之下，UTF8 节省空间；对于亚洲字符，其在 UTF8 中按三字节存储，所需空间比在AL16UTF16中的双字节要多。

在创建数据表时，可以通过国家字符集相应的数据类型存储特殊的字符。

下一个步骤是数据库存储界面，给出了存储及文件信息，如图1-25所示，可以按照需要进行调整，通常选择默认设置即可；需要注意控制文件选项，其中定义了对于控制文件至关重要的几个参数，这些参数在此一旦确定，以后往往需要重建控制文件才能修改。

最后一个步骤，可以选择将此前的设置存储为一个数据库模板，并生成创建数据库的脚本，如果接受“创建数据库”的选项，接下来就可以进行数据库的创建了（此处仅选择生成了模板和创建脚本），如图1-26所示。

单击“确定”按钮，进入如图1-27所示的界面，数据库完成了脚本生成工作。如果选择了创建数据库，此时将开始数据库创建工作。

在创建数据库的过程中遇到的错误，可以通过查找Oracle数据库的告警日志文件（alert file）获得，在某些情况下，还会有详细的跟踪文件（trace file）生成，这些文件的位置，在Oracle 11g之前，由*dump参数指定，告警日志文件alert_<ORACLE_SID>.log的位置由参数background_dump_dest定义：

SQL> show parameter background_dump_dest

----------------------------- ------------- -----------------------------------

background_dump_dest　string　D:\ORACLE\diag\rdbms\eyglee\eyglee\trace

可以在该参数的设置路径下，找到日志文件。从Oracle 11g开始，alert文件的格式发生了变化，除原有的文本格式外，还引入了XML格式。现在告警日志文件的存储位置受到一个新的参数影响，这个参数是diagnostic_dest，原有的*dump参数被废弃：

SQL> show parameter diag

----------------------------- ------------ ----------------------------------

diagnostic_dest　string　D:\ORACLE

diagnostic_dest是Oracle11g的新特性自动诊断库（Automatic Diagnostic Repository， ADR）的设置，该目录用于存放数据库诊断日志、跟踪文件等，通常称为ADR base，该参数的缺省值和环境变量ORACLE_BASE有关：

如果设置了ORACLE_BASE，则DIAGNOSTIC_DEST = ORACLE_BASE；

如果未设置ORACLE_BASE，则DIAGNOSTIC_DEST = ORACLE_HOME/log。

通过该目录结构，数据库整合存储了大量动态变化的日志及跟踪文件，方便管理和查看。在数据库出现问题时需要优先检查该文件，获得最及时的故障提示信息等。

查询v$diag_info视图可以获得跟踪诊断的相关信息，其中“Default Trace File”指出进程跟踪文件的可能名称：

SQL> select name,value from v$diag_info;

------------------------ -------------------------------------------------------------

ADR Base　D:\ORACLE

ADR Home　D:\ORACLE\diag\rdbms\eyglee\eyglee

Diag Trace　D:\ORACLE\diag\rdbms\eyglee\eyglee\trace

Diag Alert　D:\ORACLE\diag\rdbms\eyglee\eyglee\alert

Diag Incident　D:\ORACLE\diag\rdbms\eyglee\eyglee\incident

Diag Cdump　D:\ORACLE\diag\rdbms\eyglee\eyglee\cdump

Health Monitor　D:\ORACLE\diag\rdbms\eyglee\eyglee\hm

Default Trace File　D:\ORACLE\diag\rdbms\eyglee\eyglee\trace\eyglee_ora_3360.trc

Active Problem Count　3

Active Incident Count　45

在 DBCA 的最后一个步骤，如果保存生成了创建数据库的脚本，则可以通过手工执行这些脚本，在命令行完成数据库的创建工作，这可以使我们摆脱图形界面的困扰，特别是在一些不易于运行图形界面的环境。此外，很多时候通过DBCA创建数据库可能会遇到一些错误，这些错误在图形界面下可能不易判断，但是通过命令行则要容易定位得多。

现在通过数据库的创建脚本来深入地了解一下数据库的创建过程。按照上面的路径找到生成的数据库创建脚本。

D:\Oracle\admin\eygle\scripts>dir

2012-12-11 16:03　<DIR>　.

2012-12-11 16:03　<DIR>　..

2012-12-11 16:03　1,204 CreateDB.sql

2012-12-11 16:03　640 CreateDBCatalog.sql

2012-12-11 16:03　398 CreateDBFiles.sql

2012-12-11 16:03　281 emRepository.sql

2012-12-11 16:03　640 eygle.bat

2012-12-11 16:03　721 eygle.sql

2012-12-11 16:03　1,659 init.ora

2012-12-11 16:03　512 lockAccount.sql

2012-12-11 16:03　944 postDBCreation.sql

9 File(s)　6,999 bytes

2 Dir(s)　579,424,256 bytes free

在Linux/UNIX环境下，同样存在这样一系列的脚本：

[oracle@jumper scripts]$ pwd

/opt/oracle/admin/eygle/scripts

[oracle@jumper scripts]$ ll

-rw-r--r--　1 oracle　dba　713 Apr 24 2006 CreateDBCatalog.sql

-rw-r--r--　1 oracle　dba　338 Apr 24 2006 CreateDBFiles.sql

-rw-r--r--　1 oracle　dba　769 Apr 24 2006 CreateDB.sql

-rwxr-xr-x　1 oracle　dba　628 Aug 18 2006 eygle.sh

-rw-r--r--　1 oracle　dba　2764 Apr 24 2006 init.ora

-rw-r--r--　1 oracle　dba 442 Apr 24 2006 postDBCreation.sql

如果通过手工执行脚本来创建数据库，需要执行的脚本为eygle.bat（在Linux/UNIX下是eygle.sh脚本），来看一下这个脚本的内容：

mkdir D:\Oracle\11.2.0\database

mkdir D:\Oracle\admin\eygle\adump

mkdir D:\Oracle\admin\eygle\dpdump

mkdir D:\Oracle\admin\eygle\pfile

mkdir D:\Oracle\cfgtoollogs\dbca\eygle

mkdir D:\Oracle\fast_recovery_area

mkdir D:\Oracle\fast_recovery_area\eygle

mkdir D:\Oracle\oradata\eygle

set ORACLE_SID=eygle

set PATH=%ORACLE_HOME%\bin;%PATH%

D:\Oracle\11.2.0\bin\oradim.exe -new -sid EYGLE -startmode manual -spfile

D:\Oracle\11.2.0\bin\oradim.exe -edit -sid EYGLE -startmode auto -srvcstart system

D:\Oracle\11.2.0\bin\sqlplus /nolog @D:\Oracle\admin\eygle\scripts\eygle.sql

这就是Oracle创建数据库的过程。

（1）建立一系列的目录。

需要格外注意的是 cfgtoollogs\dbca\eygle 目录，在创建数据库时，主要的日志文件或输出信息会记录在该目录中，通过检查这些文件可以用来诊断创建过程中出现的一些错误。

（2）设置ORACLE_SID环境变量。

（3）通过oradim创建并配置实例。

（4）通过sqlplus运行脚本开始创建数据库。

ORADIM工具是Oracle在Windows上的一个命令行工具（在Linux、UNIX上无需这类工具），用于进行Oracle服务的创建、修改、删除等工作。ORADIM的使用很简单，通过帮助文件可以看到常用的命令示例，此处不再赘述。

ORADIM在数据库恢复中也常被用到，很多朋友都问过这样的问题：在Windows上，如果系统崩溃了，可能数据库软件丢掉了，但是数据文件、控制文件、日志文件等都还在，该怎样来恢复Oracle数据库？

其实过程很简单，通常只要按原来的目录结构重新安装Oracle软件，然后通过ORADIM工具重建服务，就可以启动实例、加载数据库（当然相关的参数文件和口令文件等需要在$ORACLE_HOME\database目录存在）。

来看以下过程，通过ORADIM创建一个服务后，实例会随之启动：

C:\>oradim -new -sid eygle

用net命令可以查看系统启动了哪些服务，看到Oracle的服务已经启动：

已经启动以下 Windows服务:

命令成功完成。

如果你的系统装了一些UNIX增强工具（强烈建议在Windows上安装UNIX增强工具集，熟悉常用UNIX命令），那么可以通过grep过滤一下：

C:\>net start |grep Oracle

使用ORADIM工具后，会在$ORACLE_HOME\database目录下生成一个日志文件。

注意到在ORADIM创建服务之前，首先设置了ORACLE_SID：

set ORACLE_SID=eygle

在Linux/UNIX系统的创建中，同样要设置ORACLE_SID，不过Linux/UNIX上不存在服务这项内容，实例是可以通过参数文件直接启动的。

注意：启动数据库实例还和一些内核参数有关，在产品环境中需要按手册认真设定。

看一下Linux上正常情况下启动数据库实例到nomount状态的过程：

[oracle@jumper oracle]$ cd $ORACLE_HOME/dbs

[oracle@jumper dbs]$ ls

initconner.ora init.ora lkCONNER orapwconner spfileconner.ora spfile.ora

[oracle@jumper dbs]$ export ORACLE_SID=conner

[oracle@jumper dbs]$ sqlplus "/ as sysdba"

SQL> startup nomount

ORACLE instance started.

Total System Global Area　80811208 bytes

Fixed Size　451784 bytes

Variable Size　37748736 bytes

Database Buffers　41943040 bytes

Redo Buffers　667648 bytes

注意这里，Oracle 根据参数文件的内容，创建了 instance，分配了相应的内存区域，启动了一组后台进程。

回顾一下前面的内容，注意到SID和ORACLE_SID已经多次出现，那么SID是什么？在数据库启动过程中又起到什么作用呢？

SID是System IDentifier的缩写，而ORACLE_SID就是Oracle System Identifier的缩写，在Oracle系统中，ORACLE_SID以环境变量的形式出现，在特定版本的Oracle软件安装（也就是ORACLE_HOME）下，当Oracle实例启动时，操作系统上fork的进程必须通过这个SID将实例与其他实例区分开来，这就是SID的作用。

我们知道 Oracle 的实例（ instance ）是由一块共享内存区域（ SGA ）和一组后台进程（background processes）共同组成；而后台进程正是数据库和操作系统进行交互的通道，这些进程的名称就是通过ORACLE_SID决定的。

实例的启动仅需要一个参数文件，这个参数文件的名称就是由 ORACLE_SID 决定的。对于 init 文件，缺省的文件名称是 init<ORACLE_SID>.ora，对于 spfile 文件，缺省的文件名为spfile<ORACLE_SID>.ora，Oracle 依据 ORACLE_SID 来决定和寻找参数文件启动实例，参数文件的缺省位置为$ORACLE_HOME/dbs（Windows上为$ORACLE_HOME\database目录）。

spfile从Oracle 9i开始引入并成为了缺省使用的参数文件，Oracle启动实例时按照以下顺序从缺省目录查找参数文件：spfile<ORACLE_SID>.ora Æspfile.ora Æinit<ORACLE_SID>.ora。如果这3个文件都不存在，则Oracle实例将无法启动.

通过这些信息可以知道，在同一个 ORACLE_HOME 下，Oracle 能够根据 ORACLE_SID将实例区分开来；但是如果在不同的 ORACLE_HOME 下， Oracle 将不屏蔽相同名称的ORACLE_SID，也就是说，在同一台主机的不同ORACLE_HOME下，Oracle也是能够创建相同ORACLE_SID的实例的。

以下一个测试，首先启动一个Oracle 8i下ORACLE_SID为 eygle的实例：

$ export ORACLE_SID=eygle

$ sqlplus "/ as sysdba"

SQL*Plus: Release 8.1.7.0.0 - Production on Fri Feb 16 10:23:58 2007

Connected to an idle instance.

SQL> startup nomount;

ORACLE instance started.

SQL> ! ps -ef|grep smon

oracle8 11092　1 0 10:24:02 ?　0:00 ora_smon_eygle

接下来又可以启动另外ORACLE_HOME下ORACLE_SID为eygle的实例：

$ export ORACLE_SID=eygle

$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Fri Feb 16 10:24:43 2007

Connected to an idle instance.

SQL> startup nomount;

ORACLE instance started.

SQL> ! ps -ef|grep pmon_eygle

oracle9 11180　1 0 10:24:48 ?　0:00 ora_pmon_eygle

oracle8 11084　1 0 10:24:02 ?　0:00 ora_pmon_eygle

现在这同一台主机上就启动了两个相同名称的实例，在操作系统上，Oracle能够通过唯一的ID标识将共享内存或信号量区分开来：

IPC status from <running system> as of Fri Feb 16 10:30:02 CST 2007

T　ID　KEY　MODE　OWNER　GROUP

q　0　0x2e781d5　--rw-r--r--root　root

T　ID　KEY　MODE　OWNER　GROUP　ISMATTCH

m　4096　0xabdc9b64　--rw-r----- oracle8 dba　12

m　1025　0x79552064　--rw-r----- oracle9 dba　11

s　1245184　0x79978bac　--ra-r----- oracle8 dba

s　458753　0xa0e9f594　--ra-r----- oracle9 dba

通过Oracle提供的一个小工具sysresv，我们可以找到对应于不同的ORACLE_SID，操作系统上创建的共享内存段 ID（Shared Memory）和信号量 ID（Semaphores）等信息。

$ sysresv -l eygle julia

IPC Resources for ORACLE_SID "eygle" :

Oracle Instance alive for sid "eygle"

IPC Resources for ORACLE_SID "julia" :

Oracle Instance alive for sid "julia"

在Linux/UNIX上，一个名为oratab的文件还记录有ORACLE_SID信息。在Solaris环境中，这个文件一般位于/var/opt/oracle目录下，在Linux及其他UNIX平台，这个文件一般位于/etc目录下。

该文件的主要内容如下：

# This file is used by ORACLE utilities. It is created by root.sh

# and updated by either Database Configuration Assistant while creating

# a database or ASM Configuration Assistant while creating ASM instance.

# A colon, ':', is used as the field terminator. A new line terminates

# the entry. Lines beginning with a pound sign, '#', are comments.

# Entries are of the form:

# $ORACLE_SID:$ORACLE_HOME:<N|Y>:

# The first and second fields are the system identifier and home

# directory of the database respectively. The third filed indicates

# to the dbstart utility that the database should , "Y", or should not,

# "N", be brought up at system boot time.

# Multiple entries with the same $ORACLE_SID are not allowed.

enmot1:/u01/app/oracle/product/11.2.0/dbhome_1:N

当配置实例随操作系统自动启动（或手工执行dbstart脚本）时，Oracle会根据这里记录的ORACLE_SID的<N|Y>的设置来决定是否启动相关实例。

与Linux/UNIX上的情况类似，Windows上的Oracle环境也依赖于服务而存在，如图1-28所示。我们注意到Oracle环境的初始化是通过执行ORACLE.EXE eygle来完成的，至于实例和数据库是否随服务启动则要依赖于注册表中的设置。

通过手动在命令行执行类似命令，可以初始化任意的Oracle应用环境，例如，以下命令就初始化了名为julia的运行时环境：

Press CTRL-C to exit server:

此后就可以连接到这个环境启动实例：

C:\>set ORACLE_SID=julia

C:\>set nls_lang=american_america.us7ascii

C:\>sqlplus "/ as sysdba"

SQL*Plus: Release 11.2.0.1.0 Production on Tue Aug 31 22:09:31 2010

Connected to an idle instance.

ORA-01078: failure in processing system parameters

LRM-00109:无法打开参数文件 'D:\ORACLE\11.2.0\DATABASE\INITJULIA.ORA'

当然还需要创建参数文件和口令文件等：

C:\>cp c:\oracle\10.2.0\database\SPFILEEYGLE.ORA c:\Oracle\10.2.0\database\spfilejulia.ora

C:\>orapwd file=c:\oracle\10.2.0\database\PWDjulia.ora password=oracle entries=5

此后，实例可以顺利启动，并可以挂接和打开数据库：

C:\>sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0 - Production on星期六 2月 17 10:13:10 2007

已连接到空闲例程。

SQL> startup nomount;

ORACLE 例程已经启动。

SQL> set linesize 120

SQL> show parameter instance_name

------------------------------- ------------------- ---------------

instance_name　string　julia

SQL> show parameter db_name

------------------------------- ------------------- ---------------

db_name　string　eygle

SQL> alter database mount;

数据库已更改。

SQL> alter database open;

数据库已更改。

如果在环境窗口中按下Ctrl+C组合键退出，则数据库将异常中断。

总结一下，实际上不管在Windows还是Linux/UNIX环境下，ORACLE_SID的作用就是设置一个 Oracle 环境窗口，通过这个环境变量来标示和命名系统进程，此后 Oracle 的活动可以由此展开。

继续前面的脚本，在创建和启动了实例之后，Oracle开始调用eygle.sql脚本，我们将这个脚本分开来介绍。这个脚本的最初部分是要求定义用户口令，然后使用定义的sys用户口令创建口令文件：

ACCEPT sysPassword CHAR PROMPT 'Enter new password for SYS: ' HIDE

ACCEPT systemPassword CHAR PROMPT 'Enter new password for SYSTEM: ' HIDE

ACCEPT sysmanPassword CHAR PROMPT 'Enter new password for SYSMAN: ' HIDE

ACCEPT dbsnmpPassword CHAR PROMPT 'Enter new password for DBSNMP: ' HIDE

host D:\Oracle\11.2.0\bin\orapwd.exe

file=D:\Oracle\11.2.0\database\PWDeygle.ora force=y

这里又引入了另一个工具orapwd，这个工具在Linux/UNIX上同样存在，当口令文件丢失或损坏之后，可以通过这个工具重建口令文件，这个工具的语法为：

D:\oracle\11.2.0\BIN>orapwd

Usage: orapwd file=<fname> entries=<users> force=<y/n> ignorecase=<y/n> nosysdba=<y/n>

file - name of password file (required),

password - password for SYS will be prompted if not specified at command line,

entries - maximum number of distinct DBA (optional),

force - whether to overwrite existing file (optional),

ignorecase - passwords are case-insensitive (optional),

nosysdba - whether to shut out the SYSDBA logon (optional Database Vault only).

There must be no spaces around the equal-to (=) character.

注意：force参数是Oracle 10g中增加的，ignorecase参数是Oracle 11g新增加的。

Oracle在启动过程中，会在$ORACLE_HOME/dbs（Windows下相应的目录则是$ORACLE_HOME\database）目录下查找口令文件，查找的顺序是首先检查 orapw<ORACLE_SID>文件，如果不存在则查找orapw文件，如果orapw文件也不存在，就会报出如下错误：

ORACLE instance started.

ORA-01990: error opening password file '/opt/oracle/product/9.2.0/dbs/orapw'

ORA-27037: unable to obtain file status

Linux Error: 2: No such file or directory

Additional information: 3

口令文件丢失或损坏后，通常可以通过如下命令重建口令文件：

[oracle@jumper dbs]$ orapwd file=orapwhsjf password=oracle entries=5

在数据库没有启动之前，数据库内建用户是无法通过数据库来验证身份的，此时口令文件的作用就体现了出来。口令文件中存放了具有sysdba/sysoper身份用户的用户名及口令，Oracle允许用户通过口令文件验证，在数据库未启动之前登录，从而启动实例进而加载并打开数据库；而如果没有口令文件，在数据库未启动之前就只能通过操作系统认证方式来启动实例。在Oracle DataGuard环境中，要求主数据库和备用数据库的口令文件SYS用户密码相同，这时候经常会用到使用orapwd工具重建口令文件的技能。

Oracle 通过一个初始化参数 remote_login_passwordfile 来限制口令文件的使用，通过这个参数可以设置用户登录时是否检查口令文件，以及有多少个数据库可以使用口令文件。这个参数有3个选项：EXCLUSIVE、SHARED和NONE。

当remote_login_passwordfile设置为NONE时，远程用户将不能通过sysdba/sysoper身份登录数据库：

SQL> show parameter pass

------------------------- ----------- ------------------------------

remote_login_passwordfile string　NONE

此时通过远程连接会收到如下错误：

SQL> connect sys/oracle@hsjf as sysdba

ERROR:ORA-01017: invalid username/password; logon denied

此处实际上是无法通过口令文件验证。

缺省的remote_login_passwordfile参数设置为exclusive，支持远程sysdba的登录操作：

SQL> alter system set remote_login_passwordfile=exclusive scope=spfile;

这个参数是静态参数，修改后重起数据库才能生效。当 remote_login_passwordfile 参数设置为exclusive时可以通过远程以sysdba身份登录数据库：

E:\Oracle\ora92\bin>sqlplus /nolog

SQL*Plus: Release 9.2.0.4.0 -

Production on星期四 4月 15 09:47:11 2004

SQL> connect sys/oracle@hsjf as sysdba

当remote_login_passwordfile参数设置为shared时，则多个数据库可以共享一个口令文件，但是此时口令文件中只能存储SYS用户的口令，此时其他用户不能被授予sysdba身份：

SQL> select * from v$pwfile_users;

USERNAME SYSDB SYSOP

--------- ----- -----

SQL> grant sysdba to eygle;

grant sysdba to eygle

ORA-01994: GRANT failed: cannot add users to public password file

SQL> show parameter password

------------------------------ ------ ------------------------------

remote_login_passwordfile　string SHARED

此时的口令文件中是不能添加用户的。很多朋友的疑问在于：口令文件的缺省名称是orapw<ORACLE_SID>，怎么能够共享？

前面已经提到，Oracle数据库在启动时，首先查找的是orapw<ORACLE_SID>的口令文件，如果该文件不存在，则开始查找 orapw 的口令文件；如果同一主机上的多个数据库同时使用orapw文件，则口令文件就可以共享（当然通过其他方式，如符号链接等也可以实现共享）。

来看一下测试，首先移动缺省的口令文件：

[oracle@jumper dbs]$ mv orapweygle orapweygle.b

此时启动数据库会出现如下错误：

ORACLE instance started.

ORA-01990: error opening password file '/opt/oracle/product/9.2.0/dbs/orapw'

ORA-27037: unable to obtain file status

Linux Error: 2: No such file or directory

Additional information: 3

拷贝一个orapw口令文件，这时候再启动数据库就不会出现这个错误：

SQL> ! cp orapweygle.b orapw

ORACLE instance started.

SQL> show parameter password

------------------------------ ----------- ------------------------------

remote_login_passwordfile　string　SHARED

那么你可能会有这样的疑问：多个 Exclusive 的数据库是否可以共享一个口令文件（orapw）呢？继续这个测试，首先查看一下口令文件的内容，注意这里仅记录着INTERNAL/SYS的口令：

[oracle@jumper dbs]$ strings orapw

ORACLE Remote Password file

当REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE时：

SQL> alter system set remote_login_passwordfile=exclusive scope=spfile;

ORACLE instance started.

SQL> ! strings orapw

ORACLE Remote Password file

注意：这里以EXCLUSIVE方式启动以后，实例名称信息被写入口令文件。

此时，如果有其他实例以 Exclusive 模式启动，仍然可以使用这个口令文件，口令文件中的实例名称同时被改写，也就是说，数据库只在启动过程中才读取口令文件，数据库运行过程中并不锁定该文件，类似于PFILE/SPFILE文件。

进一步，如果对其他用户授予SYSDBA的身份：

SQL> select * from v$pwfile_users;

USERNAME　SYSDB　SYSOP

----------------- --------- --------

SQL> grant sysdba to eygle;

SQL> select * from v$pwfile_users;

USERNAME　SYSDB　SYSOP

---------- ------------ --------

EYGLE　TRUE　FALSE

SQL> ! strings orapw

]\[Z ORACLE Remote Password file

注意此时增加的 SYSDBA 用户，其相关信息可以被写入到口令文件，一旦口令文件中增加了其他SYSDBA用户，此文件就不再能够被其他Exclusive的实例共享。

在Oracle 12c中，由于许多新特性的引入，口令文件也发生了许多变化。可以从帮助说明中看到这些改变。在以下帮助中，可以看到较 Oracle 11g 增加的选项包括 asm、extended、sysbackup、sysdg 等。

Usage: orapwd file=<fname> entries=<users> force=<y/n> ignorecase=<y/n>

asm=<y/n> dbuniquename=<dbname> extended=<y/n> sysbackup=<y/n> sysdg=<y/n>

file - name of password file (required),

password - password for SYS will be prompted if not specified at command line,

entries - maximum number of distinct DBA (optional),

force - whether to overwrite existing file (optional),

ignorecase - passwords are case-insensitive (optional),

--asm参数表示自12c开始，口令文件也可以存储在ASM存储中。

asm - indicates that the password to be stored in

Automatic Storage Management (ASM) disk group is an ASM password. (optional).

dbuniquename - unique database name used to identify database

password files residing in ASM diskgroup only.

Ignored when asm option is specified (optional),

--以下扩展部分，用于存储SYSBACKUP、SYSDB和SYSKM等系统权限

extended - use the extended format for SYSBACKUP, SYSDG, and

SYSKM support and for longer identifiers (optional),

sysbackup - create SYSBACKUP entry (optional and requires the the extended format),

sysbackuppwd - password for SYSBACKUP will be prompted if not specified at command line,

sysdg - create SYSDG entry (optional and requires the extended format),

sysdgpwd - password for SYSDG will be prompted if not specified at command line.

当创建口令文件时，可以指定SYSBACKUP，SYSDG参数，此时会在口令文件中增加相应的条目：

bash-4.1$ orapwd file=orapwenmoz entries=5 extended=y sysbackup=y sysdg=y

Enter password for SYS:

Enter password for SYSBACKUP:

Enter password for SYSDG:

bash-4.1$ strings orapwenmoz

ORACLE Remote Password file

在Oracle 12c中，除了之前的SYSDBA、SYSOPER特殊管理权限之外，现在又随之增加了SYSASM、SYSBACKUP、SYSDG、SYSKM等权限。当对用户授予相应的权限后，口令文件中就会增加相应的条目：

SQL> grant sysbackup to enmo;

SQL> select * from v$pwfile_users;

USERNAME　SYSDB　SYSOP　SYSAS　SYSBA　SYSDG　SYSKM　CON_ID

-------------- ------- ------- ------- ------- ------- --------- -------------

SYS　TRUE　TRUE　FALSE　FALSE　FALSE　FALSE　0

ENMO　FALSE　FALSE　FALSE　TRUE　FALSE　FALSE　0

通过定义 ASM 参数，现在口令文件也可以被存储在 ASM 中，这样做的好处是，即可以通过ASM保护和加强口令文件的管理，在RAC模式下，更可以使得多实例共享同一个口令文件，保证口令文件的一致性。

通过类似如下的命令可以将口令文件创建到ASM磁盘组中：

orapwd file='+oradg/ENMO/orapwdenmo' dbuniquename='enmo' asm=y

创建完成之后，还需要通过配置指定数据库在启动时调用该口令文件：

srvctl modify database -db enmo -pwfile +oradg/ENMO/orapwdenmo

通过如下命令可以检查配置，经过配置的口令文件在通过crs启动数据库时会被调用生效：

srvctl config database -d enmo

在输出中包含了关于口令文件配置的信息：

Password file: +oradg/ENMO/orapwdenmo

经过12c的增强，Oracle终于将大到数据文件，小到参数文件和口令文件都纳入了数据库的统一管理和维护之中。

继续来看eygle.sql的内容，接下来的脚本才是创建数据库中最关键的：

@D:\Oracle\admin\eygle_nopt\scripts\CreateDB.sql

@D:\Oracle\admin\eygle_nopt\scripts\CreateDBFiles.sql

@D:\Oracle\admin\eygle_nopt\scripts\CreateDBCatalog.sql

@D:\Oracle\admin\eygle_nopt\scripts\emRepository.sql

@D:\Oracle\admin\eygle_nopt\scripts\lockAccount.sql

@D:\Oracle\admin\eygle_nopt\scripts\postDBCreation.sql

第一个脚本是CreateDB.sql，其主要内容如下：

connect "SYS"/"&&sysPassword" as SYSDBA

spool D:\Oracle\admin\eygle\scripts\CreateDB.log append

startup nomount pfile="D:\Oracle\admin\eygle\scripts\init.ora";

CREATE DATABASE "eygle"

MAXINSTANCES 8 MAXLOGHISTORY 1 MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100

DATAFILE 'D:\Oracle\oradata\eygle\system01.dbf' SIZE 700M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED

EXTENT MANAGEMENT LOCAL

SYSAUX DATAFILE 'D:\Oracle\oradata\eygle\sysaux01.dbf' SIZE 600M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED

SMALLFILE DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE 'D:\Oracle\oradata\eygle\temp01.dbf' SIZE 20M REUSE AUTOEXTEND ON NEXT 640K MAXSIZE UNLIMITED

SMALLFILE UNDO TABLESPACE "UNDOTBS1" DATAFILE 'D:\Oracle\oradata\eygle\undotbs01.dbf' SIZE 200M REUSE AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED

CHARACTER SET ZHS16GBK

NATIONAL CHARACTER SET AL16UTF16

LOGFILE GROUP 1 ('D:\Oracle\oradata\eygle\redo01.log') SIZE 51200K,

GROUP 2 ('D:\Oracle\oradata\eygle\redo02.log') SIZE 51200K,

GROUP 3 ('D:\Oracle\oradata\eygle\redo03.log') SIZE 51200K

USER SYS IDENTIFIED BY "&&sysPassword" USER SYSTEM IDENTIFIED BY "&&systemPassword";

可以看到，这个文件的主要操作步骤如下：

（1）通过SYS连接；

（2）通过配置的参数文件init.ora启动实例；

（3）开始数据库创建。

注意：如果选择 OMF 方式管理文件，控制文件的名称在创建数据库之前是未知的，所以创建数据库之后才能得到名称加入参数文件中，一般这个文件会包含类似如下语句。

column ctl_files NEW_VALUE ctl_files;

select concat('control_files=''', concat(replace(value, ', ', ''','''), '''')) ctl_files from v$parameter where name ='control_files';

host "echo &ctl_files >>C:\oracle\admin\eygle\scripts\init.ora";

在启动实例后执行的创建数据库中，第一个语句就是：

CREATE DATABASE "eygle"

这是数据库最重要的开始，其中“eygle”就是数据库名称。

对于Oracle数据库来说，db_name代表数据库的名称；而instance_name代表实例的名称， instance_name通过参数文件即可修改，而db_name则不然，我们看一下Oracle对于数据库名称的定义：db_name必须是一个不超过8个字符的文本串。在数据库创建过程中，db_name被记录在数据文件，日志文件和控制文件中。如果数据库实例启动过程中参数文件中的db_name和控制文件中的数据库名称不一致，则数据库不能启动。

通过以上定义可以看到，db_name是最具有稳定意义的参数，在数据文件、日志文件和控制文件中都会记录数据库的名称，这个名称完全可以不同于 instance_name。又由于 db_name具有存储的稳定性，所以不能简单的随意更改。

以下的测试数据库拥有相同的db_name和instance_name：

[oracle@jumper oracle]$ cd $ORACLE_HOME/dbs

[oracle@jumper dbs]$ grep name initeygle.ora

*.instance_name='eygle'

我们创建一个新的pfile为julia这个新的实例使用：

[oracle@jumper oracle]$ cd $ORACLE_HOME/dbs

[oracle@jumper dbs]$ cp initeygle.ora initjulia.ora

修改这个文件更改instance_name参数：

[oracle@jumper dbs]$ grep name initjulia.ora

*.instance_name='julia'

然后我们启动实例名称为julia的instance：

[oracle@jumper dbs]$ export ORACLE_SID=julia

[oracle@jumper dbs]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Tue Jul 25 14:04:15 2006

Connected to an idle instance.

ORACLE instance started.

ORA-01102: cannot mount database in EXCLUSIVE mode

注意，此时试图加载数据库时出现错误，因为当前数据库被另外一个实例（eygle instance）加载。在非并行模式（OPS/RAC）下，一个数据库同时只能被一个实例加载。此时已经启动了两个数据库实例，从后台进程可以看出：

[oracle@jumper dbs]$ ps -ef|grep ora_pmon

oracle　27321　1 0 Jul14 ?　00:00:00 ora_pmon_eygle

oracle　15445　1 0 14:04 ?　00:00:00 ora_pmon_julia

关闭eygle这个数据库实例后，就可以通过实例julia加载并打开db_name=eygle的数据库了：

[oracle@jumper dbs]$ export ORACLE_SID=julia

[oracle@jumper dbs]$ sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.4.0 - Production on Tue Jul 25 14:05:06 2006

SQL> alter database mount;

alter database mount

ORA-01990: error opening password file '/opt/oracle/product/9.2.0/dbs/orapw'

ORA-27037: unable to obtain file status

SQL> alter database open;

SQL> select name from v$datafile;

----------------------------------------------------------------------------

/opt/oracle/oradata/eygle/system01.dbf

/opt/oracle/oradata/eygle/undotbs01.dbf

/opt/oracle/oradata/eygle/users01.dbf

/opt/oracle/oradata/eygle/eygle01.dbf

新的实例具有独立的instance_name和db_name参数设置：

SQL> ! ps -ef|grep ora_pmon

oracle　15445　1 0 14:04 ?　00:00:00 ora_pmon_julia

SQL> show parameter instance_name

------------------------------- --------------- ------------------------------

instance_name　string　julia

SQL> show parameter db_name

------------------------------- --------------- ------------------------------

db_name　string　eygle

如果参数文件中的 db_name 和控制文件中的 db_name 不一致，那么会出现什么错误？我们修改参数文件中的db_name参数：

[oracle@jumper dbs]$ grep name initjulia.ora

*.instance_name='julia'

在启动过程中，我们看到，在mount阶段，数据库会对参数文件和控制文件进行比较，如果两者记录的db_name不一致，则数据库无法启动：

SQL> startup nomount;

ORACLE instance started.

SQL> alter database mount;

alter database mount

ORA-01103: database name 'EYGLE' in controlfile is not 'JULIA'

关于 db_name在文件头上的存储，可以通过很多方式来读取，以下通过Oracle 9i中随软件提供的BBED可以最为直观地观察和理解（这一工具在Windows平台上，Oracle 9i之后不再提供）：

D:\oracle\9.2.0\bin>bbed

BBED: Release 2.0.0.0.0 - Limited Production on星期二 8月 31 22:23:27 2010

************* !!! For Oracle Internal Use only !!! ***************

BBED> set filename 'D:\oracle\oradata\EYGLEE\DATAFILE\O1_MF_SYSTEM_60VQT1WW_.DBF'

FILENAME　D:\oracle\oradata\EYGLEE\DATAFILE\O1_MF_SYSTEM_60VQT1WW_.DBF

BBED> set blocksize　8192

进行了如上设置之后，我们可以检查文件头的结构信息，KCVFH是文件头信息的结构体：

struct kcvfh, 360 bytes　@0

struct kcvfhbfh, 20 bytes　@0

ub1 type_kcbh　@0　0x0b

ub1 frmt_kcbh　@1　0xa2

ub1 spare1_kcbh　@2　0x00

ub1 spare2_kcbh　@3　0x00

ub4 rdba_kcbh　@4　0x00400001

ub4 bas_kcbh　@8　0x00000000

ub2 wrp_kcbh　@12　0x0000

ub1 seq_kcbh　@14　0x01

ub1 flg_kcbh　@15　0x04 (KCBHFCKV)

ub2 chkval_kcbh　@16　0xa837

ub2 spare3_kcbh　@18　0x0000

struct kcvfhhdr, 76 bytes　@20

ub4 kccfhswv　@20　0x00000000

ub4 kccfhcvn　@24　0x0b200000

ub4 kccfhdbi　@28　0xea51005a

text kccfhdbn[0]　@32　E

text kccfhdbn[1]　@33　Y

text kccfhdbn[2]　@34　G

text kccfhdbn[3]　@35　L

text kccfhdbn[4]　@36　E

text kccfhdbn[5]　@37　E

text kccfhdbn[6]　@38

text kccfhdbn[7]　@39

ub4 kccfhcsq　@40　0x0000064a

ub4 kccfhfsz　@44　0x00015400

s_blkz kccfhbsz　@48　0x00

在以上输出中，kccfhdbn就是db_name的保留空间，共保留了8位，也正因为如此，数据库的db_name不能超过8个字符。又因为每个文件头上的实体存储，修改db_name的动作会较为复杂，一个名为NID的小工具可以用来更改数据库名称：

DBNEWID: Release 11.2.0.2.0 - Production on星期日 1月 23 19:52:01 2011

关键字　说明　(默认值)

----------------------------------------------------

TARGET　用户名/口令　(无)

DBNAME　新的数据库名　(无)

LOGFILE　输出日志　(无)

REVERT　还原失败的更改　否

SETNAME　仅设置新的数据库名　否

APPEND　附加至输出日志　否

HELP　显示这些消息　否

最后总结一下，一个实例（instance_name）可以mount并打开任何数据库（db_name），但是同一时间一个实例只能打开一个数据库；一个数据库（db_name）同一时间可以为任一实例（instance_name）所打开，但是在非RAC情况下，同时只能被同一个实例所打开。

在 CREATE DATABASE的过程中，Oracle会调用$ORACLE_HOME/rdbms/admin/sql.bsq脚本，用于创建数据字典，这是非常重要的一个脚本，其中存储了数据字典的创建语句及注释说明，当我们对某些数据字典存在兴趣时，可以通过检查这个文件得到更为详细的信息。

在Oracle 11g之前，sql.bsq脚本包含了所有的SQL语句；自Oracle 11g开始，这个文件被拆分为多个.bsq文件，sql.bsq文件中描述了拆分后的文件调用：

rem !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! IMPORTANT !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

rem Whenever new column is created to store internal, user or kernel column

rem number, be sure to update the structure adtDT in atb.c so that those

rem columns will be updated properly during drop column.

rem !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

拆分后的基础SQL更加清晰，如dcore.bsq包含了最为核心的字典创建语句，对于控制数据库启动的bootstrap$表，其创建语句就可以从这个文件中找到：

create table bootstrap$

( line#　number not null,　/* statement order id */

obj#　number not null,　/* object number */

sql_text　varchar2("M_VCSZ") not null)　/* statement */

storage (initial 50K)　/* to avoid space management during IOR I */

//　/* "//" required for bootstrap */

提示：sql.bsq及其相关文件值得每个研究Oracle数据的人，认真去阅读理解。

sql.bsq文件的位置受到一个隐含的初始化参数（_init_sql_file）的控制：

SQL> @GetParDescrb.sql

Enter value for par: init_sql

NAME　VALUE　DESCRIB

--------------- ------------------ -----------------------------------------------

_init_sql_file ?/rdbms/admin/sql.bsq File containing SQL statements to execute upon database creation

如果在数据库的创建过程中，Oracle无法找到sql.bsq文件，则数据库创建将会出错。可以测试一下移除sql.bsq文件，看一下数据库创建过程：

SQL> startup nomount;

ORACLE instance started.

CREATE DATABASE eygle

ORA-01092: ORACLE instance terminated. Disconnection forced

此时，警告日志（alert_<oracle_sid>.log）中会记录如下信息：

Fri Aug 18 15:45:49 2006

Errors in file /opt/oracle/admin/eygle/udump/eygle_ora_3632.trc:

ORA-01501: CREATE DATABASE failed

ORA-01526: error in opening file '?/rdbms/admin/sql.bsq'

ORA-07391: sftopn: fopen error, unable to open text file.

Error 1526 happened during db open, shutting down database

USER: terminating instance due to error 1526

这就是sql.bsq文件在数据库创建过程中的作用。知道了这个内容之后，我们甚至可以通过手工修改 sql.bsq 文件来更改数据库字典对象参数，从而实现特殊要求数据库的创建或测试自定义库，也可以通过修改_init_sql_file参数来重定位sql.bsq文件的位置（但是通常这些是不建议变更的）。

sql.bsq文件中包含的数据库核心信息非常重要，在很多时候，这个文件可以帮助我们解答很多技术疑惑。

再来看一看CreateDBFiles.sql文件：

connect "SYS"/"&&sysPassword" as SYSDBA

spool D:\Oracle\admin\eygle\scripts\CreateDBFiles.log append

CREATE SMALLFILE TABLESPACE "USERS" LOGGING DATAFILE 'D:\Oracle\oradata\eygle\users01. dbf' SIZE 5M REUSE AUTOEXTEND ON NEXT 1280K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

ALTER DATABASE DEFAULT TABLESPACE "USERS";

这个过程向数据库中创建了USERS表空间，并将该表空间设置为系统缺省的数据表空间，注意最后一句：

ALTER DATABASE DEFAULT TABLESPACE "USERS";

这是Oracle 10g之后增加的新特性，在Oracle 10g之前，如果创建用户时不指定缺省的数据表空间，那么用户的缺省表空间会被指向系统表空间（SYSTEM 表空间），现在增加了数据库缺省数据表空间后，创建用户的缺省数据表空间会被指向这里：

SQL> create user julia identified by eygle;

SQL> select username,default_tablespace from dba_users

2 where username='JULIA';

USERNAME　DEFAULT_TABLESPACE

------------------------------ ------------------------------

作为一个数据库属性，这个信息也可以从字典表props$中查询得到：

SQL> select name,value$ from props$

2 where name='DEFAULT_PERMANENT_TABLESPACE';

------------------------------ ------------------

DEFAULT_PERMANENT_TABLESPACE　USERS

继续前面的讨论，接下来Oracle通过CreateDBCatalog.sql脚本创建数据字典，catalog等脚本被依次调用，创建DBA_* 等一系列字典视图：

connect "SYS"/"&&sysPassword" as SYSDBA

spool D:\Oracle\admin\eygle\scripts\CreateDBCatalog.log append

@D:\Oracle\11.2.0\rdbms\admin\catalog.sql;

@D:\Oracle\11.2.0\rdbms\admin\catblock.sql;

@D:\Oracle\11.2.0\rdbms\admin\catproc.sql;

@D:\Oracle\11.2.0\rdbms\admin\catoctk.sql;

@D:\Oracle\11.2.0\rdbms\admin\owminst.plb;

connect "SYSTEM"/"&&systemPassword"

@D:\Oracle\11.2.0\sqlplus\admin\pupbld.sql;

connect "SYSTEM"/"&&systemPassword"

spool D:\Oracle\admin\eygle\scripts\sqlPlusHelp.log append

@D:\Oracle\11.2.0\sqlplus\admin\help\hlpbld.sql helpus.sql;

emRepository.sql文件是用于创建EM档案库的：

connect "SYS"/"&&sysPassword" as SYSDBA

spool D:\Oracle\admin\eygle\scripts\emRepository.log append

@D:\Oracle\11.2.0\sysman\admin\emdrep\sql\emreposcre D:\Oracle\11.2.0 SYSMAN &&sysmanPassword TEMP ON;

WHENEVER SQLERROR CONTINUE;

接下来是用户管理脚本，lockAccount.sql用于锁定那些暂时用不到的缺省数据库用户，以后用户可以在需要时主动解锁，但是为了安全，Oracle现在需要锁定这些用户：

spool D:\Oracle\admin\eygle\scripts\lockAccount.log append

FOR item IN ( SELECT USERNAME FROM DBA_USERS WHERE ACCOUNT_STATUS IN ('OPEN', 'LOCKED',

'EXPIRED') AND USERNAME NOT IN ( 'SYS','SYSTEM') )

dbms_output.put_line('Locking and Expiring: ' || item.USERNAME);

execute immediate 'alter user ' ||

sys.dbms_assert.enquote_name(

sys.dbms_assert.schema_name(

item.USERNAME),false) || ' password expire account lock' ;

注意：以上的SQL中，FOR循环锁定语句是非常常用的PL/SQL代码，建议DBA们能够熟练编写和使用。

postDBCreation.sql脚本用于完成数据库创建后的一些收尾工作，如创建SPFILE文件、配置EM资料库等：

connect "SYS"/"&&sysPassword" as SYSDBA

spool D:\Oracle\admin\eygle\scripts\postDBCreation.log append

@D:\Oracle\11.2.0\rdbms\admin\catbundle.sql psu apply;

select 'utl_recomp_begin: ' || to_char(sysdate, 'HH:MI:SS') from dual;

execute utl_recomp.recomp_serial();

select 'utl_recomp_end: ' || to_char(sysdate, 'HH:MI:SS') from dual;

connect "SYS"/"&&sysPassword" as SYSDBA

create spfile='D:\Oracle\11.2.0\database\spfileeygle.ora' FROM

pfile='D:\Oracle\admin\ eygle\scripts\init.ora';

connect "SYS"/"&&sysPassword" as SYSDBA

host D:\Oracle\11.2.0\bin\emca.bat -config dbcontrol db -silent -DB_UNIQUE_NAME eygle -PORT 1521 -EM_HOME D:\Oracle\11.2.0 -LISTENER LISTENER -SERVICE_NAME eygle -SID eygle -ORACLE_HOME D:\Oracle\11.2.0 -HOST oracle-vm -LISTENER_OH D:\Oracle\11.2.0 -LOG_FILE D:\Oracle\admin\eygle\scripts\emConfig.log;

完成这些脚本，一个自定制的数据库就基本创建完成了。

在数据库创建中所提到的“预防性指导报告”就包括空间指导报告，这一定时任务在很多客户系统中带来了极大的麻烦。需要提醒大家注意的是：当Oracle 数据库中引入一个新特性时，可能会因为不完善的缺陷而带来麻烦，所以关注新特性，当发现问题时及时处理屏蔽是 DBA 的一个重要职责。

在以下客户的SAP系统中，某个高负载的时段，数据库就遇到了DBMS_SCHEDULER任务的一个Bug，其数据库版本为10.2.0.2。在SQL Ordered By Elapsed Time的采样中，Top 6都是DBMS_SCHEDULER调度的任务，而且耗时显著，如图1-29所示。

处在第一位的，是 auto_space_advisor_job_proc过程调用，CPU Time消耗高达 4226秒：

call dbms_space.auto_space_advisor_job_proc ( )

执行花费了大量的时间，3000多秒，进而执行的SQL：

insert into wri$_adv_objspace_trend_data select timepoint, space_usage, space_alloc, quality from table(dbms_space.object_growth_trend(:1, :2, :3, :4, NULL, NULL, NULL, 'FALSE', :5, 'FALSE'))

也花费了2514秒的时间，这显然是不正常的。在正常情况下，单独跟踪一下SQL*Plus中手工执行这个过程，可以获得这个SQL的执行统计信息，跟踪过程可能如下：

SQL> alter session set events '10046 trace name context forever,level 12';

SQL> call dbms_space.auto_space_advisor_job_proc ( )

SQL> alter session set events '10046 trace name context off';

格式化跟踪文件，获得如图1-30所示的输出。

可以发现，这个 Insert仍然消耗了389秒的时间，逻辑读 429 297，性能是存在问题的。在Metalink上存在如下一个Bug：

Bug 5376783: DBMS_SPACE.OBJECT_GROWTH_TREND CALL TAKES A LOT OF DISK READS

这个Bug在DBMS_SPACE.OBJECT_GROWTH_TREND进行空间分析时被触发，根本原因在于内部算法在执行空间检查时，耗费了大量的评估IO成本，导致了大量的IO资源使用。

临时的处理办法是，暂时关闭这个自动任务：

execute dbms_scheduler.disable('AUTO_SPACE_ADVISOR_JOB');

这个Bug在10.2.0.2之后的版本中被修正。

既然Oracle的缺省定时任务可能会带来如此多的问题，我们就很有必要去关注一下系统有哪些缺省的任务，执行情况如何。以下是一个10.2.0.5版本的数据库中一些自动任务的调度设置情况：

SQL> select job_name,state,enabled,last_start_date from dba_scheduler_jobs;

JOB_NAME　STATE　ENABL　LAST_START_DATE

-------------------------- ------------- ------- -----------------------------------

AUTO_SPACE_ADVISOR_JOB　SCHEDULED　TRUE　07-AUG-10 06.00.03.792886 AM +08:00

GATHER_STATS_JOB　SCHEDULED　TRUE　07-AUG-10 06.00.03.783957 AM +08:00

FGR$AUTOPURGE_JOB　DISABLED　FALSE

PURGE_LOG　SCHEDULED　TRUE　07-AUG-10 03.00.00.353023 AM PRC

MGMT_STATS_CONFIG_JOB　SCHEDULED　TRUE　01-AUG-10 01.01.01.822354 AM +08:00

MGMT_CONFIG_JOB　SCHEDULED　TRUE　07-AUG-10 06.00.03.767320 AM +08:00

在以上的调度任务中，GATHER_STATS_JOB是Oracle 10g开始引入的自动统计信息收集的任务，该任务缺省的调度是，工作日每晚22:00至凌晨6:00进行分析，周末全天进行分析。在以下输出中，我们可以看到任务无法完成STOP的情况。

SQL> SELECT log_id, job_name, status,

2　TO_CHAR(ACTUAL_START_DATE,'DD-MON-YYYY HH24:MI') start_date,TO_CHAR (log_date, 'DD-MON-YYYY HH24:MI') log_date

3　FROM dba_scheduler_job_run_details

4　WHERE job_name = 'GATHER_STATS_JOB' order by 4;

LOG_ID　JOB_NAME　STATUS　START_DATE　LOG_DATE

-------- ------------------- ------------- --------------------- --------------------

1480　GATHER_STATS_JOB　SUCCEEDED　02-AUG-2010 22:00　03-AUG-2010 00:58

1561 GATHER_STATS_JOB　STOPPED　03-AUG-2010 22:00　04-AUG-2010 06:00

1640 GATHER_STATS_JO　BSUCCEEDED　04-AUG-2010 22:00　05-AUG-2010 05:36

1680 GATHER_STATS_JOB　SUCCEEDED　05-AUG-2010 22:00　05-AUG-2010 22:25

1741 GATHER_STATS_JOB　SUCCEEDED　06-AUG-2010 22:00　06-AUG-2010 22:27

1800 GATHER_STATS_JOB　SUCCEEDED　07-AUG-2010 06:00　07-AUG-2010 06:02

384 GATHER_STATS_JOB　STOPPED　07-JUL-2010 22:00　08-JUL-2010 06:00

463 GATHER_STATS_JOB　SUCCEEDED　08-JUL-2010 22:00　09-JUL-2010 05:06

503 GATHER_STATS_JOB　SUCCEEDED　09-JUL-2010 22:00　09-JUL-2010 22:05

544 GATHER_STATS_JOB　SUCCEEDED　10-JUL-2010 06:00　10-JUL-2010 06:02

589 GATHER_STATS_JOB　SUCCEEDED　12-JUL-2010 22:00　12-JUL-2010 22:04

597 GATHER_STATS_JOB　SUCCEEDED　13-JUL-2010 22:00　13-JUL-2010 22:03

在一些大型数据库中，这个任务不一定能够有效执行，以下是某用户的数据库环境，输出显示，多日数据库都因为ORA-04031错误未能完成统计信息收集采样：

SQL> SELECT LOG_DATE,RUN_DURATION,JOB_NAME,STATUS,ERROR#

2 FROM DBA_SCHEDULER_JOB_RUN_DETAILS

3 WHERE JOB_NAME='GATHER_STATS_JOB'

LOG_DATE　RUN_DURATION　JOB_NAME　STATUS　ERROR#

----------------------------------- ------------- ----------------- ---------- ------

26-MAY-10 10.00.09.290291　PM +08:00 +000 00:00:05　GATHER_STATS_JOB　FAILED　22303

25-MAY-10 10.00.08.973684　PM +08:00 +000 00:00:06　GATHER_STATS_JOB　FAILED　4031

24-MAY-10 10.00.22.977244　PM +08:00 +000 00:00:18　GATHER_STATS_JOB　FAILED　4031

22-MAY-10 06.00.16.950362　AM +08:00 +000 00:00:13　GATHER_STATS_JOB　FAILED　4031

21-MAY-10 10.00.49.653788　PM +08:00 +000 00:00:47　GATHER_STATS_JOB　FAILED　4031

20-MAY-10 10.00.14.028432　PM +08:00 +000 00:00:11　GATHER_STATS_JOB　FAILED　4031

19-MAY-10 10.00.20.828607　PM +08:00 +000 00:00:18　GATHER_STATS_JOB　FAILED　4031

19-MAY-10 05.54.27.871444　AM +08:00 +000 07:54:25　GATHER_STATS_JOB　SUCCEEDED　0

18-MAY-10 05.36.01.494920　AM +08:00 +000 07:35:59　GATHER_STATS_JOB　SUCCEEDED　0

15-MAY-10 07.06.05.793257　AM +08:00 +000 01:06:01　GATHER_STATS_JOB　SUCCEEDED　0

15-MAY-10 03.56.50.898303　AM +08:00 +000 05:56:48　GATHER_STATS_JOB　SUCCEEDED　0

在 GATHER_STATS_JOB 任务不能够有效地执行时，我们必须及时地介入进行手工处理（如自定义任务，跳过那些不重要的大表，或者选择在业务峰值以外的时间，手工执行统计信息收集），不及时的统计信息可能使数据库产生错误的执行计划。

正常的AUTO_SPACE_ADVISOR_JOB调度可能应该具有类似以下输出的执行结果：

SQL> SELECT log_id, job_name, status,TO_CHAR(ACTUAL_START_DATE,'DD-MON-YYYY HH24:MI') start_date,

2　TO_CHAR (log_date, 'DD-MON-YYYY HH24:MI') log_date

3　FROM dba_scheduler_job_run_details

4　WHERE job_name = 'AUTO_SPACE_ADVISOR_JOB' order by 4;

LOG_ID　JOB_NAMESTATUS　START_DATE　LOG_DATE

------- ------------------------- ------------ ------------------- -----------------

1460　AUTO_SPACE_ADVISOR_JOB SUCCEEDED　02-AUG-2010 22:00　02-AUG-2010 22:16

1520　AUTO_SPACE_ADVISOR_JOB SUCCEEDED　03-AUG-2010 22:00　03-AUG-2010 23:18

1600　AUTO_SPACE_ADVISOR_JOB　SUCCEEDED　04-AUG-2010 22:00　04-AUG-2010 22:19

1681　AUTO_SPACE_ADVISOR_JOB　SUCCEEDED　05-AUG-2010 22:00　05-AUG-2010 22:28

1740　AUTO_SPACE_ADVISOR_JOB　SUCCEEDED　06-AUG-2010 22:00　06-AUG-2010 22:17

对于生产环境，需要详细了解这些定时任务，并将检查工作加入DBA的工作任务列表。

某客户的ORACLE两节点集群数据库，为保证在RAC环境备份归档日志的方便性，归档日志除分别在两节点进行本地归档外，在进行本地归档的同时，通过配置 log_archive_dest_2向另一节点传送归档日志，在通过 orapwd 工具在节点一更改 SYS 密码后，造成归档 log_archive_dest_2向另一节点无法传送归档日志。

从数据库中查询到相关错误信息如下：

Error 1017 received logging on to the standby

------------------------------------------------------------

Check that the primary and standby are using a password file

and remote_login_passwordfile is set to SHARED or EXCLUSIVE,

and that the SYS password is same in the password files.

returning error ORA-16191

------------------------------------------------------------

Errors in file /oracle/app/diag/rdbms/orac/orac1/trace/orac1_arc1_1208404.trc:

ORA-16191: 主日志传送客户机没有登录到备用数据库

PING[ARC1]: Heartbeat failed to connect to standby 'orac2'. Error is 16191.

DEST_NAME　ERROR　STATUS

---------------------- --------------------------------------- -----------

LOG_ARCHIVE_DEST_1　　VALID

LOG_ARCHIVE_DEST_2　ORA-16191: Primary log shipping

client not logged on standby　ERROR

LOG_ARCHIVE_DEST_3　INACTIVE

LOG_ARCHIVE_DEST_4　INACTIVE

LOG_ARCHIVE_DEST_5　INACTIVE

LOG_ARCHIVE_DEST_6　INACTIVE

LOG_ARCHIVE_DEST_7　INACTIVE

LOG_ARCHIVE_DEST_8　INACTIVE

LOG_ARCHIVE_DEST_9　INACTIVE

LOG_ARCHIVE_DEST_10　INACTIVE

在Oracle RAC或DG环境中，出现ORA-16191错误，通常是由于两节点密码文件不一致或 remote_login_passwordfile 参数设置不当导致。而本次故障原因并非以上原因所致，客户经过口令文件的重建仍然无法解决问题，在经过分析后确认问题的原因为Oracle 11g的口令安全增强。

Oracle 11g中对于密码安全验证的增强（即Strong Authentification Framework），该增强由初始化参数SEC_CASE_SENSITIVE_LOGON决定，当该参数设置为true时，启用Strong Authentification Framework，false则关闭该增强验证。

当启用强口令认证时，Oracle区分密码大小写，在创建口令文件时，即便口令相同也会在两节点产生不同的HASH值，需要指定ignorecase参数强制忽略大小写才能够保证DG的正常认证（或者在数据库级取消大小写强口令验证）。

在Oracle数据库两节点分别执行如下命令。

orapwd file=orapworac1 password=oracle1 ignorecase=y force=y

orapwd file=orapworac2 password=oracle1 ignorecase=y force=y

分别查看两节点归档路径信息，log_archive_dest_2状态即恢复正常。

DEST_NAME　STATUS　ERROR

-------------------------------- ----------------- ------

LOG_ARCHIVE_DEST_1　　VALID

LOG_ARCHIVE_DEST_2　　VALID

LOG_ARCHIVE_DEST_3　　INACTIVE

LOG_ARCHIVE_DEST_4　　INACTIVE

LOG_ARCHIVE_DEST_5　　INACTIVE

LOG_ARCHIVE_DEST_6　　INACTIVE

LOG_ARCHIVE_DEST_7　　INACTIVE

LOG_ARCHIVE_DEST_8　　INACTIVE

LOG_ARCHIVE_DEST_9　　INACTIVE

LOG_ARCHIVE_DEST_10　　INACTIVE

在两节点通过多次手动触发日志切换，查看日志归档状态恢复正常，告警日志未再出现由于远程日志传送导致的相关错误信息。

Fri Feb 01 18:15:47 2013

RFS[7]: Archived Log: '/archivelog/rac2/2_83_802962309.dbf'

Fri Feb 01 18:16:17 2013

RFS[7]: Archived Log: '/archivelog/rac2/2_84_802962309.dbf'

Fri Feb 01 18:16:46 2013

RFS[7]: Archived Log: '/archivelog/rac2/2_85_802962309.dbf'

Fri Feb 01 18:16:48 2013

Thread 1 advanced to log sequence 98

Current log# 2 seq# 98 mem# 0: /dev/rlv_redo12

Fri Feb 01 18:17:03 2013

RFS[7]: Archived Log: '/archivelog/rac2/2_86_802962309.dbf'

RFS[7]: Archived Log: '/archivelog/rac2/2_87_802962309.dbf'

Fri Feb 01 18:17:14 2013

Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid

RFS[8]: Assigned to RFS process 1438620

RFS[8]: Identified database type as 'primary cross instance archival'

Fri Feb 01 18:17:14 2013

RFS[7]: Archived Log: '/archivelog/rac2/2_88_802962309.dbf'

RFS[8]: Archived Log: '/archivelog/rac2/2_88_802962309.dbf'

Fri Feb 01 18:17:15 2013

Thread 1 advanced to log sequence 99

Current log# 5 seq# 99 mem# 0: /dev/rlv_redo13

Fri Feb 01 18:17:27 2013

RFS[7]: Archived Log: '/archivelog/rac2/2_89_802962309.dbf'

这个案例给我们的经验是：即便是一个简单的口令文件修改操作，也要考虑到备库等集联因素，避免因为考虑不周导致的数据库故障。

图书在版编目（CIP）数据

深入解析Oracle：数据库的初始化/盖国强著.--北京：人民邮电出版社，2013.10

ISBN　978-7-115-32903-5

Ⅰ.①深…　Ⅱ.①盖…　Ⅲ.①关系数据库系统　Ⅳ.①TP311.138

中国版本图书馆CIP数据核字（2013）第191064号

本书围绕“数据库的初始化”这个主题展开，详细介绍了数据库的创建、使用模板创建数据库、插接式数据库、数据库的启动和关闭、参数及参数文件、控制文件与数据库初始化、控制文件与启动校验、数据字典等内容，不但兼顾了Oracle 10g、11g版本的功能，还为读者揭秘了刚刚发布的Oracle 12c的最新技术。

本书给出了大量取自实际工作现场的实例，在分析实例的过程中，兼顾深度与广度，不仅对实际问题的现象、产生原因和相关原理进行了深入浅出的讲解，更主要的是，结合实际应用环境，提供了一系列解决问题的思路和方法，包括详细的操作步骤，具有很强的实战性和可操作性，适用于具备一定数据库基础、打算深入学习Oracle 技术的数据库从业人员，尤其适用于入门、进阶以及希望深入研究 Oracle技术的数据库管理人员。

深入解析Oracle：数据库的初始化

图书目录:

详情

图书摘要

相关图书

相关文章

相关课程