Author: mac

客户的某套系统上有一个表空间近日使用率异常增长，该表空间用以存储索引段，经过定位发现一个原本只有200M左右的索引使用将近30+G的空间，而且表现为绝大多数是未格式化的数据块。以下为通过 show_space脚本收集的段信息： Unformatted Blocks = 1772568 Blocks with 00-25% free space = 0 Blocks with 26-50% free space = 2173 Blocks with 51-75% free space = 0 Blocks with 76-100% free space = 0 Full Blocks = 60762 Unformatted Blocks总数1772568,共使用1772568*16k=27G. 一个索引占用如此多的未格式化块似乎不可思议，首先想到的可能是一个威力惊人的Bug。 探索MOS，可以发现以下这个有趣的note: Applies to: Oracle Server – Enterprise Edition – Version: 10.2.0.3 Information in this…

近日告警日志中出现以下记录： FAL[server]: Fail to queue the whole FAL gap GAP – thread 1 sequence 180-180 DBID 3731271451 branch 689955035 这是一个10.2.0.3的dataguard环境，采用物理备库，归档传输模式；查询metalink发现相关note: Symptoms When using ARCH transport, gaps could be flagged in the alert log even though the single log gap was for a log that had not been written at the primary yet. alert.log on primary…

就OTN上发布的合并声明来看到8月1日，Oracle将完成java.sun.com,developers.sun.com,bigadmin这几个网站合并到OTN的工作，这次迁移将是完整的并且在内容上是无损的。整合后的网站将提供给java开发者，数据库开发者及管理员，系统开发者及管理员一个多样的技术社区。 同时Oracle保证通过重定向技术确保用户原先的网页书签不会失效；java开发者仍可以像以往一样轻松获取java api信息；Oracle暂时不会修改java技术页面内容的构成，开发者目前不用担心不适应(我从metalink到MOS倒是很不适应，所幸现在好了); docs.sun.com以及原sun旗下的论坛，博客，维基将暂时不做迁移。如果用户有问题可以向社区反馈讨论版反映。另外作为这些网站的原用户可能需要在OTN新注册一个成员账号。 PS: 7月30日，合并似乎提早了，OTN的界面有了极大的变化，就我个人而言似乎还是老的界面比较对眼！

1.理解Oracle进程 首先我们要做的是理解Oracle的3种进程类型：后台进程( background process)和服务进程(也叫前台进程)还有用户进程。当我们尝试启动Oracle实例，首先受到召唤的是后台进程，一组后台进程和内存组建构成了 Oracle 实例，这些后台进程包括 日志记录进程lgwr,数据库写出进程 dbwr, 系统监控进程smon, 进程监控进程pmon, 分布式恢复进程reco, 检查点进程ckpt, 11g后变得更多了，多到我记不住。 这些进程在UNIX上的具体args总是形如ora_functionname_sid, 这里的functionname即后台进程的功能名而sid 即 $ORACLE_SID所指出的值。 第二类是用户进程，它可能是一个sqlplus命令行，可能是imp/exp工具，也可能是用户开发的一个java程序，当用户进程在本地启动时它们不直接操作SGA或者PGA,但毫无疑问它们也是需要消耗一定数量的虚拟内存的。 第三类进程就是我们说的服务进程，启动一个sqlplus 连接(这个连接可能是连到本地的 也可能的是远程的，这在我们讨论内存使用时无关紧要)的同时我们需要用到一个服务进程，它直接向我们的sqlplus终端负责。我们有时候也称服务进程为影子进程。影子进程总是和每一个用户进程一一对应的映射除非我们用到了MTS(多线程服务器)时。影子进程一般形如oracleSID,这里的sid和前文所指一般。   2.理解Oracle的内存使用 Oracle对内存的使用可以划分为2个大类型，即私有的和共享的。私有内存仅供单个进程使用。相反的，共享内存可以供多个进程使用且在具体使用上要复杂得多。在合计共享内存时，我们只需将所有进程所共享的内存段累加一次即可(Oracle 的SGA具体反映到OS层可能是多个shared memory segment,我们只需要将这一个或多个段的大小加到一起就可以了)。 我们可能使用到的最大的共享内存段毫无疑问会是SGA(SYSTEM GLOBAL AREA),我们看到的SGA被映射成虚拟地址且被每一个后台进程和前台进程attach到自己身上，以便随时能够利用到SGA; 我们有很多性能工具可以反映这部分的内存使用， 好比’top’,’ps -lf’, 但他们都无法分辨前后台进程内存使用中私有内存和共享内存分别得使用状况(我们往往只能得到一个Oracle使用内存很多的结论，却不知道是PGA还是 SGA消耗的更多的内存)。如果我们把从这些途径中获得每个进程的内存使用量相加，我们会发现这样计算的总内存使用量是SGA+PGA的几十倍，这是违反常识的，实际也分配不到那么多内存。 要真正了解Oracle内存使用，你使用的内存窥测命令需要能够分离Oracle使用的私有内存和共享内存。在Aix平台上有这样一个svmon(在其他 UNIX平台上有一个我认为更好的工具是pmap,与之对应AIX上有一个procmap命令，但这个命令并不能窥测Oracle 私有或共享内存的使用，所以我们只能退而求其次了)。   您可能在AIX的安装光盘上通过安装文件(filesets) “perfagent.tools”来获取该工具。使用”smit install_lastest”命令可以配备这个命令。对于svmon，作为一个非AIX操作系统专家而言，我推荐您读一下我引用的这篇文档：   The svmon Command The svmon command provides a more in-depth analysis of…

