这篇文档汇总了与对象和类型相关的知识。

Firewall安全手册更多的内容偏重于图形化工具的配置。

Oracle的LABEL安全选件从9i就有，不过一直没有研究过。

虽然VM用户手册中没有找到我感兴趣的TroubleShooting的内容，但是关于详细配置的内容确实不少。

前不久看完安全的管理员手册，发现Firewall的功能确实是其他产品难以代替的。

和其他备份管理工具比较类似，绝大部分工作都是通过图形化界面配置。

周三的ACOUG大会上得到了Tom签名的这本书。

VM的安装文档解决不了问题，看看VM的用户手册有没有这方面的内容。

其实文章很短，如果有时间半天就能看完。

这篇文档和PL/SQL PACKAGE AND TYPES REFERENCE一样，都是大部头的文档。

最近手头的事情太多，导致文档虽然看完了，还没有动手进行过测试。

还记得Oracle一推出VM时，我写了一篇文章，不过之后一直没有研究VM。一转眼VM的版本已经到了3.0。

国内越来越多客户开始注重安全相关的内容了，使得原本一些很少使用的技术，现在开始变得十分的流行。

当第一次使用NETBACKUP配置RMAN备份到带宽时就考虑过，Oracle为什么没有直接备份到带宽的功能，非得需要借助到其他的软件，直到Oracle推出了SecureBackup，解决了这个问题。

这篇文档看完了，不过其中内容学到不到一成。

公司今后很多业务会和安全性有关，Oracle推出了Oracle Database Firewall，对这个产品目前还缺乏最基本的了解，先看看文档扫扫盲。

这篇文档篇幅并不算很长，如果想对Oracle开发或优化方面了解更深入，建议还是读一下这篇文档。

目前Oracle的文档已经看过不少了，而安全相关的内容是Oracle整体架构中不太熟悉的部分，最近一些项目会与安全方面有关，现在正好抽时间补一补。

最近准备拣拣TIMESTEN的东西。

一直不太清楚DATA CARTRIDGE应该如何翻译，查了半天觉得可能翻译成资料库相对来靠点谱，在拿不准的情况下，干脆就不翻译了。

全球支持手册看完了，这篇文档的内容虽然不少，但是对于大部分DBA而言，能够用到的内容只有其中一部分。

这篇文档包含了Oracle官方提供的所有的包和TYPE的详细说明。

这篇XML数据库开发的文档看完了，不过对于XML的诸多特性还是了解有限。

刚看完内存数据库的内容介绍，趁热打铁抓紧时间看内存数据库的用户手册。

这篇文档只是简单的介绍了内存数据库的功能，性质有点像数据库的CONCEPT文档。

两个月前参加ACOUG的中韩数据库交流大会时，拿到了出版社的这本赠书。今天有时间翻了翻，准备抽时间研究一下。

这篇文档主要介绍内存数据库的相关内容。

Golden Gate的管理员手册看完了，可惜一直没有时间去测试。

用了一年的零碎时间看完了这本书。

虽然这篇文档名称叫做应用开发者手册，但是文档中很多内容都和DBA日程工作相关。

 查看全文

虽然文档的名称叫做流高级队列，但是看完后感觉和流的关系并非那么大。

 查看全文

这篇文档介绍了Oracle数据库如何支持不同国家、地区的字符集、日期和时区、货币符号等内容。

 查看全文

和Oracle数据库的安装文档相比，GOLDENGATE的安装文档篇幅较短。

 查看全文

这篇文档介绍了GOLDENGATE的安装和配置。

 查看全文

以前没有看过ASM的官方文档，正好这次看的11.2的，连同很多新特性就一起看了。

 查看全文

今年准备开始看Golden Gate相关的文档。

 查看全文

Oracle从9i就已经有XML DB的概念，不过由于我对XML本身不是很熟悉的原因，这方面的内容一直没有仔细研究过。

 查看全文

这篇文档介绍的安全相关的基本知识。

 查看全文

今天拿到了EYGLE译文，KAMUS和崔华审校的《海量数据库解决方案》一书。

 查看全文

流的文档基本上看完了，剩下就是多做测试了，而高级队列的文档一直没有看过。

 查看全文

这一篇介绍如何在应用程序中使用RULE。

 查看全文

文档这篇介绍了一个三源双向复制的案例。

 查看全文

这一篇描述了建立一个包含异构的流复制环境，不但有Oracle数据库之间的复制，还通过透明网关复制到SYBASE环境中。

 查看全文

描述了一个最基本的单表单向复制环境的建立。

 查看全文

以前还真没有发现专门介绍ASM的文档，刚刚看完CLUSTERWARE的文档，正好接着看ASM的。

 查看全文

这篇文档比较详细的介绍了CLUSTERWARE相关内容。

 查看全文

这篇介绍了单数据库配置捕获和应用的案例。

 查看全文

这篇文档介绍了流高级应用技术，如何利用流结构来定制复制环境。

 查看全文

上一篇介绍了用于监控和诊断问题的流相关的视图，而这篇介绍流配置出现问题后，应如何诊断问题。

 查看全文

文档介绍了流相关的视图。

 查看全文

这本书是ITPUB开发版几个版主（newkid、bq_wang、dingjun123、wabjtam123、lastwinner、〇〇、贾书民）的联手之作，应邀写篇书评。

 查看全文

这篇文档包含了一些不好归类的流管理、维护操作。

 查看全文

安全方面是数据库管理的一个重要方面，不过以前一直没有时间仔细研究这部分。

 查看全文

Real Application Testing这篇文档的篇幅虽然不长，但是其中的大部分内容都是新特性的内容。

 查看全文

文档在这一章中介绍了流规则的管理以及基于规则的转换。

 查看全文

文档在这一章描述应用进程的管理。

 查看全文

这篇文档描述流传播进程以及流复制依赖的队列的管理。

 查看全文

文档在这一章描述的是捕获进程的管理。

 查看全文

介绍流环境的配置过程。

 查看全文

这一篇文章描述流环境的高可用特性。

 查看全文

这一篇描述异构环境下的流复制。

 查看全文

 查看全文

标记（TAG）是流的重要辅助工具，利用TAG可以避免循环应用。

 查看全文

无论是高级复制还是流，只要存在两个以上的站点对相同的数据进行修改，就可能导致数据冲突的产生，这一篇介绍了流中的冲突解决方案。

 查看全文

上一篇介绍的主要是规则的概念，这一篇主要描述如何在流中使用规则。

文档这一章介绍了图形化的复制管理工具。

 查看全文

RAT是Real Application Testing的缩写，如果要翻译成中文，可以译为真正应用测试。RAT不但缩写和RAC比较像，中文翻译的拗口也和RAC有的拼，因此还是用简写RAT更方便一点。

 查看全文

网络配置是数据库管理员工作的一部分，而这部分以前一直没有完整的看过文档，现在通过这篇文档来补补课。

 查看全文

文档在这一章主要描述建立复制环境应该考虑和注意的地方。

 查看全文

流的灵活性一方面与捕获、传播和应用三层的结构有关，另一方面就是由于灵活的规则设置。

 查看全文

从10g就开始用Oracle的CLUSTERWARE了，不过CLUSTERWARE的官方文档还真没有仔细读过。

 查看全文

看完这篇文档，还是有了不少收获的。

 查看全文

文档在这一章介绍了冲突解决方案的概念。

 查看全文

文档描述了模板的概念和创建。

 查看全文

最近在重新看Oracle的高级复制文档，正好昨天建立了一个物化视图专用的索引贴，事情都赶到一块了。于是找出了以前针对这篇文档的翻译进行简单的修改后作为这篇读书笔记。

 查看全文

流的应用是事件的消费过程，这章主要描述和应用进程有关的概念。

 查看全文

这篇文档涵盖了RMAN的所有功能，如果对文档中所有的内容都很熟悉，那么RMAN或者说Oracle数据库的备份和恢复已经掌握的差不多了。

 查看全文

介绍RMAN工具的检查、管理、维护备份集的操作。

 查看全文

介绍查询RMAN的资料库的各种方法。

 查看全文

这篇文档描述RMAN CATALOG REPOSITORY的管理操作。

 查看全文

这章包含了RMAN的问题诊断以及故障解决方面的内容。

 查看全文

网络配置是数据库管理员工作的一部分，而这部分以前一直没有完整的看过文档，现在通过这篇文档来补补课。

 查看全文

上周末在ACOUG上分享的就是高可用的相关内容。

 查看全文

这篇介绍了如何对备份恢复操作调优。

 查看全文

描述如何通过RMAN的DUPLICATE命令创建STANDBY数据库。

 查看全文

文档在这一章描述了多主复制的概念和体系结构。

 查看全文

介绍RMAN的如何利用DUPLICATE命令创建DUPLICATE数据库。

 查看全文

DATA GUARD BROKEN提供了DATA GUARD的自动管理、配置和监控的功能。

 查看全文

描述数据库资源属性的监视和配置。

 查看全文

介绍在RMAN中如何执行表空间及时点恢复TSPITR。

 查看全文

这篇文章主要介绍RMAN的RESTORE和RECOVER操作。

 查看全文

这篇主要介绍如何DATA GUARD BROKER的命令行接口包含的各种命令以及对应的语法。

 查看全文

Oracle的高可用技术用了不少，各个特性的专门的文档也看了不少，不过还没有看过总体上描述高可用特性的。

 查看全文

看完文档后发现，基本上这篇文档就相当于11g的DataWarehouse手册。

 查看全文

这篇主要介绍如何利用DATA GUARD BROKER的命令行接口执行各种管理操作。

 查看全文

如果说高级复制侧重概念的描述，那么这本书就是高级复制的实践手册。

 查看全文

这本书是ITPUB的第二本书，我还参与了其他两篇文章的写作，这本书出版已经5年左右了，不知道什么原因当时没有看，直到今天收拾书柜才发现。

 查看全文

花了两年的时间，Tom的这本新书终于看完了。

 查看全文

虽然经常会用到LOB类型，但是对于LOB的理解并不是很深，准备深入研究一下LOB类型。

 查看全文

用了一个半月左右看完了升级手册，不过由于时间的关系，很多内容还没有动手测试。

 查看全文

花了一个多月的时间，重读了一下这本RAC GUARD概念和管理总结。

 查看全文

这篇文档介绍ORACLE RAC GUARD的问题诊断和故障排除。

 查看全文

这篇文档介绍ORACLE RAC GUARD相关的网络配置。

 查看全文

这篇文章描述了RAC GUARD环境的管理维护操作。

 查看全文

以前看了一半的9.2文档基本上快看完了，现在开始看11.2的文档了。

 查看全文

Oracle的绝大部分功能都可以由客户进行定制，ORACLE RAC GUARD也不例外。

 查看全文

这篇文档介绍了ORACLE RAC GUARD的命令行工具。

 查看全文

这篇文档介绍了ORACLE RAC GUARD的参数配置和修改。

 查看全文

整理了一下最近打算看的文档，准备先从升级手册开始看起。

 查看全文

和性能调整手册相比，这篇文章用时更长，将近五年零一个月。

 查看全文

这篇文章介绍了物化视图的查询重写功能。

 查看全文

这篇文档终于看完了，居然历时四年之久。

 查看全文

虽然是参考性质的文章，但是如果确实需要使用Oracle的全文索引功能，这篇文章还是有必要仔细看一看的。

 查看全文

数据库中以V$开头的视图是动态视图，但是并发所有的V$开头的视图都和性能调整有关，这里介绍的都是和性能优化有关的动态视图。

 查看全文

今天拿到了junsansi童鞋亲笔签名的《三思笔记之一步一步学ORACLE》，心里的感触颇多。

 查看全文

在性能优化文档中Oracle通过单独一章来描述STATSPACK的使用，可见这个工具对于性能优化的重要性。

 查看全文

文档的这一章描述了网络问题的诊断和解决。

 查看全文

这篇文档描述了这本书的重点，如何对数据库实例进行优化。

 查看全文

