ITPub博客

现在，我们结束10046的事件跟踪：SQL> exec dbms_system.set_ev(30,24167,0,0,'');PL/SQL procedure successfully completed.SQL> exec dbms_system.set_ev(37,2707,0,0,'');PL/SQL procedure successfully completed.SQL> 根据上面记录的信息，我们知道这两个会话产生的跟踪信息分别为：SID为30的会话，产生的跟踪文件为：/ora9i/app/oracle/admin/csmisc/udump/csmisc2_ora_22580.trcSID为37的会话，产生的跟踪文件为：/ora9i/app/oracle/admin/csmisc/udump/csmisc2_ora_20552.trc看看trace文件：ora9i@cs_dc02:/ora9i > c

跟踪期间咱们再次测试一下，看看有没有其他线索。新开一个进程，找出其sid, serial和spid等信息：ora9i@cs_dc01:/ora9i > sqlplus pubuser/pubuser SQL*Plus: Release 9.2.0.4.0 - Production on Mon Jan 10 11:36:25 2005Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.Connected to:Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit ProductionWith the Partitioning and Real Application Clusters optionsJServer Release 9.2.0.4.0 - ProductionSQL> select distinct sid from v$mystat;SID------

问题描述：接到应用人员的报告，说是在任何对表CSNOZ629926699966的操作都会hang，包括desc CSNOZ629926699966,例如：ora9i@cs_dc02:/ora9i > sqlplus pubuser/pubuserSQL*Plus: Release 9.2.0.4.0 - Production on Mon Jan 10 10:11:06 2005Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.Connected to:Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit ProductionWith the Partitioning and Real Application Clusters optionsJServer Release 9.2.0.4.0 - ProductionSQL> conn pubuser/pubuserConne