Oracle 8i For AIX/Linux/Unix/Windows的安装介质 OR CDROM目前在Oracle官网或者edelivery上已经没有下载了:     0-For AIX/0-64/Oracle/Oracle817CD1.nrg 0-For AIX/0-64/Oracle/Oracle817CD2.nrg 0-For AIX/0-64/Oracle/Oracle_816.nrg oracle817 for unix.ISO #oracle817_for_Intel UNIX (DGUX Intel,SCO UnixWare,Solaris Intel).ISO p2376472_8174_AIX p2376472_8174_AIX64.zip p2376472_8174_AIX.zip linux81701.tar     有不少学习研究Oracle的朋友，苦于没有metalink账号无法下载补丁集等软件；网上曾有总结过安装介质和补丁集的下载地址的文章，可以使用迅雷或快车等软件下载到介质，针对最新的11g release 2和未辑录的平台相关补丁集，进行了一定的补全。   这里共享的链接来自于oracle官方网站，仅供研究和非商业用途之用。   Oracle9i Database Release 2 Enterprise/Standard/Personal Edition for Windows NT/2000/XP http://download.oracle.com/otn/nt/oracle9i/9201/92010NT_Disk1.zip http://download.oracle.com/otn/nt/oracle9i/9201/92010NT_Disk2.zip http://download.oracle.com/otn/nt/oracle9i/9201/92010NT_Disk3.zip Oracle9i Database Release 2 Enterprise/Standard/Personal/Client Edition for Windows…

转自老白的<oracle rac 日记>一书， dump systemstate产生的跟踪文件包含了系统中所有进程的进程状态等信息。每个进程对应跟踪文件中的一段内容，反映该进程的状态信息，包括进程信息，会话信息，enqueues信息（主要是lock的信息），缓冲区的信息和该进程在SGA区中持有的（held）对象的状态等信息。dump systemstate产生的跟踪文件是从dump那一刻开始到dump任务完成之间一段事件内的系统内所有进程的信息。 那么通常在什么情况下使用systemstate比较合适呢？ Oracle推荐的使用systemstate事件的几种情况是： 数据库hang住了 数据库很慢 进程正在hang 数据库出现某些错误 资源争用   dump systemstate的语法为： ALTER SESSION SET EVENTS ‘immediate trace name systemstate level 10’; 也可以使用ORADEBUG实现这个功能: sqlplus -prelim / as sysdba oradebug setmypid oradebug unlimit; oradebug dump systemstate 10 如果希望在数据库发生某种错误时调用systemstate事件，可以在参数文件（spfile或者pfile）中设置event参数， 例如，当系统发生死锁（出现ORA-00060错误）时dump systemstate： event = “60 trace name systemstate level 10”   LEVEL参数： 10    Dump all…