要对数据库进行性能优化，首先要了解当前数据库运行的情况，这一篇文章介绍了在Oracle中获取数据库运行状况的方法。

 查看全文

这篇文章描述配置共享服务器的方法。

 查看全文

从Oracle9i开始，UNDO段的配置简化了很多，而临时段也变得更加的有效率。

 查看全文

并行操作是数据仓库系统常用的技术，对于硬件资源充足的系统，合理的利用并行，可以使得SQL语句的性能获得大量的提升。

 查看全文

在Oracle中，几乎任何操作都是可以进行优化的，比如这一章介绍的内容，就是如何优化实例恢复过程。

 查看全文

最后一篇文章介绍的是全文索引相关的可执行命令。

 查看全文

这篇文档描述操作系统的优化。

 查看全文

文档的这一章描述了IO相关的概念。

 查看全文

这一篇介绍了CTX_ULEXER包。

 查看全文

这一章描述了如何管理和维护字典信息。

 查看全文

在文档的这一章中，Oracle描述了如何合理的配置内存，介绍了SGA和PGA的分配原则，并介绍如何通过Oracle提供的监测和建议的视图，来调整内存的配置。

 查看全文

最早从920就开始看流的概念文档，不过当时没有看完。今天终于将11.1的流概念文档看完了，流从9.2开始到11g中，增加了很多的功能，也更加稳定了。

 查看全文

周一就拿到了冯大辉(Fenng)寄来的TOP——Troubleshooting Oracle Performance的中文翻译版，但是一直没有来得及仔细阅读。

 查看全文

看完这篇文档用了整整7个月，当然除了这篇流复制管理手册之外，同时还在看几篇其他的文档，比如流的概念文档，11g的概念、管理员手册以及11.2的新特性等等。

 查看全文

由于数据仓库主要应用在两个方面：OLAP和DATA MINING。显然在数据仓库的文档中没有提到这两个功能，显得缺点什么。而且Oracle将这两个功能集成在数据库中，因此这一章Oracle简单描绘了数据库中集成的OLAP和数据挖掘的功能。

 查看全文

这一篇介绍了Oracle的分析函数，以及CASE语句。

 查看全文

这一章介绍了创建数据库，建立初始化参数，以及建立表装载数据的性能方面的考虑因素。

 查看全文

9i性能调整手册文档中介绍的这个TRACE的功能，以前还真的没有用过。

 查看全文

对于AUTOTRACE工具，估计很少有人没有用过，绝大部分人都对这个工具比较熟悉。

 查看全文

当时看这篇文档是为了搭建RAC环境，结果看了一部分后发现这篇文档对于安装RAC的左右不大，于是就先放下了，现在在搭了N多个RAC环境后终于把这篇文档看完了。

 查看全文

最近在捡起以前没有看完的文档，今天看完了性能调整手册的SQL TRACE和TKPROF这一章。

 查看全文

今天把9i的用户管理备份和恢复手册看完了。

 查看全文

最近整理了一下看过的Oracle官方文档，发现很多篇文档只看到一半，而这篇文档只差了这最后一章，而这一章还是相当有意义的。

 查看全文

这篇文档值得一读，里面介绍的大部分工具都是DBA日常需要用到的。

 查看全文

流的概念文档已经看过两次了，不过流的复制还是第一次看。

 查看全文

VAULT ADMINISTRATOR这本书终于看完了。原计划1个月左右就能看完，没想到用了3个多月。

 查看全文

在笔记本上装了11g的VAULT已经好长时间了，一直没有时间看VAULT相关的内容，最近打算看看安全性相关的内容，正好先看看VAULT。

这两天拿到了EYGLE的第二本书《循序渐进ORACLE——数据库管理、优化与备份恢复》。

 查看全文

前一段时间帮谷博士审了书中的一章，出书之后，谷博士送了我一本《ORACLE 11G权威指南》。

不过由于最近事情比较多，还没有来得及拜读，所以无法对书中的内容做任何的评价，因此只是对书的目录和结构简单描述一下。

 查看全文

很久没有写读书笔记了，一方面是由于大部分读书笔记没有什么技术含量，另一个更主要的方面实在是最近花在看文档上面的时间太少了。

 查看全文

今天在看Tom的新书Oracle9i&10g编程艺术发现了一个小问题。

 查看全文

在ITPUB年会的时候，PINER赠了一本他的新作《构建ORACLE高可用环境——企业级高可用数据库架构、实战与经验总结》给我。

转眼年会已经过了10天，一直打算写点什么，但是年底的事情实在很多，还没有来得及拜读此书。实在不好意思再拖下去了，只好先写一点对这边书的印象。至于详细的评论，只能等到看完之后再说了。

 查看全文

这篇主要介绍如何利用DATA GUARD BROKER图形界面来执行管理操作。

这一章介绍如何使用RMAN进行表空间的及时点恢复。

这篇文章介绍了如何利用RMAN来进行备份和COPY。

这一章介绍了数据库资源的管理、配置和切换。

今天将EYGLE的《深入浅出Oracle——DBA入门、进阶与诊断案例》看完了。

 查看全文

这篇主要介绍了DATA GUARD BROKER的站点对象，并详细介绍了DATA GUARD BROKER的角色管理。

这一章介绍DATA GUARD BROKER的配置管理工作。

DATA GUARD部分包括两个文档，出了这篇文档之外，还有DATA GUARD BROKER。

这篇主要介绍了DATA GUARD BROKER的主要功能和基本概念。

DATA GUARD的配置和管理基本上看完了，准备看看DATA GUARD代理工具，DATA GUARD BROKER。

DATA GUARD BROKER主要是自动管理和简化DATA GUARD环境的创建、控制以及监控等。

CTX_REPORT包中包括了全文索引的各种报告过程。

这篇文档介绍了ORACLE RAC GUARD的自动管理操作以及用户发出的角色维护操作。

这篇文档介绍了ORACLE RAC GUARD的体系结构。

这篇文档介绍了ORACLE的RAC环境下，配置DATA GUARD的概念和相关的管理操作。

这篇文档介绍了DATA GUARD环境中的所有相关视图。

这篇文档介绍了管理DATA GURAD环境的SQL语句。

这篇文档介绍了Oracle的LOG_ARCHIVE_DEST_n初始化参数的属性。

这篇文章介绍了DATA GUARD环境相关的初始化参数。

这一章介绍了ORACLE DATA GUARD部署中常见的几种情况。

这篇文档主要介绍了逻辑STANDBY环境的管理相关操作。

这篇文档主要介绍了物理STANDBY环境的管理相关操作。

这篇文章介绍了DATA GUARD切换相关的内容。

这一章分别描述了物理STANDBY和逻辑STANDBY的日志应用和日志监控。

这一章主要介绍了DATA GUARD环境中，物理STANDBY和逻辑STANDBY在三种不同保护模式下日志传输方式的不同。

这篇文档详细介绍了逻辑STANDBY数据库的建立过程。

这篇文档详细介绍了物理STANDBY数据库的建立过程。

这章介绍了在使用DATA GUARD之前应该首先考虑的问题。

 查看全文

第一章主要是对DATA GUARD进行了一个全面的介绍，使得读者可以对DATA GUARD有一个初步的认识。

DATA GUARD以前虽然没有看过官方文档，但是通过从其它地方的了解，对DATA GUARD并不算陌生，对DATA GUARD的基本概念和体系结构有一定的了解。

DATA GUARD是9i以后的名称，在8i中叫做STANDBY。9i在修改名称的同时还增加了很多的功能。其中最大的改进应该是9R2增加的逻辑DATA GUARD功能。

这篇文档主要包含了RAC环境的部署、RAC环境配置、RAC数据库性能优化和RAC数据库性能监控等内容。

这个包集合了一些和查询相关的过程。

文档介绍了性能管理器如何监控RAC数据库。

这一章介绍RAC环境的性能监控。

这本书看完第二遍了。感觉看第二次的收获不比第一次少。

 查看全文

文档介绍如何部署RAC环境，使得数据库具有更好的性能。

这篇文章介绍的是三种不同类型的应用程序在RAC环境中的部署。

这章的内容主要是在RAC环境中实现9i的特性。

这篇文档介绍RAC环境的部署、配置、性能优化以及性能监控等内容。

前后一个月的时间，断断续续的将这篇文档看完了。

 查看全文

这一章介绍的是RAC环境中如何对数据库进行备份和恢复。

这一章介绍了在RAC环境中使用RMAN与单实例数据库环境中使用RMAN的区别。

 查看全文

这一章描述的是使用OEM来管理RAC数据库。

这一章主要描述的是管理RAC环境的命令行工具。

这章主要介绍了RAC环境中的文件管理特点。

这章主要介绍了RAC的参数管理特点。

这章主要是对这篇文章包含的内容进行了一个简单的介绍。

总的来说，这篇文章包含的内容很少，基本上就是对这篇文章中主要介绍的内容做了一个简单的介绍。唯一的好处是看完这章后会对整个文档介绍的内容有了一个大致的了解。

今年的工作重心将转到RAC上来，赶在生产环境还没有建立起来之前，先补补RAC方面的知识。

其实这篇文章在看完RAC的概念文档后就应该看，但当时一是缺少用来练手的环境，二是即使看完暂时也用不到，所以就一直拖到了现在。

CTX_OUTPUT包主要用于打印全文索引诊断数据。

这个包的主要作用是提供文档的内容服务。

这个包介绍了全文索引创建维护所使用的过程。

CTX_CLS包用来产生文档的CTXRULE查询规则的

文档这一章介绍了CTX_ADM包。

这一章介绍的内容比较简单，主要是说明如何对特殊字符进行查询。

文档的这一章主要介绍了CONTEXT索引的CONTAINS操作。

 查看全文

文档在这一章介绍了创建全文索引的所有相关内容。

Tom在这本书的最后一章介绍了调用者权限存储过程和定义者权限存储过程。最开始了解调用者权限存储过程就是第一次阅读这一章的时候，这次再看的时候又有了不少新的收获。

新建对象也可能导致存储过程的失效：http://yangtingkun.itpub.net/post/468/223040

新增对象对调用者权限存储过程的影响：http://yangtingkun.itpub.net/post/468/223110

调用者权限过程的权限问题：http://yangtingkun.itpub.net/post/468/225403

调用者权限存储过程的权限特点：http://yangtingkun.itpub.net/post/468/226452

今天终于拿到了EYGLE的大作《深入浅出Oracle——DBA入门、进阶与诊断案例》。

这篇文档介绍了全文索引开发相关的知识，内容包括索引、查询、文档展示、性能调整、节搜索等内容。

文档在这章介绍了全文索引的创建、删除和修改的语法，以及一些全文索引特有的操作。

文档这章介绍了与全文索引有关的管理方面的内容。

文档在这一章描述了全文索引的字典信息，并说明了如何扩展现有的字典，如何为其他语言添加字典。

Tom在这章介绍了多层身份验证技术。利用这种技术，可以使一个用户代理其他用户登陆，并以被代理的用户的身份来执行操作。而且这个用户不必知道被代理用户的密码。

这篇文章比较详细的介绍了节搜索的相关内容。对于HTML和XML这种包含内在结构的文档，节搜索提供了强大的索引功能。

这一章的内容也是在其他文章中比较少见的。Tom介绍的精细存储控制功能也被称为虚拟专用数据库（VPD）或行级安全性。使用这种技术可以将权限的控制由对象级缩小到数据行级。

其实一开始没有打算全文索引参考的读书笔记，甚至开始的时候并没有打算仔细阅读这篇文档。一直认为这篇文档的作用很像SQL参考或错误参考手册，只是在碰到问题的时候查询一下就可以了。但是随着对TEXT了解的深入，发现全文索引开发手册上很多内容不全，或者仅仅包括一些皮毛，真正详细的内容还有参考这篇文档。

这次是看第二遍看这本书了，但是这一章里面的不少内容却没有什么印象。看来书还是不能光“看”，否则无论看多少遍，东西还是作者的，而不是你自己的。

