v$sql中的bind_data在任何Oracle官方文档中均没有解释。我猜测该处存放的BIND VALUE是在做BIND PEEKING时的值。SQL> alter system flush shared_pool;系统已更改。SQL> exec :v1 :='INVALID';PL/SQL 过程已成功完成。SQL> SELECT * FROM TEST1 WHERE STATUS=:V1;OBJECT_NAME---------------------------------------------------------------------STATUS-------DBA_LOCK_INTERNALINVALIDDBA_DDL_LOCKSINVALIDSQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'ADVANCED'));PLAN_TABLE_OUTPUT-------------------------------------------------------------------------------------------------SQL_ID  3usutsn9a01dv, child number 0-------------------------------------SELECT * FROM TEST1 WHERE STATUS=:V1Plan hash value: 2214001748-----------------------------------------------------------------------------------------| Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| Time     |-----------------------------------------------------------------------------------------|   0 | SELECT STATEMENT            |           |       |       |     2 (100)|          ||   1 |  TABLE ACCESS BY INDEX ROWID| TEST1     |     2 |    44 |     2   (0)| 00:00:01 |PLAN_TABLE_OUTPUT-------------------------------------------------------------------------------------------------|*  2 |   INDEX RANGE SCAN 

点击此处查看原文

Size of Sys.C_obj#_intcol# cluster in system tablespace is growing   Doc ID:  Note:463226.1 中说CLUSTER C_OBJ#_INTCOL#增长导致数据库的SYSTEM 表空间被大量占用，如何缩小呢？该文档说除了重建数据库无别的办法。因为这个CLUSTER是一个BOOTSTRAP$对象。首先我们看看这个CLUSTER里包含些什么内容：SQL> select obj# from obj$ where name='C_OBJ#_INTCOL#';      OBJ#----------       251SQL> SELECT OBJ#,NAME,TYPE# FROM OBJ$ WHERE DATAOBJ#=251;      OBJ# NAME                                TYPE#---------- ------------------------------ ----------       251 C_OBJ#_INTCOL#                          3       253 HISTGRM$                                2看样子只有HISTGRM$存储在这个CLUSTER中。按理说这个对象是可以TRUNCATE的SQL> truncate cluster c_obj#_intcol#;truncate cluster c_obj#_intcol#                 *第 1 行出现错误:ORA-00701: 无法变更热启动数据库所需的对象由于是BOOTSTRAP$对象，所以无法TRUNCATE.由于这个对象是251>56,因此不是核心BOOTSTRAP$对象，所以我们用得上EVENT 38003了。SQL> alter system set EVENT="38003 trace name context forever, level 10"  2  SCOPE=SPFILE;系统已

点击此处查看原文

  ora-8102问题的处理Posted on 八月 09, 2008 by 白鳝 出现Ora-8102的原因一般是由于索引中的KEY和TABLE里的相关字段值不同导致数据不一致引起。一般来说，出现ORA-8102，是由于数据库逻辑或者物理故障引起的，损坏的可能是表数据，也可能是索引数据。如果损坏的是索引数据，那么只需要将索引重建就可以使表和索引数据一致，从而解决问题。如果损坏的是表数据，那么要看损坏的范围，如果只是损坏了某一行，那么纠正某一行的数据就可以了，如果损坏的面积较大，那么处理起来就比较复杂了。Oracle有一份文档1034886.6就是解释如何处理ORA-8102的，文章涉及的数据库版本比较老（7版），不过基本思路大致是没有问题的。针对较大面积的损坏，在1034886.6里面也没有给出很好的处理方案，绝对是十分麻烦的事情，不过有一种变通的方案，导出数据，然后重建对象是最佳的选择。不过有一种情况十分头痛，如果损坏的表不是简单的用户表，而是一个字典表，如果更加不幸，碰到了核心BOOTSTRAP$对象，那么就十分头痛了。前几天客户那边出现一个十分奇怪的现象，就是使用IMP导入数据的时候碰到ORA-8102错误，错误是在创建表的时候发生的：SQL> create table tcon2( a integer not null);create table tcon2( a integer not null)*ERROR 位于第 1 行:ORA-00604: 递归 SQL 层 1 出现错误ORA-08102:

点击此处查看原文

