Author: mac

Oracle数据库的发行版本号(release number)一般由五位数字组成，那么这些数字分别代表什么含义呢？ Major Database Release Number 第一位阿拉伯数字是我们最常提到的一个大版本标识，它代表了数据库主要发行版本号；譬如我们说的10g不管是R1还是R2，其版本号的第一位总是10；不同Major release Number之间预示着存在功能上的巨大差别，例如在11g中加入了许多10g上永远不会有的新特性。新的major release number表明这是崭新一代的产品。 Database Maintenance Release Number 第二位阿拉伯数字代表数据库维护版本发行号，也就是我们常说的R1或者R2。已有的Maintenance Release Number包括:8.1(比较特殊)、9.1、9.2、10.1、10.2和11.1、11.2。从9i开始每一个大版本都有2个release，一般来说R1总是显得不那么稳定(至少11g之前是这样)，通过在R1中引入大量特性后发行并根据用户实际使用情况不断修正Bug，到R2发行时R1中引入的新特性已经日渐成熟，当然按照Oracle的风格在R2中还会引入部分特性，一些特性甚至可能是颠覆性的(例如10.2.0.2中引入mutex保护的Cursor pin)。另外值得一提的是R1极不稳定这个铁律似乎在11g中被打破了，11gR1的使用率非常之高，这是9.1或10.1所不能想象的。 Application Server Release Number 第三位阿拉伯数字代表了Oracle Application Server (OracleAS)的发行版本号；对于Oracle database软件而言这一位总是为0 Component-Specific Release Number 第四位阿拉伯数字代表了某个组件的发行版本号。这里说的组件是指我们在使用DBCA创建数据库是选择安装的Component，例如Oracle OLAP、Label Security等(如果是手动创建数据库，那么必然运行了安装组件的脚本，一般位于$ORACLE_HOME/rdbms/admin目录下)取决于数据库上所打过的Component Patch set补丁集或interim release临时版本，同一个数据库中不同组件可能存在不同的组件版本号。实际使用中该组件发行版本号一般被我们用来指代数据库软件或者某个数据库所打过的Patch set补丁集，Patch set补丁集一般都是些大家伙(1-2GB不稀奇)。在给数据库软件打上Patch set后我们需要给已经存在的数据库升级组件版本，通俗地说是给数据库升级数据字典，这样数据库内的组件版本一般是一致的，如我将一个10.2.0.1的数据库升级到10.2.0.4，那么这个数据库里的组件版本也会是10.2.0.4(不排除说你为某个组件打了特殊的Patch后造成这个组件的版本独树一帜，当然这很少见，也不推荐)。我们可以通过查询DBA_SERVER_REGISTRY视图来了解数据库中的组件版本情况: desc dba_server_registry; Name Null? Type —————————————– ——– —————————- COMP_ID NOT NULL VARCHAR2(30) COMP_NAME VARCHAR2(255) VERSION…

每一个Oracle的初学者在入门阶段都会接触到SGA/PGA的知识，如果是从10g开始学习那么会多或少会对ASMM有所了解，从使用的角度来说ASMM的出现极大地简化了Oracle内存初始化参数的设置，在ASMM的使用上高级DBA和初学者不会有太大的差别；很多人因此而认为ASMM极大程度地减少了数据库对于专业DBA的依赖：如果我们有一个足够智能的DB，那么为什么还要花费金钱雇佣DBA呢？这似乎是时下一种十分流行的想法。当然这种想法我个人是不能苟同的，ASMM一定程度上带来了便利，更大程度上它是一个黑盒，黑盒里面藏了很多秘密，这些秘密带来比手动管理更多的不确定性；在10g release 1和10.2的早期版本中ASMM扮演的角色有点像一个闯祸精，另一个让用户对ASMM很不待见的原因是ASMM直接拖慢了startup的速度。一个个人观点是ASMM也好AMM也罢，都要求产品数据库DBA掌握更多SGA/PGA相关的知识才能成功”驾驭”这些”有智力”的家伙，有点夸张的说这个时候的DBA很像一个chemist(需要和一大堆以1个或2个下划线开头的奇怪参数打交道)。 为了不辱使命我们真的有必要了解一下ASMM的基本知识，显然这并不是一件容易的事情…… Oracle的SGA基本内存组件从9i开始并没有非常大的变化，他们包括: Buffer Cache 我们常说的数据库高速缓存，虽然我一直不明白要冠以高速之名 Default Pool                  默认的缓冲池，大小由DB_CACHE_SIZE决定 Keep Pool                     持久的缓冲池，大小由DB_KEEP_CACHE_SIZE决定 Non standard pool         非标准块标准池，大小由DB_nK_cache_size决定 Recycle pool                 回收池，大小由db_recycle_cache_size决定 Shared Pool 共享池，大小由shared_pool_size决定 Library…