这一章就是这样，Tom介绍了很多和对象相关的内容，对于那些自己熟悉的内容，就有比较深的印象，而对于那些不熟悉的，就没有什么印象了。

 查看全文

这一章Oracle介绍全文索引性能相关的内容。这一章的内容也是我比较感兴趣的。

这章介绍的内容和文章的显示有关，Oracle主要介绍了几个相关的过程。

上一章介绍完了全文索引的基本情况，这章介绍的是全文索引可以支持的各种查询操作。

JAVA存储过程是Oracle815引入的一个功能，允许用户使用JAVA语言实现外部存储过程。Tom在这一章描述了JAVA存储过程的相关知识。

 查看全文

Tom在一章详细介绍了Oracle的C外部过程。

 查看全文

文档的这一节介绍了ORACLE TEXT的三种常用全文索引，以及全文索引的维护操作。

Tom在这章介绍的Oracle的全文索引。

Tom的第二本力作终于看完了。

Tom在最后一章介绍了排除故障时的一些方法和注意事项。

这章和前两章一样，都是本书中最关键的章节。

文章描述了EXPLAIN PLAN的语法以及和EXPLAIN PLAN相关的内容。

这一章高效的SQL和下一章高效的PLSQL设计可以说是本书的最核心内容了。

又是重量级的一章，Tom介绍了如何利用Oracle提供的不同的对象和模式来高效的解决各种实际问题。

 查看全文

从这章开始，进入了这篇文档的第三大部分。前两部分分别是RMAN的介绍和RMAN的基础概念，这章开始介绍实际的RMAN操作。

翻译过来的标题还真长，不过翻译了半天，也没有表达清楚，感觉不不如不翻译呢，不知道Tom的原文叫什么。

这章的内容相对比较简单，主要介绍了RMAN中用于维护的各种命令。

这章介绍了RMAN的还原、恢复操作，并介绍了利用RMAN创建DUPLICATION数据库和STANDBY数据库。

Concept是我最早看完的文档，也是目前看过重复次数最多的文档。Concept文档并非包括了所有Oracle相关的概念，RAC、备份和恢复等内容就存在专门的概念文档，但是Concept文档绝对是对Oracle介绍的最全面的一篇文档，里面涉及到了所有的Oracle的基础概念。

Concept文档的重要性我不想多说了，用TOM的话来形容，如果你看完了Concept文档，且仅仅记住了10%的内容，那么你对Oracle数据库的了解已经比90%人要多了。根据我的感觉，这句话并不夸张。就ITPUB而言，论坛里面管理区和开发区50%左右的问题的答案可以在Concept上找到。

如果有时间，Concept文档应该重复看多次，每次看完你都会发现新的收获。

这一章Tom介绍了DML、DDL语句的分析、优化和执行。

Oracle的审计功能可以方便的监测数据库的使用。而且，审计也是为数不多的监测SELECT语句的方法之一。

这一章是RMAN用户手册中篇幅最大的一篇，它包括了RMAN里面和备份有关系的各种概念。

TOM在这章介绍了的内容似乎和DBA的关系更大些。不同从另一个角度，这些也是数据库物理和逻辑结构设计的一部分。

 查看全文

这一章Oracle主要描述了权限和角色的概念。

控制数据访问这章主要描述数据库安全、用户访问以及用户资源和参数文件等内容。

 查看全文

TOM在这章介绍了四方面内容：连接服务器类型、集群、分区和并行。

 查看全文

RMAN体系结构介绍了RMAN环境、RMAN命令接口、RMAN资料库和介质管理四部分内容。

这一章通过一些最简单最基本的例子介绍了RMAN的一些基本操作。

和其他连接到数据库的程序相比，RMAN连接数据库要复杂一些。

 查看全文

这一章主要介绍了RMAN的优点和RMAN的运行环境。

备份和恢复的概念文档已经看完，用户管理的备份和恢复手册也基本学完，准备开始动手研究一下利用RMAN进行数据库的备份和恢复操作。

RMAN是的全称是Recovery MANager，是Oracle推荐的用来备份和恢复数据库的工具。简单扫了一下这本书的目录，包含的章节和内容很多，不过相信里面会包含不少内容被用户管理备份恢复手册所覆盖到的内容。

Tom在这一章集中介绍了Oracle数据库性能调整所使用的各种工具。

 查看全文

这一章Oracle给出了几个需要进行恢复的具体情况，并逐一对每种情况下的恢复操作进行了说明。

这章主要描述了介质恢复过程中可能出现的各种错误，并针对每种错误给出了建议解决方法。

这一章Oracle介绍了各种情况下的介质恢复操作。

Tom在第一章讲述的内容在他的One on One Oracle等著作中已经描述过很多次了。不过这次总结的尤其全面，而且对于大部分的观点都给出了具体的案例作为说明。

这篇文章介绍了恢复操作中最简单、最基本的步骤——文件的还原。

这一章通过实例详细讲述了用户管理备份的各个方面。

今天终于把这本书拿到手了。如果没有记错，这本书似乎是03年才出版的，居然中文版赶在了奥运会之前出版，出版进度之快，着实让我佩服。

这篇文章从到到尾详细描绘了备份和恢复的基本要点。通过学习这篇文章可以对Oracle的备份恢复有一个更深刻的了解。

不过这篇文章毕竟只是基础的概念，要想更深入的了解ORACLE的备份与恢复，必须自己动手实践，才能真正了解的备份和恢复。

这章为建立一个有效的备份和恢复策略提供指导和策略。

本章主要描述将事件部署到队列中和将事件从一个队列传播到另一个队列的相关概念。

 查看全文

用户管理备份和恢复是指不使用恢复管理器RMAN作为主要的备份和恢复策略。用户管理备份主要利用操作系统命令对数据文件和归档日志文件进行备份。

 查看全文

这篇文章介绍了如何使用操作系统命令备份和恢复手册。

 查看全文

这一章描述在数据库恢复过程中用到的概念。

这一章比较详细的介绍了数据库备份的概念和原理。

流的捕获是流机制中的第一步，主要描述和捕获进程有关的概念。

 查看全文

数据备份和恢复是指采用的各种策略来保护数据库的数据，防止数据的丢失，并在数据丢失发生之后重构数据。数据的重构一般通过介质恢复来完成，包括还原备份的数据文件（restore）、前滚和回滚三个部分。

DBA最重要的工作莫过于保证数据的安全和可用性。数据库的备份和恢复是DBA的基本功，而备份和恢复的概念又是基础中的基础。

一直对备份和恢复这部分缺少系统的学习，因此近期准备通过学习官方文档，将整个备份和恢复部分从头到尾过一遍。

PL/SQL语言可以实现对数据库对象的存储和访问。但是标准的PL/SQL要求查询的对象和查询的结果等条件必须是在编译时候就确定的，而在很多情况下却无法保证这一点。这时，就需要使用动态SQL语句。

 查看全文

流是Oracle提供的在两个数据库之间传播信息的一种机制，利用流机制，用户可以自己控制将哪些信息（如DML、DDL或用户自定义信息）放入流中，传播并应用到另一个数据库中（也可以是当前数据库）。

 查看全文

Oracle的stream（流）是从Oracle9i开始提供的新功能。它的很多功能和高级复制相似，不过二者实现机制是不同的，流是以抽取重做日志的方式实现，而高级复制是利用系统内部触发器来实现的。

大致看了一些目录，发现流比复制要灵活一些不过也更复杂。不过一直听说Oracle9i中的流还不大成熟，bug比较多，看来以后看书和测试的时候要更仔细一些了。

这一章介绍了4个方面的内容：配置客户端、RAC的Transparent Application Failover(TAF)、主/从实例设置和RAC GUARD II。

 查看全文

自治事务允许在用户在事务中建立一个新的事务，而且新建事务的提交和回滚不会影响到父事务的状态。

 查看全文

Oracle的分区技术使得拥有大量数据的对象的管理得到简化，同时分区也提高了对象的可用性。

这一章文档主要介绍RAC的安装配置信息。

这本书不仅是高级复制的参考手册，还是高级复制的实践手册。

Oracle从815开始支持物化视图。Oracle的物化视图应用很广，在性能优化、复制、数据迁移、分布计算等多方面都发挥重要的作用。不过Tom这章主要是针对性能优化这方面来论述物化视图的。

一般情况下，总是使用CBO，RBO只是为了保证系统的后向兼容性。

数据库中经常用到聚集函数。在数据仓库中，更是经常要进行聚集操作，Oracle除了最基本的GROUP BY以外，还提供了ROLLUP和CUBE等函数。

Tom的这篇分析函数是我目前见过最好的一篇关于分析函数的文章，介绍的深入浅出，而且包含了大量解决实际问题的例子。

这一章描述了数据并发访问和数据的一致性。

最近正好赶上性能优化调整手册和这本书都看到优化器方案稳定性这一章。两本对照起来看，马上就可以感觉出二者的差别。

影响Oracle的执行计划的因素很多，如统计信息、优化器模式、初始化参数等等。Oracle提供了一种方法将执行计划保存下来，从而避免环境的变化对执行计划产生影响。

Oracle插入数据有两种模式：常规路径和直接路径。

当Oracle并行执行SQL语句时，多个进程同时工作来运行一个单独的SQL语句。并行度是指同时进行工作的进程数。

Tom描述了优化思路和一些常用的优化工具。

Oracle推荐在RAC环境中用SPFILE替代PFILE。

 查看全文

这一章介绍了手工创建RAC数据库的步骤。

这章描述了高级复制相关的基本概念和术语。

这一章描述了如何定位消耗大量资源的SQL语句，并提供了调优的建议。

触发器是由PL/SQL、JAVA或C写的存储过程，当满足触发条件后自动调用。

 查看全文

事务是一个或多个SQL语句构成的逻辑单元。

RAC概念这本书对于Oracle的RAC来说类似于Oracle的Concept对于Oracle数据库。这本书包括了所有的RAC方面的概念，相信介绍了RAC的各种运行机制，描述了RAC的特性。

不过，光看这本书而不动手实践是没有作用的，只有通过自己的动手测试，才能真正理解RAC的各种运行机制。

配置成提供接近在任何时候都可用的计算环境叫做高可用系统。具有高可用性的系统一般都具有冗余的硬件和软件，一个具有良好设计的高可用系统不存在单点故障。

一些对象的定义会参考其他的对象。比如，存储过程、视图等对象会参考表、视图、过程等。这一章主要描述了方案对象的依赖关系以及Oracle是如何自动跟踪和管理这些依赖关系的。

数据仓库系统中推荐使用的方案模型为：星形方案或第三范式方案。

新的项目可能会用到Oracle的全文检索功能（Oracle TEXT），前两天做了几个简单的测试，对全文检索有了一些初步的了解。

Oracle除了基本的数据类型之外还支持对象类型，运行用户自定义各种类型的对象。

物化视图为复杂的、数据密集型查询提供高性能。概要顾问（Summary Advisor）则可以帮助你在一定的工作负荷的情况下选择合适的物化视图来提高性能。

TOM在这章详细介绍了SQLLOADER的使用。

Oracle的分区技术用来支持非常大的表和索引。利用分区可以将一张大的表分成多个小的，易于管理的分区。

查询语句和DML语句访问分区表时不需要进行任何的修改。然而DDL语句可以避免对整个表或索引进行操作，而直接针对单独的分区进行操作。分区使得数据库中包含海量数据的表或索引的可管理性增强，而且分区完全对应用程序透明。

表或索引的分区具有相同的逻辑结果，而他们可以拥有各自的物理结构。分区适用于各种类型的应用程序：OLTP系统可以在可管理性和可用性方面得到提高；数据仓库系统可以从可管理性和性能方面获益。

Hint是Oracle数据库灵活性的体现。由于Hint具有最高的优先级，因此可以通过Hint使优化器根据用户的需要来生成指定的执行计划。

Oracle的hint种类繁多，大致可以分为下面几类：