这几天我有一个客户的数据库出现了这样的情况，在一个3节点的RAC上，其中一个节点上修改的数据，马上在另外一个节点上查，发现有千分之5左右的数据没有更新，要过一会才能查到正确的结果。这造成了应用软件的业务逻辑错误。通过分析，发现是SCN的传播机制导致。由于Oracle 9i缺省的传播模式是lamport算法，SCN在实例间传递是通过GCS MESSAGE来传递的，因此就会造成一定的延时。LAMPORT算法可以减少实例间同步SCN所造成的性能问题，但是在变更十分频繁的系统中，可能出现上述的问题。因此在这种情况下，客户首先把这个应用全部部署在一个节点上，以避免业务逻辑的问题。如果无法通过应用调整来解决，那么就必须调整MAX_COMMIT_PROPAGATION_DELAY来改变传播算法了。一般来说这个参数在9i和10.1的缺省值是700（TRU64除外）也就是7秒钟，实际上这是一个上限了，因为lck每隔3秒钟会有一个例行的信息包交换，一般情况下，3秒钟肯定会完成一次scn传播。这个参数，如果设置为0-99，那么数据库会选择Broadcast-On-Commit算法，由LGWR来传播SCN。一般来说我们可以设置为0-99或者保留原有的值不懂，没有十分可靠的分析证据的情况下，建议不要设置100-700之间的值。10.2开始，lgwr传播SCN的算法有了很大的改进，因此10.2缺省使用Broadcast-On-Commit，这个参数的缺省值也变为0. 

点击此处查看原文

今天客户有个ORA-600的问题：*** 2008-07-24 04:26:54.199ksedmp: internal or fatal errorORA-00600: internal error code, arguments: [kghpih:ds], [0x5712ABB68], [], [], [], [], [], []No current SQL statement being executed.一般来说KGHPIH:DS是由于LIBRARY CACHE HEAP出现了CORRUPT。根据参数：0x5712ABB68 查看一下这个地址：5712ABB60 00000003 8002C7A8 00000005 B9C26548  [..............eH]这个地址的信息是正确的，可以看到DS的地址0X5B9C26548，再看看5B9C26548的内容：******************************************************HEAP DUMP heap name="library cache"  desc=5b9c26548 extent sz=0x348 alt=32767 het=32 rec=0 flg=2 opc=2 parent=380000030 owner=5574b15f0 nex=0 xsz=0x348EXTENT 0 addr=5712abb68  Chunk        5712abb78 sz=      824    perm      "perm           "  alo=440EXTENT 1 addr=5574b15c0  Chunk        5574b15d0 sz=      576    perm      "perm           "  alo=576  Chunk        5574b1810 sz=      224    free      "               "Total heap size    =     1624FREE LISTS: Bucket 0 size=0  Chunk        5574b1810 sz=      224    free      "               "Total free space   =      224UNPINNED RECREATABLE CHUNKS (lru first)

点击此处查看原文