sqlplus应当是DBA 1.0时代使用最为频繁的管理工具，经常有经验丰富的老DBA会提到自己敲过几万次的sqlplus:)，但有的时候这个吃饭家伙也会不好用，偶尔还会出现Segmentation fault错误，亦或者彻底hang住。在这里我介绍几种应对sqlplus无法正常使用的应对方法: 1.出现Segmentation fault，这种情况下一般是sqlplus 2进制文件被损坏了，可以通过重新build一个sqlplus来解决问题 [oracle@rh2 bin]$ sqlplus Segmentation fault /* 使用$ORACLE_HOME/sqlplus/lib目录下的make文件，编译一个新的sqlplus */ [oracle@rh2 ~]$ make -f $ORACLE_HOME/sqlplus/lib/ins_sqlplus.mk newsqlplus Linking /s01/oracle/product/11.2.0/dbhome_1/sqlplus/bin/sqlplus rm -f /s01/oracle/product/11.2.0/dbhome_1/sqlplus/bin/sqlplus gcc -o /s01/oracle/product/11.2.0/dbhome_1/sqlplus/bin/sqlplus -m64 -L/s01/oracle/product/11.2.0/dbhome_1/sqlplus/lib/ -L/s01/oracle/product/11.2.0/dbhome_1/lib/ -L/s01/oracle/product/11.2.0/dbhome_1/lib/stubs/ /s01/oracle/product/11.2.0/dbhome_1/sqlplus/lib/s0afimai.o -lsqlplus -lclntsh `cat /s01/oracle/product/11.2.0/dbhome_1/lib/ldflags` -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnro11 `cat /s01/oracle/product/11.2.0/dbhome_1/lib/ldflags` -lncrypt11 -lnsgr11 -lnzjs11 -ln11 -lnl11 -lnnz11 -lzt11 -lztkg11 -lztkg11 -lclient11…

几天前被问到关于rman catalog兼容性的问题，catalog所在数据库版本与目标数据库版本不同会有影响吗？在我概念当中catalog所在数据库的版本并不会影响rman catalog的使用，但catalog schema的版本却有着明确要求，至于具体的兼容关系就不清楚了。 查了下MOS找到文档<RMAN Compatibility Matrix>,这个文档解释地比较清楚，存在3个基本的原则： RMAN可执行文件的版本需要和target database目标数据库的版本一致(弱一致要求)，具体的合法组合如下面列出的表格 RMAN catalog schema版本必须大于等于RMAN可执行文件(强一致要求) RMAN catalog对target database目标数据库向后兼容，即支持早期版本的目标数据库 具体的可用版本组合: Target/Auxiliary Database RMAN Executable Catalog Database Catalog Schema 8.1.7.4 8.1.7.4 >=8.1.7 8.1.7.4 8.1.7.4 8.1.7.4 >=8.1.7 >=9.0.1.4 9.0.1 9.0.1 >=8.1.7 >= RMAN executable 9.2.0 >=9.0.1.3 and <= Target database >=8.1.7 >= RMAN executable 10.1.0 >=9.0.1.3 and <= Target database >=9.0.1…