优化方式和目标：如RULE、CHOOSE、FIRST_ROWS、ALL_ROWS等。

访问路径：如INDEX、FULL、CLUSTER、INDEX_FFS等。

查询转换：如MERGE、USE_CONCAT、NO_EXPAND等。

连接顺序：如ORDERED和STAR。

连接操作：如USE_NL、USE_HASH、USE_MERGE等。

并行执行：如PARALLE、NOPARALLEL、PARALLEL_INDEX等。 

其他类型；如APPEND、UNNEST、CACHE等。

方案是数据逻辑结构或用户对象的集合。方案属于一个数据库用户并具有和数据库用户相同的名称。每一个用户只能拥有一个方案（对于刚建立的用户，且用户尚未建立任何对象，则该用户没有方案）。

方案包含以下对象：聚簇、数据库链、数据库触发器、维度、外部过程库、索引和索引类型、Java class、Java resource和Java source、物化视图和物化视图日志、对象表、对象类型和对象视图、Operators、序列、存储过程、函数和包、同义词、表和索引组织表、视图。

下列对象存储在数据库中，并不包含在方案中：

上下文、目录、Profile、角色、表空间、用户和回滚段。

 查看全文

这章描述了如何通过Oracle Universal Installer来安装Oracle9i企业版和RAC软件。

高级复制主要描述了高级复制的概念和机制。这本书并没有包含任何例子，所有关于高级复制的例子都在《复制管理应用程序接口参考》这本文档中。

Oracle的资源管理器可以帮助数据库管理员把资源分配给不同的用户组。

EXP和IMP的主要用途包括：检测冲突、抽取DDL、克隆模式、传输表空间、重构实例和在平台之间复制数据等。

如果系统不支持Cluster File System（CFS）或者不希望使用CFS，可以为RAC配置共享磁盘子系统。

这篇文章包括两个部分：

为RAC配置共享磁盘子系统；

为RAC配置逻辑设备。

第一章主要描述了一下RAC的安装过程，并说明了RAC对硬件和软件的要求。

RAC的概念基本看完了，对RAC有了一个大致的了解。这篇文章是讲RAC的安装、建立和配置。

从RAC的四个阶段分别介绍了对应的工具，这四个阶段是：

RAC的安装、建立和配置；

RAC的管理；

RAC的性能监测；

RAC的备份和恢复。

从数据文件、参数文件、联机重做日志文件和回滚表空间数据文件四个方面描速了RAC的数据存储特点。

从三个方面介绍全局队列服务（Global Enqueue Service）：

全局队列服务处理；

全局队列并发控制；

全局队列服务所管理的资源；

这章描述了缓存融合（Cache Fusion）处理，解释了GCS操作。同时说明了RAC中的资源控制机制，举例说明了Cache Fusion，并且描述了RAC中的恢复处理。

 查看全文

RAC需要在多个实例中同步以控制资源的共享访问。在RAC中资源协调同时发生在实例级和数据库集群级。实例级的资源协调叫做本地资源协调，集群级的叫做全局资源协调。

 查看全文

这一章从三部分讨论RAC的可扩张性：

RAC的可扩展特性；

RAC可以给不同类型的系统带来性能提升；

扩展性的分级讨论。

RAC软件结构可以分为四部分：

操作系统相关的软件（Operating System-Dependent）；

RAC共享磁盘部分；

RAC中特别的后台进程和实例进程；

全局缓冲区服务和全局队列服务。

RAC的结构主要包括三个部分：

两个或多个节点；

将各个节点连接在一起的INTERCONNECT；

存储设备或共享磁盘子系统。

这一章主要讨论两方面内容：什么是RAC和RAC给我们带来的好处是什么。

以前没有怎么接触过RAC，对RAC的了解很浅，正好有个机会学习一下RAC，准备先从最基本的RAC概念学起。

这章Tom从两个部分介绍索引，前半部分介绍了各种类型的索引以及它们的用途，后半部分是关于索引常见问题的回答。

 查看全文

变化数据捕获(Change Data Capture)在数据仓库中用来快速定位数据源的变化，可以使UTL操作的数据范围缩小到自上次导入后发生变化的数据。

管理员手册是DBA的最基础的文档之一。我认为，对于一个ORACLE DBA来说，看完CONCEPT手册，应该马上看管理员手册。

管理员手册中包含了Oracle中几乎所有的基本操作，而且还是CONCEPT手册的实战部分。如果把CONCEPT手册比作课本的正文的话，那么管理员手册就是正文后面的习题，通过验证测试管理员手册中的各种操作，可以加深对CONCEPT的理解。如果能把这两本文档基本掌握的话，那么至少论坛中50%以上的问题你已经知道答案了。

Tom从表的基本存储参数：FREELISTS、PCTFREE、PCTUSED、INITIAL、NEXT、PCTINCREASE、MINEXTENTS、MAXEXTENTS、LOGGING、NOLOGGING、INITRANS和MAXTRANS开始介绍，然后依次对堆表、索引组织表、聚簇表、散列聚簇表、嵌套表、临时表和对象表进行了讲解和说明。

这篇文章主要从四个方面来如何高效的维护数据仓库。

Oracle系统中进程主要包括两类：

用户进程：运行应用程序或数据库工具。

Oracle进程：运行Oracle服务器代码。可以分为两部分，服务器进程和后台进程。

这一章首先介绍了如何选择、建立和维护索引，然后介绍了这种特殊类型的索引和它们的使用范围，最后介绍了索引聚簇和哈希聚簇，并说明了它们的适用条件。

Oracle使用内存来存储下列信息：

程序代码；

连接会话的信息；

程序执行过程中所需信息；

Oracle进程间共享和交互的信息；

数据缓冲。

Oracle的内存结构包括：

系统全局区（SGA）：由所有server进程和后台进程共享。其中包括以下几部分：

数据库缓冲池；

重做日志缓冲池；

共享池；

大池。

程序全局区（PGA）：由每个server进程和后台进程私人专用。

软件代码区。

数据库和应用程序经常处于分布环境中。系统架构可能是两层结构（客户端/服务器结构）或多层结构。

统计信息包括下面几类：

表统计：包括记录数、block数和记录平均长度。

列统计：列中不同值的数量（NVD）、空值的数量和数据分布（HISTOGRAM）。

索引统计：索引叶块的数量、索引的层数和聚集因子（CLUSTERING FACTOR）。

系统统计：I/O性能和利用率和CPU性能和利用率。

数据转换操作常常是ETL过程中最复杂、占用时间最长的过程，而且转换过程都发生在数据库中。从结构上，有两种方式进行转换：

多级数据转换：传统的转换方式，每一步都生成一张中间表。

管道数据转换：通过表函数机制，将第一步操作的结果直接作为第二步的输入。

描述了INSTANCE的概念，并介绍了数据库的启动和关闭。

数据字典是Oracle数据库中最重要的部分之一，数据字典是一系列只读的表，用来提供数据库的信息。

这章介绍了表空间、数据文件和控制文件的概念。

Tom在这章详细的介绍了重做和回滚的信息。

这章主要介绍了两方面的内容：优化器如何评估、执行某些操作和优化器如何转换sql语句。

当优化器发现和当前操作等价的操作且转换后执行效率更高，则优化器会自动将当前操作进行等价的转换。比如，Oracle会将“= ANY (子程序)”转化为“IN (子程序)”。

这章介绍了如何评估、转换和执行下列操作：IN-LIST迭代、Concatenation、远端操作、分布语句、排序操作、视图、常量、UNION和UNION ALL操作、LIKE操作、IN操作、ANY和SOME操作、ALL操作、BETWEEN操作、NOT操作、传递性操作、公共子查询和确定性函数。

SQL语句是一种十分灵活的语句，得到相同的查询结果可能存在着很多种写法。有时优化器会对查询语句进行等价的转换如果优化器发现进行转换后的语句的执行效率更高。

优化器会对下面五种语句进行转换，包括：

将OR连接的查询转换为使用UNION ALL语句；

将多层嵌套的复杂语句转换为连接语句；

合并视图；

将查询条件推入到子查询中。

数据仓库中的传输一般发生在：

从数据源传输到中间数据库或数据仓库；

从中间数据库传输到数据仓库；

从数据仓库到数据集市（data mart）。

传输机制主要有三种：文件传输、通过分布式操作传输和利用传输表空间传输。

文件传输是最简单方便的方法，但是需要抽取和装载。

通过分布式操作可以通过一个步骤完成抽取、传输和装载的工作，但是对源系统的时间和资源消耗要比其它两种方式大得多。

传输表空间可以快速、方便的传输多个对象到目的数据库，而且传输表空间的所需时间基本上就是传输数据文件的时间。不同传输表空间还是有不少限制的，具体的例子可以参考：http://blog.itpub.net/post/468/13902

这章介绍了事务的概念，事务应该具有一下特点：原子性、一致性、隔离性和持久性。

Tom首先介绍了事务控制语句，然后通过例子说明了Oracle内部是如何使用SAVEPOINT语句来保证语句级和事务级的一致性的。

介绍了完整性约束和事务的关系，并给出了延迟约束的例子。

Tom一再的重申，事务的大小应该由具体的商务规则决定，不要人为的添加COMMIT语句。Tom给出了具体的例子说明由一条语句构成的大的事务比人为的将一个长事务分成若干个小事务执行快得多。而且拆分成小事务后，如果执行中途失败，很可能无法继续执行，从而造成数据完整性的破坏。

在抽取之前可以考虑两个问题：

选择哪种抽取方法；这个选择会影响数据源系统、传输过程和数据仓库的刷新时间。

如何为后续操作提供抽取数据。这个选择会影响传输方法以及是否需要进行清洗和转换数据。

逻辑抽取包括两种类型：全部抽取和增量抽取。

物理抽取包括：在线抽取和离线抽取。

变化数据捕获（Change Data Capture）一般包括三种技术：Timestamps、分区和触发器。

Oracle抽取数据到文件一般采用几种方式：SQLPLUS的spool命令输出到文件、通过PRO*C和OCI输出到文件、通过EXP导出到二进制文件。文档没有介绍，还可以通过PL/SQL的UTL_FILE包将数据输出到文件。

这章介绍Oracle的逻辑结构data block（数据块）、extent（扩展）和段（segment）的概念。

这一章Oracle对数据库中最基本的概念进行了简单的描述。虽然介绍的比较简单，但是覆盖面比较广，包括了Oracle的基本架构和各种特性。

这一章主要描述了权限和角色和管理。

Oracle建立用户使用CREATE USER语句，用户建立完成后为了可以访问数据库，必须授予一定的权限或角色。Oracle还提供了一种将授权和建立用户合二为一的语句，例如：GRANT CONNECT TO TEST IDENTIFIED BY TEST;这个语句在建立用户的同时给用户授予了CONNECT角色。

Oracle用户授权方式有四种：数据库验证、外部验证、全局验证和代理验证。大多数情况会使用数据库验证的方式。对于使用外部验证的操作系统用户：可以参考下面这篇文章。Windows下的操作系统验证：http://blog.itpub.net/post/468/4223

Oracle通过给用户指定PROFILE文件的方式来限制用户的资源使用情况。当修改PROFILE的时候，ALTER语句中包含的PROFILE选项进行修改，其它的选项保持原样。

这一章分别描述了系统安全策略、数据安全策略、用户安全策略和密码安全策略。

Oracle给出了一个安全检查列表，可以通过这个列表检查并配置你的数据库环境。这个列表主要包括以下几点：

只安装需要的产品；

锁定默认用户帐户并使之过期；

改变默认用户密码；

设置数据字典保护；初始化参数O7_DICTIONARY_ACCESSIBILITY=FALSE。

采用最小权限原则；给用户满足其需要的最小的权限。

有效的加强存储控制；初始化参数REMOTE_OS_AUTHENT=FALSE。

约束操作系统访问；

约束网络访问；

应用所有的安全补丁；

联系Oracle安全性产品。如果你确认发现了Oracle9i的安全性方面的隐患，你可以直接联系Oracle。

