ITPub博客

创建回滚段 　　语法： 　　CREATE [PUBLIC] ROLLBACK SEGMENT rollback_segment 　　　　 [TABLESPACE tablespace] 　　　　 [STORAGE ([INITIAL integer[K|M]] [NEXT integer[K|M]] 　　　　　　　　　　 [MINEXTENTS integer] 　　　　　　　　　　 [MAXTENTS {integer|UNLIMITED}] 　　　　　　　　　　 [OPTIMAL {integer[K|M]|NULL}]) ] 　　注： 　　 回滚段可以在创建时指明PRIVATE或PUBLIC，一旦创建将不能修改。 　　 MINEXTENTS 必须大于等于2 　　 PCTINCREASE必须是0 　　 OPTIMAL如果要指定，必须大于等于回滚段的初始大小（

自从oracke 7.3以来，oracle提供了一种新的join技术，就是hash join。Hash Join只能用于相等连接，且只能在CBO优化器模式下。相对于nested loop join，hash join更适合处理大型结果集。Hash join不需要在驱动表上存在索引。一． Hash Join概述Hash join算法的一个基本思想就是根据小的row sources(称作build input，我们记较小的表为S，较大的表为B) 建立一个可以存在于hash area内存中的hash table，然后用大的row sources(称作probe input) 来探测前面所建的hash table。如果hash area内存不够大，hash table就无法完全存放在hash

在Oracle 10g中， exp 和 imp 被重新设计为Oracle Data Pump（虽然Oracle 仍然装载了exp 和imp，并完全地支持它们）。如果你以前使用过exp 和 imp，那么Data Pump 的命令行程序的语法对你来说就不陌生了。　　　　Data Pump 是运行在数据库内部的， 而不是像一个独立的客户端应用程序一样存在。这就意味着这部分的工作在一定程度上独立于发起执行导入或者导出任务的进程 。 在一台机器上 (例如一个定期任务) 可以开始执行导出的任务，而另一台机器上 (例如 DBA 的 手提电脑) 可以对任务的运行状态进行监控。 也正因为任务是运行在数据

In Oracle8i, release 8.1, we could use java to run a system command with an "&" after it (assuming unix) or perhaps "start xxx.cmd" if using NT.o In Oracle8.0 and up, we can write an external procedure in C that runs host commands with system() and the "&". (see attached for an external procedure example)o In Oracle7.0 and up, we can use dbms_pipes to talk to a daemon running outside the database. Here is a simple example that uses sqlplus to be the daemon:

在具有许多活跃用户的繁忙生产环境中，跟踪SQL会话是费时且十分复杂的，因为在任何使用连接池的多层系统中处理SQL语句可能要涉及多个进程，或者甚至是不同的实例。 利 用Oracle数据库10g，Oralce通过一个新的内置软件包DBMS_MONITOR合理化了SQL的跟踪，这个软件包中包含以前无书面记载的跟踪 工具（如DBMS_SUPPORT软件包）的功能。现在，您可以轻松地从头到尾--从客户机到中间层再到后端--跟踪任何用户的会话，并且基于特定的客户 ID、模块或动作生成跟踪文件。 此外，Oracle数 据库10g包含一种新的实用程序trcsess，它可以让您基于会

第二个特点，CACHE存储参数无效：SQL> CREATE TABLE T3 STORAGE(BUFFER_POOL KEEP) AS SELECT * FROM T2; Table created.SQL> ALTER TABLE T2 CACHE; Table altered.SQL> SELECT COUNT(*) FROM T;COUNT(*)----------334022SQL> SELECT OBJECT_NAME, A.STATUS, COUNT(*) 2 FROM V$BH A, USER_OBJECTS B3 WHERE A.OBJD = B.OBJECT_ID4 AND OBJECT_NAME IN ('T', 'T2', 'T3')5 GROUP BY OBJECT_NAME, A.STATUS;OBJECT_NAME STATU COUNT(*)--------------------------T xcur 8096SQL> SELECT COUNT(*) FROM T2;COUNT(*)-------