由于回家换了台电脑，因此数据块换了一个，继续介绍下面的数据结构。其逻辑DUMP:tsiz: 0x1f98hsiz: 0x14pbl: 0x0cebec64bdba: 0x0100028e     76543210flag=--------ntab=1nrow=1frre=-1fsbo=0x14fseo=0x1f8eavsp=0x1f7atosp=0x1f7a0xe:pti[0]      nrow=1  offs=00x12:pri[0]     offs=0x1f8eblock_row_dump:tab 0, row 0, @0x1f8etl: 10 fb: --H-FL-- lb: 0x1  cc: 2col  0: [ 3]  31 31 31col  1: [ 2]  c1 03end_of_block_dump这个块有2个ITL槽，今后计算所有的位置都要根据这个来计算。下面一个重要的结构就是KDBHstruct kdbh {  ub1                  kdbhflag; /*  FLAGs  */  ktno                 kdbhntab; /*  Number of TABles in the table index  */  ub2                  kdbhnrow; /*  Number of ROWs in the row index  */  sb2                  kdbhfrre; /*  first FRee Row index Entry  */  sb2                  kdbhfsbo; /*  Free Space Beginning Offset  */  sb2                  kdbhfseo; /*  Free Space Ending Offset  */  b2                   kdbhavsp; /*  AVailable SPace in the block  */  b2             &

点击此处查看原文

从44开始是ITL表，每个ITL记录的长度为24，从1可以看到这个块有3个ITL槽，因此ITL占72字节我们开始分析：00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F00 00 00 00 03 00 32 00 11 A7 00 01 FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 006D 48 25 00 00 00 00 00 00 00 00 00 00 00 00 00struct ktbit {  kxid                 ktbitxid; /*  transaction id  */  kuba                 ktbituba; /*  undo address for last change  */  b2                   ktbitflg; /*  num of locks in block  */  ktbitun_t            _ktbitun;  ub4                  ktbitbas; /*  sys commit num base  */}KXID： UB2 ：UNDO SEGMENT NUMBER             UB2 ：SLOT NUMBER             UB4 ：WRAP44-51 XID(8)：FF FF 00 00 00 00 00 00 ：0xffff.0000.0000000052-59UBA(8)：00 00 00 00 00 00 00 00  ：0x00000000.0000.00 60-61(2): FLAG:00 80,0X0800,  c---  LOCK 062-67(6):scn:00 00 6D 48 25 00 ,0x00254864.00 该贴被白鳝编辑于2008-4-24 22:35:44

点击此处查看原文

这里介绍一下Oracle type: 0x06=trans data的数据块的结构(本文涉及的数据库版本为10.2.0.1）以下是一个块的逻辑结构：buffer tsn: 4 rdba: 0x0100a714 (4/42772)scn: 0x0000.0025486e seq: 0x02 flg: 0x04 tail: 0x486e0602frmt: 0x02 chkval: 0xddf1 type: 0x06=trans dataBlock header dump:  0x0100a714 Object id on Block? Y seg/obj: 0xcc5c  csc: 0x00.25486d  itc: 3  flg: E  typ: 1 - DATA     brn: 0  bdba: 0x100a711 ver: 0x01 opc: 0     inc: 0  exflg: 0  Itl           Xid                  Uba         Flag  Lck        Scn/Fsc0x01   0xffff.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.0025486d0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.000000000x03   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000 data_block_dump,data header at 0x8eb227c===============tsiz: 0x1f80    hsiz: 0x16pbl: 0x08eb227cbdba: 0x0100a714     76543210flag=--------ntab=1    ----有1个表，如果是CLUSTER，可能大于1nrow=2   -----有2行frre=-1  fsbo=0x16       ----空闲空间的开始（44+NO_OF_ITLS*24+0X16)  NO_OF_ITLS:itl插槽的数量fseo=0x1e70   ----空闲空间尾部 （44+NO_OF_ITLS*24 +0x1e70)avsp=0x1e5a  tosp=0x1e5a0xe:pti[0] nrow=2 offs=00x12:pri[0] offs=0x1f79  ----第一行的地址0x1f79+（44+NO_OF_ITLS*24)0x14:pri[1] offs=0x1e70 ----第二行的地址0x1e70+（44+NO_OF_ITLS*2

点击此处查看原文

这几天在外面出差，回到酒店就什么都不想干了，为了不让这个系列夭折，还是写一小段吧当一个实例突然宕掉（比如服务器故障、SHUTDOWN ABORT，后台进程被杀等情况），很多没有写回文件的DB CACHE就会丢失，数据库会失去一致性。Oracle如何在这种情况下进行恢复呢？首先我们来看看实例恢复在什么时候做的。对于多实例环境,某个实例发生故障的时候，生存下来的实例就有义务将故障实例出现的CACHE不一致现象进行恢复。比如：某个实例：Tue Apr  1 15:08:05 2008LGWR: terminating instance due to error 600由于LGWR的故障宕了，另外一个实例：Tue Apr  1 15:10:24 2008Reconfiguration started (old inc 4, new inc 5)List of nodes: 1 Global Resource Directory frozenone node partition Communication channels reestablished Master broadcasted resource hash value bitmaps Non-local Process blocks cleaned out Resources and enqueues cleaned out Resources remastered 7909 247672 GCS shadows traversed, 8 cancelled, 5754 closed 211843 GCS resources traversed, 0 cancelled 150817 GCS resources on freelist, 269799 on array, 269799 allocated set master node info  Submitted all remote-enqueue requests Update rdomain variables Dwn-cvts replayed, VALBLKs dubious All grantable enqueues granted 247672 GCS shadows traversed, 0 replayed, 5760 unopened Submitted all GCS remote-cache requests 0 write requests issued in 241912 GCS resources 31 PIs marked suspect, 0 flush PI msgsTue Apr  1 15:10:27 2008Reconfiguration complete Post SMON to start 1st pass IRTue Apr  1 15:10:27 2008Instance recovery: looking for dead threadsTue Apr  1 15:10:27 2008Beginning instance recovery of 1 threadsTue Apr  1 15:10:27 2008Started redo scanTue Apr  1 15:10:36 2008Completed redo scan 220466