我们在查看10704 event trace(Print out information about what enqueues are being obtained)或deadlock detected trace死锁检测跟踪日志时，总是会看到名为”DID”的名词，影响”DID”这个名词被正确理解的一个原因是你很难通过search engine正确找到相关的正确解释(被误解)。 那么DID到底是什么东西呢？我们来看一下trace中的DID: =====================10704 enqueue trace======================== ksqgtl *** CU-913f5a28-00000000 mode=6 flags=0x10010 timeout=300 *** ksqgtl: no transaction ksqgtl: use existing ksusetxn DID ksqgtl: ksqlkdid: 0002-001E-00000026 *** 2011-05-09 23:44:15.210 *** ksudidTrace: ksqgtl ksusesdi: 0002-001E-00000025 ksusetxn: 0002-001E-00000026 ksqgtl: RETURNS 0 *** 2011-05-09 23:44:15.212 ksqrcl: CU,913f5a28,0 ksqrcl:…

客户有一套AIX 5.3上的10.2.0.4.5生产库系统，最近频繁出现”KKSFBC CHILD COMPLETION”等待，同时导致session不断spin消耗CPU并hang住，从表象看这似乎是由bug引起的。以KKSFBC CHILD COMPLETION为关键字到MOS查询可以找到<Bug 6795880 – Session spins / OERI after ‘kksfbc child completion’ wait – superceded [ID 6795880.8]>,该Bug的症状为进程不断spin且hang住、出现’KKSFBC CHILD COMPLETION’等待事件、还可能伴有’Waits for “cursor: pin S”‘等待事件，直接影响的版本有11.1.0.6、10.2.0.3和10.2.0.4。 对于该Bug的描述是在发生’kksfbc child completion’等待事件后会话陷入无休止的自旋(spins)中，这种自旋(spins)发生在由堆栈调用(stack call)kksSearchChildList->kkshgnc陷入对kksSearchChildList函数的无限循环中。 就当前用户提供的版本号及等待事件信息仍不足以定位到该Bug，我们需要更详细的stack call。所幸的是这个trouble是可以重现的(reproduceable),在之后的一次案发现场我们得到了必要的信息: Name PID CPU% PgSp Owner oracle 3723390 10.0 7.0 oracle SQL> oradebug setospid 3723390 Oracle pid: 155, Unix process pid: 3723390, image:…

编 写 人:            Oracle ACS技术顾问 杜平     Oracle  安全备份简介   Oracle 的安全备份，是 oracle 公司提供可为整个 IT 环境提供集中磁带备份管理的软件。它利用 高度可扩展的客户端-服务器体系结构，管理遍布于数据中心和远程办公地点的异构服务器的数据保 护，以解决由数据库和文件系统数据组成的分布式环境的复杂性的数据备份： Oracle 数据库与 Recovery Manager (RMAN) 集成，支持从 Oracle9i 到 Oracle11g 等数据库版本， 有令同类介质管理产品望尘莫及的优化性能（备份速度提高 25-40%，CPU 利用率降低 10%） 文件系统数据保护：UNIX / Windows / Linux 服务器和网络连接存储 (NAS) 企业 IT 环境可能需要将数百个服务器备份到大量的物理或虚拟磁带设备上，从而导致要在同城或 异地根据不同保留期限来保留数千个备份磁带。Oracle 安全备份通过一个通用管理界面解决了这些 复杂性，它可以跨越各种服务器并利用基于策略的管理，从而允许细粒度控制磁带介质和备份域。 其他同类产品都单独许可高级特性、服务器数量和规模以及数据库集成，但 Oracle 安全备份不会 这么做！Oracle 安全备份可提供全面的数据保护管理，将企业级特性和 Oracle 数据库集成在一个 低成本解决方案中。   1.1…

很多人怀念那个界面十分古典、可以迅速打开的html版Metalink，在Oracle让My Oracle Support来代替Metalink后仍提供了一个旧版Metalink的入口,很多人在沿用这个入口，但也有很多朋友不知道还有这个玩样！ 这个入口在这里https://supporthtml.oracle.com，让我们回到过去！  

L1 cache reference 0.5 ns Branch mispredict 5 ns L2 cache reference 7 ns Mutex lock/unlock 100 ns Main memory reference 100 ns Compress 1K bytes with Zippy 10,000 ns Send 2K bytes over 1 Gbps network 20,000 ns Read 1 MB sequentially from memory 250,000 ns Round trip within same datacenter 500,000 ns Disk…