三、解决方法有两种方法可以查询library cache pin的相关信息，推荐使用第二种。使用这种方法前，有必要先了解以下表或视图：x$kglob、x$kgllk、x$kglpn、DBA_KGLLOCK1) x$kglob该基表主要是library cache object的相关信息。X$KGLOB--[K]ernel [G]eneric [L]ibrary Cache Manager [OB]ject引用该基表的视图有﹕GV$ACCESS、GV$OBJECT_DEPENDENCY、GV$DB_OBJECT_CACHE、GV$DB_PIPES、DBA_LOCK_INTERNAL﹑DBA_DDL_LOCKS2) x$kgllk该基表保存了library cache中对象的锁信息，主要用于解决library cache lock。其名称含义是：[K]ernel Layer [

一、概述一个实例中的library cache包括了不同类型对象的描述,如:游标,索引,表,视图,过程,等等.这些对象不能在他们被使用的时候改变,他们在被使用的时候会被一种library locks and pins的机制锁住.一个会话中,需要使用一个对象,会在该对象上先得到一个library lock(null, shared or exclusive模式的)这是为了,防止其他会话也访问这个对象(例如:重编译一个包或视图的时候,会加上exclusive类型的锁)或更改对象的定义.总的来说，library cache pin和library cache lock都是用于share pool的并发控制的。pin和lock都可以看作是一种锁。locks/p

　　SGA的阀值摘要　　由下面的表一可以看到，在监视SGA的内存使用时，有几个明显的阀值可以利用。我们可以写一些脚本并在其中集成一些智能，这样就可以在处理的需求变化时重新设置SGA。　　RAM Area Too-small Condition Too-Large Condition 　　Shared pool Library cache misses No misses 　　Data buffer cache Hit ratio < 90% Hit ratio > 95% 　　PGA aggregate high multi-pass executions 100% optimal executions　　　表1：SGA中的异常条件指示　　查看SGA内存区域的负载　　Oracle9i使用了一些新的内部视图或者在现有

Oracle9i数据库在内部特性方面有着非常大的增强，其中一个最令Oracle DBA兴奋的莫过于可以动态设置全部的Oracle SGA控制参数。与8i不同的是，原来都将初始化参数放到一个文本文件中，并且在数据库启动的时候读取，Oracle9i却可以通过ALTER DATABASE和ALTER SYSTEM命令复位全部的Oracle参数。　　在9i前，如果想对Oracle数据库的处理模式作一 些改变的话，Oracle管理员必须关闭数据库并且重新设置INIT.ORA文件中的参数，然后重新启动数据库。对于白天使用OLTP模式运作，晚上切换 到数据仓库模式的Oracle数据库来说，这种重新设置是经常

ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 bytes is 100.00% used, and has 0 remaining bytes available.*************************************************************You have the following choices to free up space fromflash recovery area:1. Consider changing your RMAN retention policy. If you are using dataguard, then consider changing your RMAN archivelog deletion policy.2. Backup files to tertiary device such as tape using the RMAN command BACKUP RECOVERY AREA.3. Add disk

版本历史2003-5-22 v0.1 Created by Fenng (Fenng@itpub.net)版权声明转载请注明作者及出处----------------------前言----------------------每一个DBA在进行数据库管理的过程中不可避免的要遇到形形色色的错误(ORA-xxxx).有些错误由于频繁出现、原因复杂而被DBA们戏称之为"经典的错误".其中ORA-3113 "end of file on communication channel" 就是这样的一个.我们可以简单的把这个错误理解为Oracle客户端进程和数据库后台进程连接中断.不过,导致这个错误的原因实际上有很多种,对数据库设置不当、任何能导致数据库后台

以往以为group by 后的记录集是排序的，而且在9i环境下屡试如此，最近在升级过程中终于发现了这种写法的不严谨之处。也可能是10gR2的内部算法开始有变，至少10gR2之前的版本group by是排序结果集，但10gR2不灵了！前几天从9i升级到10gR2时，以往排好序的报表突然出现了乱序，查代码，发现select ... from tb group by ..没有强制使用order by ，虽然在以前的环境中得到的就是期望的排序结果集，可到了10gR2里不灵了！！！仔细翻阅了Oracle各版本的官方文档http://tahiti.oracle.com/ 均明确注明:The GROUP BY clause groups rows but doe

Oracle的等待事件是衡量Oracle运行状况的重要依据及指标。等待事件的概念是在Oracle7.0.1.2中引 入的，大致有100个等待事件。在Oracle 8.0中这个数目增加到了大约150个，在Oracle8i中大约有200个事件,在Oracle9i中大约有360个等待事件。主要有两种类别的等待事 件，即空闲(idle)等待事件和非空闲(non-idle)等待事件。　　空闲事件指Oracle正等待某种工作,在诊断和优化数据库的时候,我们不用过多注意这部分事件。　　常见的空闲事件有:　　• dispatcher timer　　• lock element cleanup　　• Null event　　•

Latch free等待事件的三个参数：p1－latch的地址；p2－latch编号；p3－请求次数。从oracle10g起，latch free不再包含所有的latch等待，有些latch等待可能表现为单独的等待事件，这个后面有提到一些这样的等待事件，一般情况下我们还是统称为latch free等待事件。在处理latch free等待事件时，需要注意以下几点：n Latch只是用来保护sga中的内存结构。对数据库中的对象的保护，使用的lock而不是latch。Oracle sga中有许多latch，用来保护sga中各种内存结构不会因为并发访问而损坏。n 等待latch的是oracle会话。不同的latch类型会导致会话采

Latch产生的原因，诊断以及对策Latch争用通常意味这某个进程持有latch的时间过长。如果latch争用明显，系统性能将显著下降。在高并发的环境中，latch争用经常发生，并且你无法完全消除latch争用。在v$system_event中总会出现latch free等待事件。只有当time_waited相对实例启动以来的总时间比较明显时，你才需要关注latch争用。当latch在系统范围内的等待时间比较显著时，你可以通过v$latch中的sleeps列来发现争用显著的latch：Select name, gets, misses, immediate_gets, immediate_misses, sleeps from v$latch order by sleeps;

尽量减每个块中的记录数。首先需要dump一些数据块来分析现在每个块中的记录数。Dump出来的跟踪文件中，nrow就是块中的记录总数。然后exp表，再truncate表，在表中插入你想要在每个块中保存的条数的记录，然后使用alter table table_name minimize records_per_block，再truncate表，最后imp回数据即可。n 可以考虑减少块的大小。从oracle9i开始，数据库可以支持不同的块大小。例如当前块大小为16k，你可以将表及其索引移动块大小为8k的表空间中。这也会对全表扫描造成负面影响。并且，多个块大小也会使得管理更复杂。另外，从orac

　　　　调整闩(latch)和锁定(lock)　　　　1.　 调整闩(latch)　　　　闩可以作为内存性能的另一个指标。　　　　1.闩:等待闩和立即闩(V$lacth。共239个)。　　　　数据库中是否存在闩争用V$system_event("latch free")。　　　　几个重要的闩：shared pool、library cache、cache buffers lru chain、　　　　cache buffers chains、redo allocation、redo copy。　　　　select * from V$latch where misses!=0;　　　　2.自由列表：V$system_event("buffer busy waits")。　　　　V$waitstat。　　　　测量哪些段

Oracle 10g 操作系统solaris Db_cache_size32m64m128m256m512m1024m2048m_ksmg_granule_size4m4m4m4m4m16m16m_db_block_buffers39767952159043180863616127232254464_db_block_hash_buckets8192163843276865536131072262144524288_db_block_hash_latches1024102410241024102410242048Oracle9i 操作系统solarisDb_cache_size32m64m128m256m512m 1024m2048m_ksmg_granule_size4m4m16m16m16m16m16m_db_block_buffers40008000160163203264064128128256256_db_block_hash_buckets8009160013205164067128147256279512521_db_block_hash_la

　　　　调整磁盘I/O的性能　　　　哪些操作会导致磁盘I/O：　　　　将Buffer cache中的内容写到数据文件。　　　　写回退段。　　　　将数据文件的内容读到Buffer cache中。　　　　将Redo log Buffer中的内容写到online redo log中。　　　　将online Redo log中的内容归档到 archive log中。　　　　1. 调整表空间和数据文件　　　　测量数据文件I/O：使用V$filestat。　　　　使用STATSPACK来测量数据文件I/O。　　　　使用REPORT.TXT来测量数据文件I/O。　　　　使用Performance Manager(I/O)来测量数据文件I/O。　　　　建议：　　　

　　Buffer cache由数据块组成。　　　　1. Buffer cache的工作原理　　　　LRU列表：MRU　………………. LRU。(全表扫描FTS放在LRU端。)　　　　缓冲区块的状态：Free、Pinned、Clean、Dirty。　　　　Dirty List或Write List(写列表)。　　　　数据库写进程DBW0将缓冲区高速缓存中的数据写到数据文件中。　　　　2.测量Buffer cache的性能　　　　测量Buffer cache的命中率：　　SQL> select 1-((physical.value – direct.value – lobs.value)/logical.value) “Buffer Cache Hit Ratio” from V$SYSSTAT physical, V$SYSSTAT dire

在监控、诊断、处理数据库性能问题的时候，时间信息往往是非常重要的判断依据。有时候可能我们会使用一些比例来判断性能，但是使用比例而不使用时间往往会将我们带向错误的方向。在Oracle9i的第一版中关于时间的信息被进行了增强，提供了更多更有益的时间信息。除了9i的外貌发生了变化，在一些并没有被我们注意或者不为人知得一些v$视图的相关字段也发生了变化。这里提到的主要是他们发生了那些改变以及对DBA有什么帮助。这里也列出了零星的一些Oracle内部的未公开的信息。Second 1 秒Centi-second 1/100 百分之一秒 厘秒Milli Second 1/1

二、守护进程工作原理和方式 在 Client/Server模式下。服务器监听（Listen）在一个特定的端口上等待客户连接。连接成功后服务器和客户端通过端口进行数据通信。守护进 程的工作就是打开一个端口，并且等待（Listen）进入连接。如果客户端产生一个连接请求，守护进程就创建（Fork）一个子服务器响应这个连接，而主 服务器继续监听其他的服务请求。 守护进程工作方式： （1）运行独立的守护进程 独 立运行的守护进程由init脚本负责管理，所有独立运行的守护进程的脚本在/etc/rc.d/init.d/目录下。系统服务都是独立运行的守护进程包 括：