另外文档中对于密码重用规则的描述有误。具体的错误以及正确的描述可以参考这篇文章：

ORACLE9i密码策略——密码重用规则：http://blog.itpub.net/post/468/4456

ETL是Extraction、Transformation和Load的缩写。Extraction抽取、Transformation转换和Load装载是ETL过程的三个最主要步骤，但是ETL并不仅仅包括这三个步骤，它还包括比如Transportation传输步骤。

Oracle9i数据库并没有包括ETL的完整解决方案。Oracle有专门的ETL工具OWB（Oracle Warehouse Builder）。ETL工具除了完成抽取、传输、转换和装载等任务，还包括一些日常维护功能，比如记录ETL过程的成功、失败，跟踪和记录历史数据变化等功能。

Oracle在这一章介绍了维度的定义、维度的创建、修改和删除。不过没有说明维度的使用。建立维度是为了数据仓库中的查询重写功能。通过维度Oracle可以了解更多的商业规则，根据维度定义Oracle可以从详细的维度汇总出概括的维度。

维度会包含一个或多个LEVEL，每个LEVEL可以定义多个属性。通过建立一个HIERARCHY将所有的LEVEL建立等级关系。

Tom在这一章介绍了Oracle的锁机制和并行性。

Oracle的锁机制在技术上领先于其他的数据库。Oracle读不阻塞写，写也不阻塞读，Oracle的行级锁不会带来额外的性能开销，Oracle不会读取没有提交的数据（脏读），Oracle也不会将锁定升级。正是这些特点，使得Oracle在可以为OTLP环境提供更高的并发性和可伸缩性。这也是其他数据库没有或很难实现的。当然，Oracle的锁定也是有代价的，这个代价发生在block中，Oracle需要额外的存储空间来存储锁定信息。

这章还介绍了隔离等级，SQL92标准有4个等级，Oracle显示的支持两个（READ COMMIT和SERIALIZABLE），同时Oracle还提供了一个额外的READ ONLY隔离等级。

Oracle提供了DBMS_REPAIR包来检测和修复坏块。

使用这个包需要注意几个地方：

首先，这个包没有授权，普通用户没有权限访问，一般推荐用SYS执行这个包的过程。

这个包可以修复坏块，一般情况下不可避免的会造成数据的丢失（取决于出现坏块的表的索引的情况）。而且使用这个表的时候可能会引入数据不一致和完整性约束被破坏等情况的出现，因此不但要谨慎使用，在使用前还应该做好备份。

最后说明一点，当碰到坏块的情况，如果可能，首先考虑使用备份进行恢复。但是如果是逻辑坏块，且备份的时间在坏块出现之后，则备份也会包含坏块，除非能找到坏块发生之前的备份，否则无法通过备份来清楚坏块。

DBMS_REPAIR的具体使用已经损坏数据的恢复可以参考下面两篇文章：

DBMS_REPAIR的使用：http://blog.itpub.net/post/468/9121

DBMS_REPAIR的使用（二）：http://blog.itpub.net/post/468/13241

这一章Oracle介绍了对于所有对象或大部分对象都使用的管理语句。

 查看全文

由于视图、序列和同义词相对来说比较简单，因此Oracle将这三部分放到一章里进行介绍。

 查看全文

HASH CLUSTER和索引CLUSTER不同，当数据插入到HASH CLUSTER表中时，Oracle会根据CLUSTER的键值把记录放到不同的物理地址中，当读取数据时，Oracle会根据键值直接定位到物理地址。

和普通的带索引的表相比，HAHS CLUSTER的读取所要花费的IO更少，由于通过HASH函数可以直接定位到物理地址，最少只需要一个IO就可以获取数据。

HASH CLUSTER的适用情况：

大部分查询通过HASH CLUSTER的键值查询，且查询条件为“=”；

HASH CLUSTER表的大小保持稳定。如果表的大小超过了建表时的估计值，会造成HASH CLUSTER表的读取性能的下降。

不适合使用HASH CLUSTER的情况：

大部分查询是对HASH CLUSTER键值的范围查询；索引是按照键值顺序存放的，因此支持范围扫描，但是HASH CLUSTER表并非按照键值顺序存储，因此，HASH CLUSTER表不支持范围扫描。

表的大小不是稳定的而是持续增长的；

经常会对HASH CLUSTER表执行全表扫描。当HASH CLUSTER没有填满预计的空间时，数据会比较分散，这时全表扫描的效率会比较低。

聚簇（CLUSTER）分为两种：索引聚簇和HASH聚簇。这章介绍的是索引聚簇。

CLUSTER是段的一种类型。一个聚簇就是一个段，聚簇中的所有表根据聚簇列存放在同一个段中。这些表具有相同的物理存储结构。

CLUSTER平常似乎很少使用，但是在Oracle的数据字典中使用很普遍。原因主要有两方面，一是对CLUSTER的特性和功能不是很了解，二是CLUSTER簇的限制相对较多，影响了CLUSTER的使用。

CLUSTER的主要优点包括：

由于不同表的数据根据CLUSTER键的顺序存放在以前，因此当对CLUSTER表之间连接访问时，会减少IO和存储访问时间；

虽然每个表都包含CLUSTER键，但这一列在CLUSTER中保存一份。因此可以减少存储的空间。

适合CLUSTER的表的特点：

表以查询为主，不适合以插入或修改为主的表；

经常通过连接一起查询的表。

对于索引CLUSTER，注意首先创建CLUSTER，然后创建相应的CLUSTER表，最后一定要建立CLUSTER索引，如果不建立索引的话，没有任何记录可以插入到CLUSTER表中。

Oracle提供了分区技术以支持VLDB(Very Large DataBase)。分区表通过对分区列的判断，把分区列不同的记录，放到不同的分区中。分区完全对应用透明。

Oracle的分区表可以包括多个分区，每个分区都是一个独立的段（SEGMENT），可以存放到不同的表空间中。查询时可以通过查询表来访问各个分区中的数据，也可以通过在查询时直接指定分区的方法来进行查询。

分区提供以下优点：

由于将数据分散到各个分区中，减少了数据损坏的可能性；

可以对单独的分区进行备份和恢复；

可以将分区映射到不同的物理磁盘上，来分散IO；

提高可管理性、可用性和性能。

Oracle提供了以下几种分区类型：

范围分区（range）；

哈希分区（hash）；

列表分区（list）；

范围－哈希复合分区（range-hash）；

范围－列表复合分区（range-list）。

开始的时候奇怪Oracle为什么没有提供范围－范围复合分区，后来想了一下发现，范围－范围复合分区实际上就相当于对两个列进行复合分区。

索引也可以进行分区，分区索引有两种类型：global和local。对于local索引，每一个表分区对应一个索引分区，当表的分区发生变化时，索引的维护由Oracle自动进行。对于global索引，可以选择是否分区，而且索引的分区可以不与表分区相对应。当对分区进行维护操作时，通常会导致全局索引的INVALDED，必须在执行完操作后REBUILD。Oracle9i提供了UPDATE GLOBAL INDEXES语句，可以使在进行分区维护的同时重建全局索引。

感觉Oracle的分区功能十分强大。不过用起来发现有两点不大方便：

第一是已经存在的表没有方法可以直接转化为分区表。不过Oracle提供了在线重定义表的功能，可以通过这种方式来完成普通表到分区表的转化。可以参考这个例子：http://blog.itpub.net/post/468/13091

第二点是如果采用了local分区索引，那么在增加表分区的时候，索引分区的表空间是不可控制的。如果希望将表和索引的分区分开到不同的表空间且不同索引分区也分散到不同的表空间中，那么只能在增加分区后，对新增的分区索引单独rebuild。

Oracle的物化视图提供了强大的功能，可以用在不同的环境中。在不同的环境中，物化视图的作用也不相同。

这一章Tom介绍了Oracle的整个架构，包括各种文件、Oracle分配的内存空间和各种后台进程。

由于这本书的主要面向对象是Oracle开发人员，因此，这一章只是简要的介绍了一下Oracle的构成和工作原理。大部分的概念和Oracle的concepts相比要描述的简单一些，但是Tom给出的例子，尤其是排序区影响PGA和UGA的那个例子，有助于加深你对概念的理解。这是Oracle的concepts手册所欠缺的。

Oracle的这篇文档应该是所有Oracle初学者必读的文档。这篇文档中包含了和Oracle数据库相关的绝大部分概念，比较详细的介绍了Oracle的体系结构和工作原理。这篇文档也是阅读其他Oracle文档的基础。

前一阵刚刚看完第二遍Oracle的Database Concepts。第一遍看的是816的文档，虽然看得不很仔细，但是感觉收获很大。第二遍看的是920的文档，这一次看得比较详细，而且对数据库已经有了一定理解，这次的收获更大，对数据库整体有了一个比较清晰的概念。

打算简单的把这篇文档再过一篇，总结一下比较重要的概念。

建立索引的目的是加快对表的访问速度，索引一般对用户是透明的。

Oracle支持的索引类型包括：B树索引、B树聚簇索引、HASH聚簇索引、全局和本地索引、反向键值索引、BITMAP索引、函数索引和domain索引。

BITMAP索引和函数索引只有在CBO下可以被优化器使用。

通过执行ALTER INDEX index_name MONITORING USAGE开始监测索引的使用情况，执行ALTER INDEX index_name NOMONITORING USAGE语句结束对索引的监测。可以通过查询视图V$OBJEXT_USAGE来判断在监测的时间段内，索引是否被使用。

这一章包含了很多和SQL执行计划相关的基础知识。

表是Oracle中最基本的存储数据的对象。表有多种类型，包括：普通表（堆表）、分区表、临时表、对象表、索引组织表、聚簇表和外部表。

Oracle的临时表有两种类型，一种会在事务结束中自动删除表中的数据，另一种是在SESSION结束后删除表中的数据。

Oracle支持很多操作可以对表进行在线修改。不过对于某些情况，ALTER TABLE语句支持直接修改，比如：修改普通表到分析表。关于在线重定义功能的概念和详细描速，可以参考这个帖子：http://blog.itpub.net/post/468/12855。

这一章主要描述Oracle对象的存储参数的设置。对PCTFREE、PCTUSED、INITRANS、MAXTRANS、INITIAL、NEXT、MINEXTENTS、MAXEXTENTS、PCTINCREASE、FREELIST GROUPS、FREELISTS、OPTIMAL和BUFFER POOL等存储参数的含义和作用进行了说明。使用DBMS_SPACE包可以得到空间的使用情况。

这一章还介绍了Oracle的resumable space allocation属性。

Oracle数据库必须具有一种方法来维护一些信息，这些信息用于回滚或撤销对数据库的修改。这些信息由事务操作记录组成，Oracle把这些记录统称为UNDO。

UNDO记录主要用于回滚事务、恢复数据库和提供一致性读取。

在8i以前版本，Oracle使用回滚段来管理UNDO空间，这种管理方式比较灵活同时也比较负载。从9i开始，Oracle可以自动管理UNDO空间，通过建立UNDO表空间，由Oracle自动分配回滚段的个数和大小。这种方式只需设置一两个初始化参数就可以了，十分简单方便，不过灵活性相对较差，而且9i中的UNDO空间自动管理仍然存在着一些小问题。

9i中通过设置初始化参数UNDO_MANAGEMENT的值来决定使用回滚段还是UNDO表空间。设置UNDO_MANAGEMENT的值为AUTO则使用UNDO表空间，由Oracle自动管理UNDO空间，设置为MANUAL，则通过手工建立回滚段的方式来管理UNDO空间。这两种方式可以互相切换，不过必须重起数据库。

数据文件是构成表空间和数据库的物理文件，存放在操作系统中。

每个数据文件有两个编号：Absolute和Relative。绝对文件号在数据库唯一标识一个数据文件。相对文件号在表空间中唯一标识一个数据文件。当数据文件数小于1024时，这两个值是相等的。