OPTIMIZER_INDEX_COST_ADJ这个初始化参数代表一个百分比,取值范围在1到10000之间.该参数表示索引扫描和全表扫描成本的比较。缺省值100表示索引扫描成本等价转换与全表扫描成本。这些参数对于CBO的执行具有重大影响，其缺省值对于数据库来说通常需要调整。一般来说对于OPTIMIZER_INDEX_CACHING可以设置为90左右对于大多数OLTP系统，OPTIMIZER_INDEX_COST_ADJ可以设置在10到50之间。对于数据仓库和DSS系统，可能不能简单的把OPTIMIZER_INDEX_COST_ADJ设置为50，通常我们需要反复调整取得一个合理值.更为具体的可以根据统计信息,db file scat

下面说明KEEP池缓存的特点，先看一下查询的结果：SQL> SELECT COUNT(*) FROM T2;COUNT(*)----------167011Statistics--------------0 recursive calls0 db block gets4839 consistent gets4829 physical reads0 redo size381 bytes sent via SQL*Net to client503 bytes received via SQL*Net from client2 SQL*Net roundtrips to/from client0 sorts (memory)0 sorts (disk)1 rows processedSQL> SELECT OBJECT_NAME, A.STATUS, COUNT(*) 2 FROM V$BH A, USER_OBJECTS B3 WHERE A.OBJD = B.OBJECT_ID4 AND OBJECT_NAME IN ('T', 'T

下面继续说明KEEP池和DEFAULT的一些不同之处。首先，创建T表的一个索引：SQL> CREATE INDEX IND_T_NAME ON T (NAME) STORAGE (BUFFER_POOL KEEP);Index created.SQL> ALTER TABLE T MODIFY NAME NOT NULL;Table altered.SQL> SELECT COUNT(*) FROM T;COUNT(*)----------334022Statistics---------------120 recursive calls0 db block gets9682 consistent gets9655 physical reads0 redo size381 bytes sent via SQL*Net to client503 bytes received via SQL*Net from client2 SQL*Net roundtrips to/from client4 sorts (memo

下面再创建一个同样大小的表：SQL> CREATE TABLE T2 STORAGE (BUFFER_POOL KEEP) AS SELECT * FROM DBA_SOURCE;Table created.SQL> SELECT COUNT(*) FROM T2;COUNT(*)-------167011Statistics-----------0 recursive calls0 db block gets4839 consistent gets4828 physical reads0 redo size381 bytes sent via SQL*Net to client503 bytes received via SQL*Net from client2 SQL*Net roundtrips to/from client0 sorts (memory)0 sorts (disk)1 rows processedSQL> SELECT COUNT(*) FROM T2;COUNT(*)----------167011Statisti

文章介绍了KEEP池和DEFAULT池的差异之处，下面通过例子进行详细的说明：首先，将T表的容量扩大1倍，这样，即使是单独查询T表，所有的数据也无法全部放入KEEP池。SQL> INSERT INTO T SELECT * FROM T;167011 rows created.SQL> COMMIT;Commit complete.SQL> SELECT COUNT(*) FROM T;COUNT(*)----------334022Statistics----------------0 recursive calls0 db block gets9666 consistent gets4828 physical reads0 redo size381 bytes sent via SQL*Net to client503 bytes received via SQL*Net from client2 SQL*Net roundtrips

The KEEP buffer pool retains the schema object’s data blocks in memory.
The RECYCLE buffer pool eliminates data blocks from memory as soon as theyare no longer needed.
The DEFAULT buffer pool contains data blocks from schema objects that are notassigned to any buffer pool, as well as schema objects that are explicitlyassigned to the DEFAULT pool.The initialization parameters that configure the KEEP and RECYCLE buffer pools areDB_KEEP_CACHE_SIZE and DB_RECYCLE_CACHE_SIZE.对象放入KEEP池后，数据

其他解决方法当重新编译某个package时,应确认当前没有session在使用此package中的object. 当我们重新编译某个package时,如果有session正在执行此package中的procedure或function,那么编译就会挂起. 因为编译或分析(parse)package或procedure或function或view时,Oracle需要先取得”library cache lock”和”library cache pin”以保证在编译或分析(parse)期间没有session正使用此object – 因为我们正修改此object的定义并需要删除后用新的定义来重建此object.我们可以用以下procedure来检查是否有session正在使用某个package,如果此proced

详细分析步骤下面给出两种方法来分析”library cache pin”,目的是找出哪些session在等待资源,哪些session 正占着这些资源,而占着资源的这些session又在做什么,从而找到问题的根源并加以解决.方法1.(1). 通过查询V$SESSION_WAIT找出正在等待”library cache pin”的session,其SQL语句如下:sql>select sid,substr(event,1,30),p1,p2,p3 from v$session_wait where wait_time=0 and event like 'library cache pin%'; SID SUBSTR(EVENT,1,30) P1 P2 P3 -------------------------------------------------------------------------------

概述 造成数据库性能下降或挂起的原因很多,”library cache pin”等待是其中之一.当数据库性能严重下降或挂起时,我们通过查询v$session_wait,发现大量的”library cache pin”等待,查询的SQL语句如下: #su - oracle$svrmgrlsvrmgr>connect internalsvrmgr>select sid,event,p1,p2,p3 from v$session_wait where wait_time=0;SID EVENT P1 P2 P3 ---------- ------------------------- ---------- ---------- -------------- 9 library cache pin 15417016 10090832 20 154 library cache pin 15417016 11224168 20 341 library cach

根据上述两个ORACLE进程号(ORACLE PID)，我们可以找到他们的会话信息和操作系统进程信息SQL> select spid,pid,addr from v$process where pid in (26,28);SPID PID ADDR------------ ---------- ----------------20552 26 C000000109C831E0 ----------- 阻塞其他会话的Oracle进程22580 28 C000000109C83BF0 ----------- 被阻塞的Oracle进程SQL> 我们来进一步证实一下上述信息：SQL>col username for a20SQL> col osuser for a20SQL> col machine for a20SQL> l1 select sid,serial#,username,osuser,machine,to_char(lo

前面我们已经知道碰到'library cache lock'导致进程hang时，如何解决。那么如何避免这类问题的发生呢？这篇文章主要介绍了library cache lock的成因以及如何避免。当我们在执行一些DML，DDL，甚至desc tablename等等操作的时候，会话就hang住了，还有一种情况，当我们使用create or replace procedure/function等语句修改Procedure和Function的时候，会话也会hang住，这是为什么呢？当出现上述情况的时候，我们可以通过v$session_wait查询等待事件，当然，这种情况下，该session的等待事件一定是'Library cache lock'。让我们来解释一下，

这里，简单的介绍一下X$KGLLK，这个基表保存了库缓存中对象的锁的信息，它对于解决这类问题特别有用，其名称的含义如下：[K]ernel Layer [G]eneric Layer [L]ibrary Cache Manager ( defined and mapped from kqlf ) Object Locks X$KGLLK - Object [L]oc[K]s KGLNAOBJ 列包含了在librarky cache中的对象上执行命令的语句的前80个字符（其实从这里我们也可以大大缩小范围了）X$KGLLK.KGLLKUSE 和 x$kgllk.KGLLKSES 对应于跟踪文件中的owner的值X$KGLLK.KGLLKADR X$KGLLK.KGLLKHDL 对应于跟踪文件中的handle的值(handle=C000000122E2A6D8)，

现在我们来dump 系统状态(systemstate)，看看更详细的信息。首先简单的介绍一下 event systemstate。很多人把 systemstate 事件理解为dump发生的那一刻的系统内所有进程的信息，这是个错误的概念，事实上，转储 system state 产生的跟踪文件是从dump那一刻开始到dump任务完成之间一段事件内的系统内所有进程的信息。dump systemstate产生的跟踪文件包含了系统中所有进程的进程状态等信息。每个进程对应跟踪文件中的一段内容，反映该进程的状态信息，包括进程信息， 会话信息，enqueues信息（主要是lock的信息），缓冲区的信息和该进程在

问题的成因已经基本上明确了，这里推荐两种解决问题的方法：方法1，根据 c000000122e2a6d8 地址，我们可以得到当前在library cache中相应的锁信息： SQL> l1 select INST_ID,USER_NAME,KGLNAOBJ,KGLLKSNM,KGLLKUSE,KGLLKSES,KGLLKMOD,KGLLKREQ,KGLLKPNS,KGLLKHDL2* from X$KGLLK where KGLLKHDL = 'C000000122E2A6D8' order by KGLLKSNM,KGLNAOBJSQL> /INST_ID USER_NAME KGLNAOBJ KGLLKSNM KGLLKUSE KGLLKSES KGLLKMOD KGLLKREQ KGLLKPNS KGLLKHDL---------- ------------- ---------------------- ---------- ----------------