同11.2.0.1.2 psu同时发布的还有10.2.0.4.5 psu,值得注意的是这2个psu都包括了针对ora-600/7445错误出现时信息显示的原因和调用(cause/action)。 附该psu的readme note: Released: July 13, 2010 This document is accurate at the time of release. For any changes and additional information regarding PSU 10.2.0.4.5, see these related documents that are available at My Oracle Support (http://support.oracle.com/): Note 854428.1 Patch Set Updates for Oracle Products Note 1089052.1 Oracle Database Patch Set Update 10.2.0.4.5…

7月13日，11g release 2 的第二个补丁集更新发布了；9i的最终版本为9.2.0.8,10g上10.2.0.5很有可能成为最终版本，我们预期今后(11g,12g)中Patch set数量会有效减少，而patch set update数量可能大幅增加；这样的更新形式可以为Oracle Database提升一定的软件形象。可以猜想11gr2的最终版本号可能是11.2.0.2/3.x。 附该psu的readme note: Released: July 13, 2010 This document is accurate at the time of release. For any changes and additional information regarding PSU 11.2.0.1.2, see these related documents that are available at My Oracle Support (http://support.oracle.com/): Note 854428.1 Patch Set Updates for Oracle Products Note 1089071.1 Oracle…

一般情况下无法从动态视图(v$session/v$session_wait)看到这个等待事件，因为它十分短暂。其本质从字面意思上来解释的话，是一种网络等待(network issue)； 举例而言，如果运行的代码中包含某种可能的错误，且在调用中触发了的话，服务器端本地的服务进程有义务对远程客户端告知该信息，这个告知的过程中服务进程就处于SQL*Net break/reset to client等待中，直到客户端收到问题信息为止。与一般意义上的Sever-client模式一样，使用dblink时也可能出现该种等待事件。 下面我们来尝试演示该种等待事件： SQL> create table tv (t1 int unique); Table created. SQL> insert into tv values(1); 1 row created. SQL> commit; Commit complete. SQL> oradebug setmypid; Statement processed. SQL> oradebug event 10046 trace name context forever,level 8; Statement processed. SQL> insert into tv values(1); insert into tv values(1) * ERROR…

客户的新系统上线已经一年有余，核心系统硬件采用IBM P595，操作系统版本AIX　5300-09，存储使用DS6000,数据库版本为10.2.0.4，没有打额外的patch set update.此套系统平时会话数量在2000-3000的水平，每秒新建会话在10个左右。 客户这套系统一直有一个问题，即每次准备关闭实例进行一些维护工作时，在多次手动执行检查点（确保脏块被写出）后，shudown immediate命令仍需要非常长的时间才完成关闭数据库动作；之前客户一直使用在shutdown之前将大部分应用服务进程杀死的方法，可以缩短 shutdown immediate命令完成的时间。 实际上服务进程在2000-3000的OLTP系统在当前已经很普及了，而在其他平台上(譬如:Linux,SUN OS)上则不会出现一个shutdown操作持续半个小时以上的情况。 通过查询My Oracle support发现一个9i上shutdown immediate费时半个小时的note: Hdr: 3484589 9.2.0.4.0 RDBMS 9.2.0.4.0 PRODID-5 PORTID-212 Abstract: BUG:3046394 WHICH IS A REWORK OF BUG :2674297 DOES NOT STILL FIX THE PROBLEM. PROBLEM: ——– Shutdown abort on AIX5L takes 7 min. and Shutdown immediate takes 30 min. Patch for the bug…