初始化参数DB_FILES设置一个INSTANCE可以建立的最大数据文件数。当数据文件的个数达到初始化参数DB_FILES的值时，必须修改DB_FILES的值并重新启动数据库使修改生效。

归档模式下数据文件可以单独OFFLINE，而非归档模式数据文件不能正常OFFLINE。

数据文件的重命名和移植操作有两种方法实现。对于单个非SYSTEM表空间的数据文件的转移或重命名可以在数据库打开的情况下完成，对于多个表空间或SYSTEM表空间的数据文件的转移或重命名，只能在数据库的MOUNT模式下进行。

Oracle没有办法删除已经加载到数据库的数据文件。只能通过删除表空间的方式将表空间和它包含的全部数据文件删除，不能只删除一个单独的数据文件。ALTER DATABASE DATAFILE …… OFFLINE DROP语句只能使数据文件不再使用，并没有从数据库上真正删除掉数据文件。

初始化参数DB_BLOCK_CHECKSUM设置Oracle是否对BLOCK进行校验。不管是否设置这个值，SYSTEM表空间都会进行校验。如果设置为TRUE，那么DBWn进程会对每个写回磁盘的BLOCK进行校验计算，结果存放到BLOCK的头部。Oracle下次读取该块时，会根据这个校验结果验证是否存在磁盘错误。

由于对硬件不太了解，Mapping Files to Physical Devices这一章基本上没怎么看懂，有时间还要好好研究一下。

描述了管理表空间的策略，并对各种表空间管理操作进行了简单的说明。

 查看全文

Oracle9i中和JOB有关的初始化参数只剩下一个：job_queue_processes。设置job进程的数量。这个初始化参数的最大值由8i的36个增加到了1000个。由CJQ0进程负责唤醒job进程J000～J999对Oracle中的JOB进行处理。

由于采用了这种机制，9i中的JOB总会比设置的NEXT_DATE晚几秒。为了保证多次运行的JOB不会由于这种不准确的因素而造成时间偏移，最好使用TRUNC函数设立JOB运行时间的基准。

Oracle文档上关于JOB失败的情况描述的不很准确。JOB失败后，Oracle会在2分钟左右去再次执行，如果还是执行失败，会在4分钟后重试，然后是8分钟、16分钟。直到遇到3种情况，否则每次重试的时间都会翻倍。

1.执行成功，这时清除失败次数，恢复正常时间间隔。

2.重试16次后，Oracle将JOB设置为BROKEN，停止再次重试。

3.重试的时间超过INTERVAL设置的值，至此以后，Oracle都会以INTERVAL为间隔进行重试，直到上面的两种情况出现。

关于JOB的一些特点：

JOB会对what中进行的操作自动提交；

同时使用数据库链和JOB时应该提供用户名和密码，匿名数据库链会失败；

如果将INTERVAL或者NEXT_DATE设置为NULL，则下次JOB不会再次执行，且会从JOB队列中自动删掉；

通过EXP和IMP可以导出导入JOB（只能通过SCHEMA和DATABASE模式导出，不能单独导出），但是如果JOB号已经在目的数据库中存在，则JOB无法导入；

DBMS_JOB的SUBMIT和REMOVE等过程需要COMMIT；

和JOB有关的视图：DBA_JOBS和DBA_JOBS_RUNNING。

可以参考以下文章：

第一遍看这本书有点走马观花，很多东西没有亲手验证，打算重新看第二遍。

第一章主要介绍TOM对使用数据库的理念——理解数据库的工作原理，充分利用数据库已经提供的功能，用最简单有效的方法解决问题。这一理念贯穿整本书。

Oracle在重做日志中保存所有对数据库的修改，不管是DML语句还是DDL语句，也不管是由普通用户发出的语句还是Oracle自动进行的操作，这些操作全部都会记录到联机重做日志中。

 查看全文

这篇文档很短，只有三章，不过这篇文档总结概括了设计和开发阶段应如何考虑性能问题，遇到性能问题后如何正确的诊断、定位并解决，以及如果快速处理紧急性能问题。

这篇文档包含的内容是性能调整和参考手册的前提和基础，这篇文档给出的是解决问题的思路和步骤，而针对具体性能问题的描述和解决是在性能调整和参考手册中。

2005-1-4

紧急性能调整的方法和第二章介绍的性能调整方法是一样的，只不过紧急性能调整的目标是快速解决问题，尽快使系统恢复到正常状态。

紧急性能调整方法包括以下步骤：

1.调查性能问题并收集性能问题所表现的症状。根据用户的反馈确定问题是吞吐量太小还是响应时间太长。

2.全面检查应用系统中所有硬件的使用情况。检查CPU使用率是否过高、内存的使用、磁盘的情况以及网络的性能。将问题定位到数据库服务器或者应用程序程序上。

3.确定是由数据库服务器上CPU的使用率过高还是由于等待事件造成的问题。

如果是CPU使用问题，进行下列检查：

在操作系统上检查大量消耗CPU资源的会话；

在数据库上查询消耗buffer gets过多的会话，可以通过V$SESSTAT, V$SQL进行查询；

执行计划改变造成的低效的SQL语句（比较困难）；

不正确的初始化参数设置；

版本发行造成的代码的改变或者部件的升级。

如果是等待事件造成的问题，可以通过查询视图V$SESSION_WAIT找到问题产生的根源。

4.使用应急手段是系统恢复稳定。可能的操作包括屏蔽部分应用程序的使用或者限制应用的负荷，也可能包括中止正在执行的任务甚至是重起系统。

5.验证系统是否已经稳定。系统稳定后应根据第二章中介绍的严格的性能调整方法来诊断并解决性能问题。

统计信息分为三部分：

1.操作系统统计信息：包括CPU、内存、磁盘和网络四部分。

2.数据库统计信息：包括Buffer Cache、Shared Pool和Wait Events三部分。

3.应用程序统计信息

收集统计信息：

收集操作系统统计信息的工具：sar、vmstat、mpstat、iostat和netstat等。

收集数据库统计信息的工具：Statspack、OEM和BSTAT/ESTAT脚本（推荐用statspack代替）。

应当在系统刚建立时和系统工作正常时收集统计信息，为系统保留历史统计信息和性能基线。

V$SYSSTAT视图中的USER COMMITS和REDO SIZE统计项可以给出数据库中的事务数和数据的改变量。另外‘session logical reads’可以在一定程度上表示系统查询的负载。但是当这个值发生变化并不一定意味着查询负载发生变化，还有很大可能是由于执行计划的改变导致了逻辑读发生了变化。

Oracle改进性能方法的步骤：

1.从客户得到公正的反馈。

2.收集操作系统、数据库和应用程序处于性能良好和性能较差两种状态的统计信息。如果无法收集到所有状态的统计信息，那么收集所有能收集到的。统计信息的缺失会给诊断问题带来很大的困难。

3.全面检查和当前性能问题有关的所有计算机的操作系统。检查硬件问题和系统资源的使用情况。

4.检查是否发生了Oracle数据库中10个最可能发生的一般性错误。

5.根据目前的症状作为线索，构造一个概念上的模型，来推断导致性能问题的原因。

6.给出一系列补救措施，并将它们按照有效性大小的顺序应用到系统中。最好的方法是每次只修改一个地方，然后观测修改后有什么不同。然而，现实中诸多限制可能无法允许多次的系统重新和过长的停机时间。那么如果同时修改多个地方，应该保证这些修改是彼此独立的。

7.验证这些改变是否能达到预期的效果，用户是否能感受到性能的提升。如果没有达到的话，继续寻找其他瓶颈并重定义概念模型，直到你对应用程序的理解更加的准确。

8.重复上面最后三步，知道性能问题解决或确认所要求的目标无法实现。

如何检查操作系统：

检查整个系统和每个CPU在user和kernel项上的CPU使用率；

确认没有分页和交换存在；

检查不同计算机间的网络延迟是否可接受；

检查磁盘是否存在较长的响应时间和队列；

确认不存在硬件错误。

一个性能概念模型的例子：

1.单用户模式在空闲服务器上运行任务，响应时间是否满足要求？

如果这种情况下都无法满足相应时间，则说明应用程序的设计存在问题，这时无论如何调优，在多用户模式下也不可能满足要求。这种情况应该收集应用程序内部统计信息，进行SQL TRACE检查SQL语句的执行计划。这时问题可能出在数据、索引、事务和SQL语句的设计上。

2.是否所有的CPU被使用？

如果kernel超过了40%，那么检查网络传输、分页、交换或进程瘫痪等。如果CPU的使用主要集中在user上，检查是否存在ORACLE数据库以外的其他进程消耗CPU资源。之后检查最消耗CPU资源的SQL语句。如果应用程序已经是优化的，不存在低效的SQL语句，考虑将部分工作放到非高峰时期或更换系统硬件。

3.如果性能没有达到要求，且CPU没有被重复利用。

检查等待事件，找出导致系统串行化的关键。如果不存在这种问题导致系统串行化，那么问题很有可能出在数据库之外。

Oracle系统中10个最容易犯的错误：

1.连接管理问题

2.没有重复利用游标、没有使用绑定变量导致的无法重用共享池的问题

3.数据库I/O配置错误

4.重做日志文件设置太小的问题

5.由于free lists、free list groups、transaction slots、rollback segment的设置较小导致cache中的data block串行使用问题。

6.长时间的全表扫描

7.磁盘排序

8.大量的系统递归SQL调用

9.方案移植时缺少索引或统计信息的错误和优化问题

10.使用非标准初始化参数的问题

性能问题应该从系统设计时期开始考虑，并延续到系统的生命期终止之时。

具有可伸缩性的系统是指当系统的负载增加一倍，系统需要的资源也同样增加一倍。说起来简单，但在现实环境中确难以做到。由于管理并发用户的开销的增长、锁事务的增长、一致性读负载的增加、操作系统负载的增加、低效的SQL或索引设计导致的过高的I/O等等因素，会导致系统资源的消耗的增长远大于一倍。

破坏可伸缩性的因素：

1.低效的应用程序设计、实施和配置

2.硬件部分的规模不合适

3.软件部分的限制

4.硬件部分的限制

系统的结构可分为硬件和软件两部分：

硬件部分包括：CPU、内存、I/O子系统和网络模块。

软件部分包括：管理用户接口、实现商业逻辑、管理用户请求和资源分配、管理数据和事务。

在设计系统时，应该考虑以下几个问题：

系统将支持多少用户？

用户的交互方式是什么？

用户所处的位置？

网络的速度怎样？

用户将访问多少数据？有多少数据是只读访问？

用户对响应时间的要求？

用户是否需要24小时服务？

是否所有的修改需要实时完成？

应用程序设计原则：

设计简单性原则：

1.如果表的设计复杂到没有人能够完全的理解，那么表的设计可能是比较差的。

2.如果SQL语句过长以致于优化程序无法优化该语句，那么SQL语句的设计、事务和表的设计一定存在问题。

3.如果表的相同列上被重复索引，那么索引的设计可能是有问题的。

4.如果提交的查询没有限定，以致无法迅速的将结果返回给在线用户，那么用户接口或事务的设计是有问题的。

5.如果数据库的调用被许多层软件从应用逻辑中抽象出来，那么，软件开发的方法可能存在问题。

数据建模：应当注意，不要在非核心数据单元上花费过多的时间。

表和索引的设计：选择合适的列进行索引、选择索引类型、注意索引的代价、关注索引中列的顺序。

一个表上如果有3个索引，那么当进行INSERT/UPDATE/DELETE操作时，会比不带索引的表慢大约10倍。

组合索引中，选择性高的列在前查询时需要的I/O更少。选择性低的列在前，有助于代排序操作的查询。

SQL执行效率：

数据库连接管理：应避免没有必要的过多连接。

数据库游标管理：使用cursor和绑定变量，尽量避免硬分析，较少软分析。

硬分析：sql语句第一次提交，并在共享池中无法找到。

软分析：sql语句第一次提交，但是可以在共享池中找到相同的语句。