点击此处查看原文

从今天开始，白鳝将陆续介绍Oracle recovery的一些基础知识。今天是第一部分，介绍RECOVERY的基本思路Oracle是依靠REDO LOG来实现RECOVERY的，无论是INSTANCE RECOVERY还是MEDIA RECOVERY。REDO LOG中记录了数据库变更的顺序，REDO LOG是按照THREAD来组织的，对于多实例的情况，每个实例独自组织自己的REDO LOG。不过无论如何，SCN是控制数据库变化顺序的一个重要的机制，通过SCN，无论是哪个实例中的变更，都回在RECOVERY的时候被排序，这样就不会出现数据库无法分辨多个实例中的变化的顺序了。REDO LOG存储了数据库的变更情况，无论是提交过的还是未提交的，都被记录下来。由于Oracle记录了UNDO SEGMENT的变化，因此ROLLBACK信息也被间接的记录了下来。数据库做实例恢复或者介质恢复的时候分为2个阶段，第一个阶段是前滚阶段，数据库根据REDO LOG中的信息进行前滚，直到所有的REDO LOG记录都被提交到数据库上。前滚结束的时候，数据库里包含了这段时间里的所有变更，也包含了部分未提交的事务。这个阶段被称为恢复阶段。这个阶段是DB级的。第二个阶段是回滚，回滚是事务级的操作，在这个阶段，所有未提交的事务都回被回滚，这样第二阶段结束的时候，数据库就恢复到了一致的状态。 

点击此处查看原文

  B树索引的分析（本次分析是在自动段管理模式下进行的）1、创建测试表：SQL> create sequence seq1 ;序列已创建。

点击此处查看原文

  
 
 
 该贴被白鳝编辑于2008-4-6 9:26:30

点击此处查看原文