作者：Simon Tatham 专业的自由软件程序员 翻译：Dasn 为公众写过软件的人，大概都收到过很拙劣的bug（计算机程序代码中的错误或程序运行时的瑕疵——译者注）报告，例如： 在报告中说“不好用”； 所报告内容毫无意义； 在报告中用户没有提供足够的信息； 在报告中提供了错误信息； 所报告的问题是由于用户的过失而产生的； 所报告的问题是由于其他程序的错误而产生的； 所报告的问题是由于网络错误而产生的； 这便是为什么“技术支持”被认为是一件可怕的工作，因为有拙劣的bug报告需要处理。然而并不是所有的bug报告都令人生厌：我在业余时间维护自由软件，有时我会收到非常清晰、有帮助并且“有内容”的bug报告。 在这里我会尽力阐明如何写一个好的bug报告。我非常希望每一个人在报告bug之前都读一下这篇短文，当然我也希望用户在给我报告bug之前已经读过这篇文章。 简单地说，报告bug的目的是为了让程序员看到程序的错误。您可以亲自示范，也可以给出能导致程序出错的、详尽的操作步骤。如果程序出错了，程序员会收集额外的信息直到找到错误的原因；如果程序没有出错，那么他们会请您继续关注这个问题，收集相关的信息。 在bug报告里，要设法搞清什么是事实（例如：“我在电脑旁”和“XX出现了”）什么是推测（例如：“我想问题可能是出在……”）。如果愿意的话，您可以省去推测，但是千万别省略事实。 当您报告bug的时候（既然您已经这么做了），一定是希望bug得到及时修正。所以此时针对程序员的任何过激或亵渎的言语（甚至谩骂）都是与事无补的——因为这可能是程序员的错误，也有可能是您的错误，也许您有权对他们发火，但是如果您能多提供一些有用的信息（而不是激愤之词）或许bug会被更快的修正。除此以外，请记住：如果是免费软件，作者提供给我们已经是出于好心，所以要是太多的人对他们无礼，他们可能就要“收起”这份好心了。 “程序不好用” 程序员不是弱智：如果程序一点都不好用，他们不可能不知道。他们不知道一定是因为程序在他们看来工作得很正常。所以，或者是您作过一些与他们不同的操作，或者是您的环境与他们不同。他们需要信息，报告bug也是为了提供信息。信息总是越多越好。 许多程序，特别是自由软件，会公布一个“已知bug列表”。如果您找到的bug在列表里已经有了，那就不必再报告了，但是如果您认为自己掌握的信息比列表中的丰富，那无论如何也要与程序员联系。您提供的信息可能会使他们更简单地修复bug。 本文中提到的都是一些指导方针，没有哪一条是必须恪守的准则。不同的程序员会喜欢不同形式的bug报告。如果程序附带了一套报告bug的准则，一定要读。如果它与本文中提到的规则相抵触，那么请以它为准。 如果您不是报告bug，而是寻求帮助，您应该说明您曾经到哪里找过答案，（例如：我看了第四章和第五章的第二节，但我找不到解决的办法。）这会使程序员了解用户喜欢到哪里去找答案，从而使程序员把帮助文档做得更容易使用。 “演示给我看” 报告bug的最好的方法之一是“演示”给程序员看。让程序员站在电脑前，运行他们的程序，指出程序的错误。让他们看着您启动电脑、运行程序、如何进行操作以及程序对您的输入有何反应。 他们对自己写的软件了如指掌，他们知道哪些地方不会出问题，而哪些地方最可能出问题。他们本能地知道应该注意什么。在程序真的出错之前，他们可能已经注意到某些地方不对劲，这些都会给他们一些线索。他们会观察程序测试中的每一个细节，并且选出他们认为有用的信息。 这些可能还不够。也许他们觉得还需要更多的信息，会请您重复刚才的操作。他们可能在这期间需要与您交流一下，以便在他们需要的时候让bug重新出现。他们可能会改变一些操作，看看这个错误的产生是个别问题还是相关的一类问题。如果您不走运，他们可能需要坐下来，拿出一堆开发工具，花上几个小时来好好地研究一下。但是最重要的是在程序出错的时候让程序员在电脑旁。一旦他们看到了问题，他们通常会找到原因并开始试着修改。 “告诉我该怎么做” 如今是网络时代，是信息交流的时代。我可以点一下鼠标把自己的程序送到俄罗斯的某个朋友那里，当然他也可以用同样简单的方法给我一些建议。但是如果我的程序出了什么问题，我不可能在他旁边。“演示”是很好的办法，但是常常做不到。 如果您必须报告bug，而此时程序员又不在您身边，那么您就要想办法让bug重现在他们面前。当他们亲眼看到错误时，就能够进行处理了。 确切地告诉程序员您做了些什么。如果是一个图形界面程序，告诉他们您按了哪个按钮，依照什么顺序按的。如果是一个命令行程序，精确的告诉他们您键入了什么命令。您应该尽可能详细地提供您所键入的命令和程序的反应。 把您能想到的所有的输入方式都告诉程序员，如果程序要读取一个文件，您可能需要发一个文件的拷贝给他们。如果程序需要通过网络与另一台电脑通讯，您或许不能把那台电脑复制过去，但至少可以说一下电脑的类型和安装了哪些软件（如果可以的话）。 “哪儿出错了？在我看来一切正常哦！” 如果您给了程序员一长串输入和指令，他们执行以后没有出现错误，那是因为您没有给他们足够的信息，可能错误不是在每台计算机上都出现，您的系统可能和他们的在某些地方不一样。有时候程序的行为可能和您预想的不一样，这也许是误会，但是您会认为程序出错了，程序员却认为这是对的。 同样也要描述发生了什么。精确的描述您看到了什么。告诉他们为什么您觉得自己所看到的是错误的，最好再告诉他们，您认为自己应该看到什么。如果您只是说：“程序出错了”，那您很可能漏掉了非常重要的信息。 如果您看到了错误消息，一定要仔细、准确的告诉程序员，这确实很重要。在这种情况下，程序员只要修正错误，而不用去找错误。他们需要知道是什么出问题了，系统所报的错误消息正好帮助了他们。如果您没有更好的方法记住这些消息，就把它们写下来。只报告“程序出了一个错”是毫无意义的，除非您把错误消息一块报上来。 特殊情况下，如果有错误消息号，一定要把这些号码告诉程序员。不要以为您看不出任何意义，它就没有意义。错误消息号包含了能被程序员读懂的各种信息，并且很有可能包含重要的线索。给错误消息编号是因为用语言描述计算机错误常常令人费解。用这种方式告诉您错误的所在是一个最好的办法。 在这种情形下，程序员的排错工作会十分高效。他们不知道发生了什么，也不可能到现场去观察，所以他们一直在搜寻有价值的线索。错误消息、错误消息号以及一些莫名其妙的延迟，都是很重要的线索，就像办案时的指纹一样重要，保存好。 如果您使用UNIX系统，程序可能会产生一个内核输出（coredump）。内核输出是特别有用的线索来源，别扔了它们。另一方面，大多数程序员不喜欢收到含有大量内核输出文件的EMAIL，所以在发邮件之前最好先问一下。还有一点要注意：内核输出文件记录了完整的程序状态，也就是说任何秘密（可能当时程序正在处理一些私人信息或秘密数据）都可能包含在内核输出文件里。 “出了问题之后，我做了……” 当一个错误或bug发生的时候，您可能会做许多事情。但是大多数人会使事情变的更糟。我的一个朋友在学校里误删了她所有的Word文件，在找人帮忙之前她重装了Word，又运行了一遍碎片整理程序，这些操作对于恢复文件是毫无益处的，因为这些操作搞乱了磁盘的文件区块。恐怕在这个世界上没有一种反删除软件能恢复她的文件了。如果她不做任何操作，或许还有一线希望。 这种用户仿佛一只被逼到墙角的鼬（黄鼠狼、紫貂一类的动物——译者注）：背靠墙壁，面对死亡的降临奋起反扑，疯狂攻击。他们认为做点什么总比什么都不做强。然而这些在处理计算机软件问题时并不适用。 不要做鼬，做一只羚羊。当一只羚羊面对料想不到的情况或受到惊吓时，它会一动不动，是为了不吸引任何注意，与此同时也在思考解决问题的最好办法（如果羚羊有一条技术支持热线，此时占线。）。然后，一旦它找到了最安全的行动方案，它便去做。 当程序出毛病的时候，立刻停止正在做的任何操作。不要按任何健。仔细地看一下屏幕，注意那些不正常的地方，记住它或者写下来。然后慎重地点击“确定” 或“取消”，选择一个最安全的。学着养成一种条件反射——一旦电脑出了问题，先不要动。要想摆脱这个问题，关掉受影响的程序或者重新启动计算机都不好，一个解决问题的好办法是让问题再次产生。程序员们喜欢可以被重现的问题，快乐的程序员可以更快而且更有效率的修复bug。 “我想粒子的跃迁与错误的极化有关” 并不只是非专业的用户才会写出拙劣的bug报告，我见过一些非常差的bug报告出自程序员之手，有些还是非常优秀的程序员。 有一次我与另一个程序员一起工作，他一直在找代码中的bug，他常常遇到一个bug，但是不会解决，于是就叫我帮忙。“出什么毛病了？”我问。而他的回答却总是一些关于bug的意见。如果他的观点正确，那的确是一件好事。这意味着他已经完成了工作的一半，并且我们可以一起完成另一半工作。这是有效率并有用的。 但事实上他常常是错的。这就会使我们花上半个小时在原本正确的代码里来回寻找错误，而实际上问题出在别的地方。我敢肯定他不会对医生这么做。“大夫，我得了Hydroyoyodyne（真是怪病——译者），给我开个方子”，人们知道不该对一位医生说这些。您描述一下症状，哪个地方不舒服，哪里疼、起皮疹、发烧……让医生诊断您得了什么病，应该怎样治疗。否则医生会把您当做疑心病或精神病患者打发了，这似乎没什么不对。 做程序员也是一样。即便您自己的“诊断”有时真的有帮助，也要只说“症状”。“诊断”是可说可不说的，但是“症状”一定要说。同样，在bug报告里面附上一份针对bug而做出修改的源代码是有用处的，但它并不能替代bug报告本身。 如果程序员向您询问额外的信息，千万别应付。曾经有一个人向我报告bug，我让他试一个命令，我知道这个命令不好用，但我是要看看程序会返回一个什么错误（这是很重要的线索）。但是这位老兄根本就没试，他在回复中说“那肯定不好用”，于是我又花了好些时间才说服他试了一下那个命令。 用户多动动脑筋对程序员的工作是有帮助的。即使您的推断是错误的，程序员也应该感谢您，至少您想去帮助他们，使他们的工作变的更简单。不过千万别忘了报告“症状”，否则只会使事情变得更糟。 “真是奇怪，刚才还不好用，怎么现在又好了？” “间歇性错误”着实让程序员发愁。相比之下，进行一系列简单的操作便能导致错误发生的问题是简单的。程序员可以在一个便于观察的条件下重复那些操作，观察每一个细节。太多的问题在这种情况下不能解决，例如：程序每星期出一次错，或者偶然出一次错，或者在程序员面前从不出错（程序员一离开就出错。——译者）。当然还有就是程序的截止日期到了，那肯定要出错。 大多数“间歇性错误”并不是真正的“间歇”。其中的大多数错误与某些地方是有联系的。有一些错误可能是内存泄漏产生的，有一些可能是别的程序在不恰当的时候修改某个重要文件造成的，还有一些可能发生在每一个小时的前半个小时中（我确实遇到过这种事情）。 同样，如果您能使bug重现，而程序员不能，那很有可能是他们的计算机和您的计算机在某些地方是不同的，这种不同引起了问题。我曾写过一个程序，它的窗口可以蜷缩成一个小球呆在屏幕的左上角，它在别的计算机上只能在…