实施新的应用程序：

切换方式包括两种：Big Bang Approach（所有用户一次性转移到新的系统上）和Trickle Approach（用户分多次转移到新的系统上）。

性能清单列表：

1.设置MAXINSTANCES, MAXDATAFILES，MAXLOGFILES，MAXLOGMEMBERS和 MAXLOGHISTORY的值高于预期值。避免系统的增长导致必须重建控制文件。

2.设置BLOCK SIZE和优化模式与开发环境中相同。如果测试环境中的所有SQL语句的执行计划都是正确的，可以测试环境中的统计信息导入到正式库中。

3.尽量少修改初始化参数。除了SGA的组成部分和归档目录的设置，其他初始化参数尽量保持默认值，可以为以后性能优化留下一定的余地。

4.通过设置数据库对象的存储参数来管理BLOCK的争用。

5.所有的sql语句应该被优化。

6.验证中间层软件和程序采用高效的方式连接数据库。

7.验证sql语句有效的利用游标。

8.确认所有方案的对象从开发环境移植到了产品数据库中。

9.一旦完成系统的切换，建立数据库和操作系统统计信息的基线。

10.发现最先出现的瓶颈。

这本书主要描述关于性能调整方面的概念、方法和基本工具。

根据文档的描述，这篇文档主要是针对OLTP系统的，对于DSS系统的调整在数据仓库文档中进行描述。

这篇文档从描述了SQL的执行计划、CBO/RBO策略、统计信息的收集、Hints和Outline的使用、Sql trace和Tkprof的介绍、内存和IO及其他系统资源的使用、Statspack的使用、网络的调整等和优化相关的各个方面的内容。

虽然做过一些优化的工作，但是这方面的概念和知识比较匮乏，希望看完这篇文档能巩固我这方面的基础知识。

2005-1-1

准备开始看Oracle的性能调整手册和参考的文档，结果发现，文档推荐首先看性能计划的文档，

这篇文档的篇幅很短，估计是性能调整的概念和基础知识。希望能使用2天左右的时间看完这篇文档。

2004-12-30

Oracle有两种工作模式：归档模式（ARCHIVELOG MODE）和非归档模式（NOARCHIVELOG MODE）。

只有归档模式支持联机备份（热备份），可以保证数据的不丢失。非归档模式只能采用冷备份或逻辑备份。一旦出现磁盘故障，必然会导致数据的丢失。因此，产品库应该运行在ARCHIVELOG模式下。

当出于归档模式时，联机重做日志切换后，需要对日志进行归档，如果等到联机重做日志循环重用这个日志文件的时候仍然发现这个日志没有进行归档操作，那么数据库将进入SUSPEND状态，直到联机重做日志归档完成。因此，保证归档操作的正确执行是十分关键的。

归档模式又分为自动归档和手工归档两种。一般情况下，都选择自动归档，手工归档的意义不大。

重做日志是Oracle系统的重要组成部分，通过重做日志记录Oracle所有的操作信息。

虽然重做日志十分重要，但是重做日志的管理并不复杂。为了保护重做日志，每个重做日志组应该至少包括2个成员（member），而且应该将重做日志的不同成员放到不同的磁盘上。为了保证Oracle可以及时的归档，至少应该包含3个日志组。出于性能的考虑，根据日志切换的时间间隔来确定日志文件的大小，一般半个小时切换一次比较合适。

控制文件中保存着下列信息：数据库名称、所有数据文件的名称和位置、数据库创建的时间、当前重做日志序号、检查点信息。

控制文件对数据库十分重要，如果控制文件丢失或破损，会造成数据库的无法启动。因此，Oracle推荐使用多个控制文件，并把多个控制文件放到不同的磁盘上，以此来保证控制文件的安全。如果重做日志组中的一个成员损坏，不会影响到数据库的运行，Oracle仅仅是在alert文件中记录这个信息，并不再向损坏的日志文件中写数据。但是，控制文件和重做日志不同，任何一个控制文件的损坏都会立时导致数据库发生错误。从这种情况考虑，多个控制文件反而增加了数据库发生错误的概率。

控制文件的大小由MAXDATAFILES, MAXLOGFILES, MAXLOGMEMBERS, MAXLOGHISTORY, MAXINSTANCES参数的值决定。可以通过查询视图V$CONTROLFILE_RECORD_SECTION得到当前控制文件中的值。

备份控制文件的方法：

数据库关闭时，直接拷贝控制文件；

数据库打开时，使用ALTER DATABASE BACKUP CONTROLFILE TO ‘dest’语句备份二进制文件，或者使用ALTER DATABASE BACKUP CONTROLFILE TO TRACE;语句，将重新生成控制文件的语句保存到trace文件中。

Oracle的服务器进程包括专用进程和共享进程。

Oracle的主要后台进程包括：DBWn、LGWR、CKPT、SMON、PMON、ARCn、RECO、Dnnn、LMS、CJQ0等。

Oracle在描述并行执行时，文档中有一个地方描述有误，文档上面说：

All subsequent DML (INSERT, UPDATE, DELETE), DDL (CREATE, ALTER), or query (SELECT) statements will not be parallelized after an ALTER SESSION DISABLE PARALLEL DML|DDL|QUERY statement is issued. They will be executed serially, regardless of any PARALLEL clause or parallel hints associated with the statement.

简单的说，就是ALTER SESSION DISABLE PARALLEL DML语句的优先级最高，它会覆盖表的PARALLEL子句和HINT的设置。但是通过实际测试发现，HINT的优先级大于ALTER SESSION语句大于表的并行语句。具体可以参考下面的例子。

 查看全文

Oracle在9i中提供了自动管理文件的功能，Oracle可以自动管理的文件包括：数据文件、临时文件、控制文件、联机重做日志文件。

Oracle在文档中是这样评价Oracle-Managed Files的优点的：简化管理数据库的操作、减少名称冲突的可能性、可以避免不再使用的数据文件浪费空间等。

不过这些所谓的优点似乎意义并不是很大，感觉Oracle的自动管理文件的真正用途还是10g中的自动存储管理（ASM）,9i中不过是提前实现了部分功能而已。

创建数据库前应该考虑清楚下列问题，这些设置在建立数据库后是无法修改或很难修改的：数据库名称、BLOCK的大小、字符集和时区、SYSTEM表空间是否采用本地管理等。

创建数据库可以使用Database Configuration Assistant（DBCA）或通过手工建立。

DBCA是一个图形化软件，通过和用户交互的方式来建立数据库、删除数据库或管理模板。

DBCA有有个silent模式，可以通过命令行的方式根据模板直接建立数据库。DBCA的静默模式建库可以参考：http://blog.itpub.net/post/468/11929

手工创建数据库的步骤：

1.确定数据库的SID，在windows系统上，还应该使用ORADIM -NEW -SID SID_NAME来建立相应的服务。

2.创建密码文件

3.建立初始化文件

4.连接并启动实例

5.使用CREATE DATABASE语句建立数据库

6.添加必要的表空间（可选）

7.执行catalog.sql和catproc.sql来建立数据字典

8.执行其他脚本安装一些附加的选项（可选）

9.创建spfile文件（可选）

10.备份数据库

11.将数据库的信息添加到tnsnames.ora和listener.ora中

在建立数据库时如果指定FORCE LOGGING，则Oracle对所有的操作都会记录重做日志，即使是在执行语句时指定了NOLOGGING的语句也不例外。设置FORCE LOGGING对于DATA GUIDE具有很大的好处。可以在数据库启动后更改该设置。

9i中的spfile提供了在数据库中修改初始化参数的方法，使用比pfile要方便得多。但是感觉Oracle对spfile的检查机制还不够，当通过alter system set parameter_name = value scope = spfile设置一些必须重起才能生效的存储参数时，很可能由于存储参数的错误造成Oracle的无法正常启动。

Oracle数据库用户可以分为几种：数据库管理员、安全管理员、网络管理员、应用程序开发程序员、应用程序管理员、数据库用户。

数据库管理员的任务：

1.评估数据库服务器的硬件

2.安装数据库软件

3.设计数据库

4.创建并打开数据库

5.备份数据库

6.登记系统用户

7.实施数据库的设计

8.数据库结构发生变化时，立即备份数据库

9.调整数据库性能

数据库的版本号如9.2.0.1.0由5部分组成，按照从前到后的顺序分别是：主数据库版本号、数据库维护版本号、应用服务器版本号、指定组件版本号、指定平台版本号。

数据库管理员的授权由两种方式：操作系统验证和密码文件验证。

Oracle会自动处理分布事务，保证分布事务的一致性，所有站点全部提交或全部回滚。一般情况下，处理过程在很短的时间内完成，根本无法察觉到。但是，如果在commit或rollback的时候，出现了连接中断或某个数据库站点CRASH的情况，则提交操作可能会无法继续，此时DBA_2PC_PENDING和DBA_2PC_NEIGHBORS中会包含尚未解决的分布事务。

对于绝大多数情况，当恢复连接或CRASH的数据库重新启动后，会自动解决分布式事务，不需要人工干预。只有分布事务锁住的对象急需被访问，锁住的回滚段阻止了其他事务的使用，网络故障或CRASH的数据库的恢复需要很长的时间等情况出现时，才使用人工操作的方式来维护分布式事务。

手工强制提交或回滚将失去二层提交的特性，Oracle无法继续保证事务的一致性，事务的一致性应由手工操作者保证。

对于分布式事务，给事务命名是一个好的习惯。而且在事务执行过程中，可以使用ALTER SESSION ADVISE COMMIT(ROLLBACK);语句，为手工解决分布事务提供参考信息。

当手工解决分布事务出现了冲突，比如一个站点进行了提交而另一个进行了ROLLBACK，这时，DBA_2PC_PENDING中的记录不会清除，必须使用DBMS_TRANSACTION.PURGE_MIXED过程来清除。

如果CRASH的数据库必须重建，或者无法再次启动，则DBA_2PC_PENDING中的记录也无法自动清除，需要使用DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY过程来清除。

Oracle9i中，当使用上述两个过程时，必须处于UNDO_MANAGEMENT＝MANUAL的模式，这个限制条件Oracle没有写到文档中。一般使用9i都会使用AUTO模式（Oracle也是这样推荐的），也就是说，想要清除DBA_2PC_PENDING中的信息，必须重起数据库两次，感觉这两个过程的实际用处不大。

出现无法解决的分布式事务时，可能会锁住分布式事务中涉及的表，由于Oracle无法确定哪些数据是提交过的，哪些是没有提交的，无法确定查询操作可见的结果集，因此，即使是查询操作也无法在该表上执行。

使用ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY，可以使Oracle不再自动解决分布事务，即使网络恢复连接或者CRASH的数据库重新启动。ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY恢复自动解决分布事务。

为了保证数据库之间的SCN同步，可以采用两种方法：在查询数据前，执行SELECT * FROM DUAL@REMOTE或者在执行查询前提交或回滚当前事务。

数据仓库中使用约束一般出于两个目的：数据清理和查询优化。

建立约束的三种用途：强制（ENFORCEMENT）、验证（VALIDATION）和信任（BELIEF）。

强制保证所有对表的修改都满足约束条件，索引处于ENABLE状态。

验证保证表中当前存在的数据都满足约束条件，索引处于VALIDATE状态。

信任是使Oracle的优化器相信存在完整性约束，但是并不去验证。

数据仓库环境中，为了避免无意义的唯一索引的建立，唯一约束经常以DISABLE VALIDATE状态建立。

数据仓库环境中，为了验证约束的开销，外键约束经常以ENABLE NOVALIDATE状态建立。

在可以保证数据的完整性的情况下，有时会建立RELY DISABLE NOVALIDATE约束，这种约束没有额外开销，但可以使Oracle的优化器信任约束的存在，为查询重新提供必要的信息。

另外：视图上只能建立RELY约束。

在数据仓库系统中，最为广泛使用的索引类型是BITMAP索引。和BTREE索引相比，BITMAP索引更加适合数据仓库环境。