棉花说RMAN会对已经变更过的块重新拷贝一次。从Oracle的角度考虑，我觉得这种处理模式不现实，第一是重新拷贝也避免不了块断裂，除非把整个块锁住。第二是这么做效率不高。可能拷贝完了，发现所有的块又变更了。(Oracle实际的算法是RMAN作为一个Oracle Session，和OS COPY命令实现是不同的，RMAN可以读取一个数据块。RMAN备份某个文件的时候，会设置文件头的Absolute Fuzzy和absolute fuzzy scn，这个时候做其他的备份就会被禁止。absolute fuzzy scn最初是空的，当RMAN在读取BUFFER的时候，比较这个BUFFER的SCN和当前的FUZZY SCN，如果BUFFER的更大，就更改为BUFFER的。这样，当整个文件备份完后，文件头里的FUZZY SCN是整个文件中的最大的。备份结束的时候，会比较ABSOLUTE FUZZY SCN和CHECKPOINT SCN，如果CHECKPOINT SCN已经高于FUZZY SCN，那么说明这个文件这个时间点恢复所需要的数据都已经写入磁盘，这个时候清除FUZZY BIT就可以了。如果CHECKPONT SCN还比较低，那么就保留。）下面做个实验：SYS用户SQL> ALTER TABLESPACE INDX BEGIN BACKUP;表空间已更改。SQL> select max(ktuxescnw * power(2, 32) + ktuxescnb) from x$ktuxe;MAX(KTUXESCNW*POWER(2,32)+KTUXESCNB)------------------------------------                            18074167 然后SCOTT 用户：SQL> UPDATE TBK SET A=5 WHERE B=5;已更新 1 行。SQL> COMMIT;提交完成。然后SYS用户：SQL> select max(ktuxescnw * power(2, 32) + ktuxescnb) from x$ktuxe;MAX(KTUXESCNW*POWER(2,32)+KTUXESCNB)------------------------------------                            18074182SQL> alter system dump logfile 'd:\oracle\oradata\ora92\redo01.log' scn min 18074167 SCN MAX 180741

点击此处查看原文

本文正在编辑中X$KCBWDS结构是WORKSET的描述，从这里可以看到一些主要的链： ADDR                    RAW(4)  地址 INDX                    NUMBER   INST_ID                 NUMBER  实例ID SET_ID                  NUMBER  WORK SET ID DBWR_NUM                NUMBER  DBWR编号 BLK_SIZE                NUMBER  WORKSET的BLOCK SIZE PROC_GROUP              NUMBER   CNUM_SET                NUMBER   FLAG                    NUMBER   CKPT_LATCH              RAW(4)  CHECKPOINT LATCH CKPT_LATCH1             RAW(4) SET_LATCH               RAW(4)  NEXT REPLACEMENT CHAIN  NXT_REPL                RAW(4)  PRV  REPLACEMENT CHAIN PRV_REPL         &n

点击此处查看原文

COMMIT的内部处理过程其实很简单COMMIT Processing Oracle server 使用一种快速commit的机制来确保提交的变化已经被Oracle数据库接受，当实例故障的时候也能够通过内部机制来恢复1、当事务提交的时候，Oracle服务器为这个事务分配一个SCN2、SERVER进程产生一个COMMIT记录，该记录包含了SCN,COMMIT记录被写入REDO LOG BUFFER.3、 LGWR 将未写入REDO LOG文件的该COMMIT记录之前（包含该记录）的所有REDO LOG BUFFER写入REDO LOG文件。这些数据写入REDO LOG文件后，就可以保证实例故障的时候，这些数据也不会丢失。4、此时SERVER进程通知USER 进程，COMMIT完成5、SERVER进程释放锁资源等 
该贴被白鳝编辑于2008-4-6 9:29:20

点击此处查看原文

从DUMP出的UNDO SEGMENT HEADER中的TBL看：  index  state cflags  wrap#    uel         scn            dba            parent-xid    nub     stmt_num    cmt  ------------------------------------------------------------------------------------------------   0x00    9    0x00  0x02a3  0x0001  0x0000.0019f379  0x0080dfd4  0x0000.000.00000000  0x00000001   0x00000000  1205461935   0x01    9    0x00  0x02a4  0x002b  0x0000.001a129a  0x0080dfd4  0x0000.000.00000000  0x00000001   0x00000000  1205462192   0x02    9    0x00  0x02a4  0x001f  0x0000.0019f358  0x0080dfd4  0x0000.000.00000000  0x00000001   0x00000000  1205461879   0x03    9    0x00  0x02a4  0x0028  0x0000.001a155a  0x0080dfd7  0x0000.000.00000000  0x00000001   0x00000000  1205463626   0x04    9    0x00  0x02a4  0x0011  0x0000.001a134e  0x0080dfd7  0x0000.000.00000000  0x00000002   0x00000000  1205462541   0x05    9    0x00  0x02a5  0x000d  0x0000.001a16e2  0x0080dfd8  0x0000.000.00000000  0x00000001   0x00000000  1205464056   0x06    9    0x00  0x02a4  0x002a  0x0000.0019e2f5  0x0080dfd5  0x0000.000.00000000  0x00000001&nb

点击此处查看原文

Library cache lock：  这个锁的作用是控制多个Oracle客户端对同一个LIBRARY CACHE对象的并发访问。通过对LIBRARY CACHE OBJECT HANDLE上加锁来防止非兼容的访问。包括：一个客户端可以通过这个锁来防止其他客户端访问这个对象一个客户端可以在一个相对长的时间内防止某个对象被修改（比如为了分析某个SQL的过程中防止某个存储过程被修改）一个客户端在共享池中查找某个对象也可以使用这个锁当SQL和PL/SQL分析的时候，able, view, procedure, function, package, package body, trigger, index, cluster, synonym这些对象使用这个锁来保护。而CURSOR,PL/SQL片段以及一些瞬时对象不使用该锁。Library cache pin：     当一个对象要被装载到内存中的时候，需要使用Library cache pin，如果一个客户端要修改或者查看某个对象的时候，在library cache lock后，需要加library cache pin。    如我们以前讨论过的，一个对象在共享池中包括HANDLE(KGLHD)以及kglob,kglna，只有当这3个部分都在内存中，才能够持有library cache pin。 library cache lock和Library cache pin都是为了并发访问共享池对象的。lock是为了在客户端中进行同步，而pin是为了保护共享内存的访问。LOCK可能会产生死锁，而且死锁对于访问性能影响较大。而PIN对于死锁不敏感。 参考资料METALINK NOTE：444561.1可以通过 X$KGLLK 和 X$KGLPN来查看LOCK 和PIN 该贴被白鳝编辑于2008-4-6 14:01:07

点击此处查看原文

Oracle的HOT BACKUP，文件拷贝后END BACKUP。（根据棉花的提醒，修改了本帖，原文是：其代表工具就是RMAN，可以在数据库在线运行的情况下，对数据文件进行备份呢。实际上，RMAN备份和使用操作系统命令进行CP没有本质的区别，实际上，RMAN的处理模式是不同的，详细情况参考下面的回帖）将文件设置为BEGIN BACKUP，然后拷贝文件。如果我们正在拷贝一个BLOCK的时候，正好DBWR也在写一个BLOCK，那么我们拷贝的一个BLOCK可能是不一致的。Oracle恢复的时候如何避免这种情况的发生呢。1、BEGIN BACKUP的时候会做CHECKPOINT，尽量把脏块写入文件2、对于处于BEGIN BACKUP状态的文件，当某个BLOCK第一次被变更的时候，整个BLOCK会被写入REDO LOG,而不仅仅是CHANGE VECTOR。这样做恢复的时候，可以从这个完整的BLOCK开始提交REDO VECTOR，从而恢复这个块的数据。3、DATAFILE会保留上一次完整CHECKPOINT的SCN，并且在备份过程中不会改变，直到END BACKUP后。这样恢复的时候Oracle知道哪些数据块需要前滚。 从这种机制我们可以学到什么呢？在我们做备份的时候，对于DB FILE的备份，尽量减少BEGIN BACKUP和END BACKUP的时间，以减轻备份期间对REDO LOG的压力。 该贴被白鳝编辑于2008-3-26 14:35:14该贴被白鳝编辑于2008-4-6 14:01:48

点击此处查看原文

SPFILE是Oracle 9i引入的新的参数文件，SPFILE和以前的pfile相比，具有很多优点，spfile可以通过命令来维护。SPFILE里包含了所有非缺省值的参数的信息。并且是一种二进制形式的文件，虽然打开SPFILE后可以看到参数和其取值，但是直接修改SPFILE是不允许的，直接编辑SPFILE可能导致SPFILE损坏。因为在spfile的第一个BLOCK中，包含整个文件的CHECKSUM,一旦CHECKSUM出现问题，那么Oracle会认为SPFILE损坏。数据库启动后，在共享池中保留了一分SPFILE的内存拷贝。通过ALTER SYSTEM命令可以修改内存拷贝也可以修改SPFILE文件。为了保证SPFILE被正确的维护，在SPFILE中保存有两个拷贝的参数信息。两个拷贝中一个为主要拷贝，另外一个是备用拷贝。到底哪个拷贝为当前的主要拷贝，通过一个标志位来指明。修改SPFILE的流程如下：1、获取KSP 锁2、检查标志位，查看主拷贝是否为VALID。如果检查失败，跳转到11步。本阶段确定如果本次修改失败后，存在可用的合法拷贝3、确定本次修改需要多少文件空间4、如果目前文件空间不足，扩展SPFILE5、在备用拷贝上计算写入的位置6、写入备用拷贝7、修改标志位表示备用拷贝是VALID的8、拷贝备用拷贝到主拷贝9、修改标志位，表示主拷贝是VALID的10、结束正常修改，返回11、将备用拷贝拷贝到主拷贝------------------------------------------------------------------------12、修改标志位，表示主拷贝是VALID的13、返回第二步该贴被白鳝编辑于2008-4-6 14:03:06

点击此处查看原文

 谈谈CURSOR系列（3）预备知识KGHOracle的内存（空间）分配都是采用HEAP的模式，HEAP管理的基础就是KGH，为了理解一些深入的Oracle内部原理，我们必须首先理解KGH的基本知识，本节就是讨论KGH的一些基本的概念。最常见的内存HEAP包括SGA HEAP,PGA HEAP，另外我们最常见的表也是HEAP TABLE，其空间管理也是使用KGH。0.基础概念   Oracle的各种内存组织都是以HEAP形式的，每个HEAP包含一个HEAP句柄和一系列的内存EXTENT，每个EXTENT包含了一系列的连续的CHUNK。内存申请者通过在HEAP上申请空间的模式来获得内存。我们常见的SGA,PGA都是以HEAP的形式管理的。在HEAP上分配空间（CHUNK），根据ALLOCATION CLASS的不同，其管理模式也不同。

点击此处查看原文