在数据仓库系统中，BITMAP系统具有以下优势：

减少大级别特别查询的响应时间；和其他类型的索引相比，减少了对存储空间占用；即使在CPU和内存资源相对较少的环境下，仍可以大幅度地提升性能；使用并行DML或LOAD时，BITMAP索引维护具有很高的效率。

BITMAP索引适用于集势（选择性）较低的列，也就是说，具有较多重复值的列。一般来说，degree of cardinality应小于1%。计算degree of cardinality的方法：

select count(distict column_name)/count(*) from table_name;

BITMAP索引的一些特点：BITMAP索引包括NULL值；只有CBO模式，才会使用BITMAP索引；分区表的BITMAP索引只能是LOCAL的。

BITMAP连接索引在建立索引时，把两张表通过主外键连接起来，在执行查询时，就可以直接访问索引从而避免表连接。和具有类似功能的物化视图相比，BITMAP连接索引占用的空间要少得多。

另外：文档中关于BITMAP索引部分的例子至少错了两个地方，尤其是后一个关于BITMAP连接索引的例子，例子和文字的描述不一致，如果以前对这部分不是很了解，很容易别误导。

BTREE索引在数据仓库中的应用要少一些。主要用在唯一或接近唯一的列上。

对于分区表，LOCAL索引比GLOBAL索引更适合数据仓库环境，GLOBAL索引只创建在LOCAL索引无法满足条件时。

和OLTP系统相比，并行和分区技术更多的应用在数据仓库系统中。

在DSS或DATA WAREHOUSING系统中，类似包含多个表连接查询操作或对非常大的表查询操作，都适合并行执行。

并行执行可以提高几种操作的性能：大表的扫描和连接、创建大的索引、分区索引扫描、大批量插入更新和删除、聚集和拷贝操作。使用并行执行的系统应具备的条件：SMP（对称多处理器）、足够的I/O带宽、未充分利用的CPU资源、足够的内存。

并行执行的基本颗粒度有两种：一种是基于block的范围，一种是基于分区。

分区包括范围分区、哈希分区、列表分区、范围哈希分区、范围列表分区。其中范围分区，尤其是基于时间的范围分区在数据仓库系统中最常使用。

Partition pruning和Partition-wise joins是数据仓库系统中，分区表带来性能提升的主要因素。

Partition pruning是指在执行查询操作中，可以根据WHERE语句中的条件，直接将查询范围定位到分区上。将全表扫描变成对某个或某几个分区的全扫描，或将全索引扫描变为某个索引分区的扫描，通过这种方法来提升查询的性能。

Partition-wise joins是指在连接查询时，两个分区表对应的分区之间直接连接。将两张大表的连接转化为多个分区对的连接，减少了对内存的消耗，在并行执行时，由于分区对之间不需要额外的通信负担，Partition-wise joins可以减少响应时间，提高查询性能。

这一章描述了分布事务的一些基本概念。

Local Coordinator：在分布事务中，必须参考其它节点上的数据才能完成自己这部分操作的站点。

Global Coordinator：分布事务的发起者，负责协调这个分布事务。

Commit Point Site：在分布事务中，首先执行COMMIT或ROLLBACK操作的站点。一般情况下，应该把存储关键数据的站点作为Commit Point Site。因为Commit Point Site和其他站点不一样，不会存在IN-DOUBT事务。

可以设置初始化参数COMMIT_POINT_STRENGTH，在分布式事务中，会根据这个值的大小来确定Commit Point Site。

分布式事务包括三个阶段：准备阶段（Prepare Phase）、提交阶段（Commit Phase）和遗忘阶段（Forget Phase）。

在准备阶段，Global Coordinator指导除Commit Point Site的所有参与分布事务的站点进行准备工作。如果任何一个分布站点无法完成准备工作，则Global Coordinator会对每个站点发出会滚消息。如果所有站点都准备好了，则会将消息发给Global Coordinator。

Global Coordinator指导Commit Point Site提交事务，收到成功消息后，Global Coordinator给每个节点都发出COMMIT消息。

当Global Coordinator收到每个节点都执行完COMMIT操作后发回的消息，它通知Commit Point Site，这两个站点清除分布事务的记录。

这一章主要描述了开发一个分布式应用程序应该注意那些问题。

分布式查询语句会在回滚断上放置事务锁，必须通过COMMIT和ROLLBACK来释放这个锁。

Oracle无法在不同数据库间建立完整性约束，可以通过建立触发器来实现这个功能，不过使用触发器会带来新的问题——网络连接断开将同时影响到两个服务器上面的DML操作。

优化分布式查询可以采用collocated inline view，如果对相应的表进行分析后，基于代价的优化器无法得到正确的执行计划，可以使用NO_MERGE或DIVING_SITE这两个hints来强制Oracle选择指定的查询方案。

在这一章阅读过程中，发现两个地方和文档的描述有出入。

1.在介绍分布式系统的参考系约束时，文档上有这么一段描述：

If a part of a distributed statement fails, for example, due to an integrity constraint violation, Oracle returns error number ORA-02055. Subsequent statements or procedure calls return error number ORA-02067 until a rollback or rollback to savepoint is issued.

但是根据文档的描述，无法模拟出这个错误。或许是我的理解有误，或许是只有在特定的条件下才能模拟出这个错误。

2.在处理远端存储过程错误这部分，有如下描述：

When calling a remote procedure, exceptions can be handled by an exception handler in the local procedure. The remote procedure must return an error number to the local, calling procedure, which then handles the exception as shown in the previous example. Note that PL/SQL user-defined exceptions always return ORA-06510 to the local procedure.

Therefore, it is not possible to distinguish between two different user-defined exceptions based on the error number. All other remote exceptions can be handled in the same manner as local exceptions.

但是通过测试发现，本地可以处理远端存储过程自定义的异常。

SQL> conn yangtk/yangtk@test
已连接。
SQL> create or replace procedure p_test(p_para in number) as
  2  begin
  3  if p_para = 0 then
  4  raise_application_error(-20001, 'Error one');
  5  else
  6  raise_application_error(-20002, 'Error two');
  7  end if;
  8  end;
  9  /

过程已创建。

SQL> conn yangtk/yangtk@test4
已连接。
SQL> create or replace procedure p_test_local(p_para in number) as
  2  null_salary exception;
  3  too_many_rows exception;
  4  pragma exception_init(null_salary, -20001);
  5  pragma exception_init(too_many_rows, -20002);
  6  begin
  7  p_test@test(p_para);
  8  exception
  9  when null_salary then
 10  dbms_output.put_line(sqlcode || ':' || sqlerrm);
 11  when too_many_rows then
 12  dbms_output.put_line(sqlcode || ':' || sqlerrm);
 13  end;
 14  /

过程已创建。

SQL> set serveroutput on
SQL> exec p_test_local(0);
-20001:ORA-20001: Error one
ORA-06512: 在"YANGTK.P_TEST", line 4

PL/SQL 过程已成功完成。

SQL> exec p_test_local(1);
-20002:ORA-20002: Error two
ORA-06512: 在"YANGTK.P_TEST", line 6

PL/SQL 过程已成功完成。

这一章看完后，对数据库链的了解更深了一步，对于分布式事务有了一点认识，而且上一章留下的疑问也找到了变通的解决方法。

总结了一些关于数据库链的小技巧和容易出现问题的地方。

http://blog.itpub.net/post/468/8699

http://blog.itpub.net/post/468/8743

http://blog.itpub.net/post/468/9547

http://blog.itpub.net/post/468/9662

当然，问题也还是有的。文章的一开始就出现了一个错误。文档上面说，创建数据库链时，是否必须采用GLOBAL_NAME名称与远端站点的设置有关，但测试证明，这是和本地GLOBAL_NAMES的设置有关。测试如下：

SQL> CONN YANGTK/YANGTK@YANGTK
已连接。
SQL> SHOW PARAMETER GLOBAL

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
global_context_pool_size             string
global_names                         boolean     TRUE
SQL> CONN YANGTK/YANGTK@DICSYS
已连接。
SQL> SHOW PARAMETER GLOBAL_NAME

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
global_names                         boolean     FALSE
SQL> CREATE DATABASE LINK ABC CONNECT TO YANGTK IDENTIFIED BY YANGTK USING 'YANGTK';

数据库链接已创建。

SQL> SELECT * FROM TAB@ABC;

TNAME                          TABTYPE  CLUSTERID
------------------------------ ------- ----------
CHAINED_ROWS                   TABLE
DEPT                           TABLE
DIVISION1_STAFF                VIEW
EMP                            TABLE
EXCEPTIONS                     TABLE
ORDER_HIST                     TABLE
SYNONYM_EMP                    SYNONYM
TEST                           TABLE
TESTA                          TABLE
TEST_CHAR                      TABLE
TEST_CHAR2                     TABLE
TRIAL                          TABLE            1
TRIAL_CLUSTER                  CLUSTER
V_TEST                         VIEW

已选择14行。

SQL> CONN YANGTK/YANGTK@YANGTK
已连接。
SQL> CREATE DATABASE LINK BBB CONNECT TO YANGTK IDENTIFIED BY YANGTK USING 'DICSYS';

数据库链接已创建。

SQL> SELECT * FROM TAB@BBB;
SELECT * FROM TAB@BBB
                  *
ERROR 位于第 1 行:
ORA-02085: 数据库链接BBB.YANGTINGKUN与DICSYS.YANGTINGKUN相连结

对于shared数据库链也有一个不大清楚的地方，为什么非要增加AUTHENTICATED BY语句，感觉实在是没有什么意义。也许是为了以后扩展？

另外，在close数据库链之后查询v$dblink时出现一次ORA-600，Oracle的数据库链部分还是有一些小问题。

根据资源瓶颈的不同，可以把系统分为两种类型，CPU绑定型和I、O绑定型。

OLTP系统的瓶颈主要来自用户工作负荷已经应用程序访问模式，属于CPU绑定型。而数据仓库系统更加关心I/O性能，属于I/O绑定型。

RAID0：对磁盘进行STRIPING，没有冗余，具有最好的写性能和比较好的读性能。

RAID1：对磁盘镜像，冗余100％，系统会自动选择反应较快的磁盘，因此具有最好的读性能，写性能和普通磁盘相同。

RAID0+1：先对磁盘进行STRIPING然后做镜像，在RAID系统中具有最好的性能。

RAID5：多块磁盘进行奇偶校验，为了避免单一磁盘成为瓶颈，将奇偶校验分散到各个磁盘中。一般来说，高并发写入性能较差。

看完这一章，主要的问题都集中在database link上面。

从连接用户角度讲，database link可以分为三种：

1.建立数据库链时不指定CONNECT TO语句，这时数据库链是以当前连接用户访问远端站点。

优点：可以不用把用户名、密码存储到数据库中。

缺点：本地数据库和远端数据库必须具有相同的用户名和密码。而且如果将这种数据库链放到视图、同义词或存储过程中，通过这种视图、同义词和存储过程访问对象时，可能和当前的连接用户有关，而这可能并不是你想要的结果。

2.建立数据库链时指定CONNECT TO USERNAME IDENTIFIED BY PASSWORD语句，这时数据库链以固定用户访问远端站点。

优点：简单明确，任何用户使用这个数据库链（public）得到的结果都是一致的。一般这种情况是平常最常使用的方式。

缺点：必须把远端用户名密码以明文方式保存在本地数据字典中。这是一个安全隐患。

3.建立数据库链时指定CONNECT TO CURRENT_USER，这时数据库链以当前的全局用户（global user）连接远端站点。

这种数据库链必须建立global用户，这种用户的授权是在数据库外面的LDAP-based directory service中。这种方式需要建立额外的目录服务，配置比较负责，适合具有多个数据库的大型系统。关于这方面内容，oracle专门在Oracle Advanced Security Administrator’s Guide中进行了描述，这部分内容还没有看过，更没有进行过测试。

对于数据库链，有两个问题还有一些疑问：