《DBA的思想天空》读书笔记

       这篇日志记录《DBA的思想天空》的读书情况，包括读书计划，需要注意的点等，连续更新。

       2013年1月15日

       1.P6，oracle复制，用tar一下然后relink all就行，这个得测试一下

       2.p6，看看inventory，在/etc下伙子/var/opt/oracle下，有个Inventory.xml，看看多db下是什么情况

       3.p9, 看口令文件的内容，strings orapworcl，orcl是sid

       4.p11,看控制文件的内容：

          select type,record_size,records_total,records_used from v$controlfile_record_section;

       5.p12,在线日志文件即redo log文件，“在线”这两个字是用于和归档日志区分，归档日志文件是在线日志的离线拷贝版本，当在线日志切换的时候，arch进程就会将刚刚关闭的在线日志文件的内容复制到磁盘上，长期保存。

       6.p13,实例是访问数据库的通道，操作系统中的一系列进程和为进程分配的内存块。oracle数据库对外提供的访问方式并不是应用程序直接打开数据文件来操作数据库，而是通过一种two-task的模式提供服务，即通过实例的逻辑结构去访问数据库。一个实例在一个时间点只能打开一个数据库，而一个数据库可以同时被多个实例打开rac。

       7.p14,用ipcs命令，可以看共享内存的情况。

       8.p15,在本机上连接本机数据库，不需要经过sql*net，而是通过ipc机制进行通信，就是beq协议。如果通过sql*net，就是tcpip协议。

       9.p16,存储共享技术，san,netapp,nfs。

 

       1月16日

       读第二章 理解db cache，这章读不大懂，性能调优时用的比较多，latch等待事件

       1.db cache存储的技术磁盘上block的完整镜像

       2.定位db cache中的数据块是通过散列算法实现的。有个hash链结构，hash链是由多个bucket组成的多链结构，每个bucket就是一个链的头。通过数据块所在的文件号和块号，进行散列运算，得到bucket的位置，从链头的双向链表扫描下去，即可找到相关的数据块。

       3.访问hash链时，为了一致性，通过cache buffers chains栓保护。

       4.多缓冲区技术可以有效地避免数据库缓冲区的抖动。

       5.p48,db cache的相关参数的锁和等待事件。

 

      1月17日 第三章 这一章基本理解不动，以后回来再专门研究

       1.共享池主要包括字典缓存row cache和库缓冲library cache两个部分，但是还有很多其他结构。

        select pool,name,bytes from v$sgastat where pool='shared pool';

       2.为了确保共享池中共享数据的访问性能，共享池每次内存分配都必须是联系的内存空间，这引起碎片。各个会话在共享池中分配空间时，所需要的空间差别很大，有的几十字节，有的甚至要几M。

       3.共享池中分配的内存，有些是永久使用，不会释放的，被标示为permanent,如进程信息、会话信息，是根据processes和sessions在启动时一次分配的，不会动态扩展，加大processes时，必须重启实例才能有作用。     

       4.子池技术解决了较大共享池在并发访问方面的性能问题。

 

       第四章 理解控制文件

       1.p133，转储控制文件

        oradebug setmypid;

        oradebug dump controlf 3;

 

       1月25日 第五章 理解redo日志

       1.oracle为了实现数据库崩溃时，不会丢失已提交的数据，将变化数据记录在redo日志文件中，通过redo-write-ahead(RWA)机制确保数据库在变更之前，其变更的redo日志信息必须先写入日志缓冲区，而事务提交之前也必须首先将日志缓冲中和这个事务相关的redo信息写入redo日志文件。

       2.redo日志被设计为多个组，一个数据库可以包含多个redo日志组。这样设计的好处是，当一组redo日志完成后，可以切换到另外一组上面继续写，因此没有必要马上清除当前redo日志中的信息，由于某些数据块的写盘操作还没完成，这些信息不能马上清除，否则数据库宕机后就没办法恢复了。

       3.介质恢复和实例恢复的概念：instance recovery的目的是在数据库发生故障时，确保数据块缓冲区中的数据不会丢失，不会造成数据库的不一致。介质恢复的目的是当数据库文件发生故障时，能够恢复数据。

       4.redo日志的数据是按照线程来组织的。对于单实例系统来说，只有一个线程，对于RAC来说，可能有多个线程，每个数据库实例拥有一组独立的redo日志文件和独立的日志缓冲区。

       5.对于介质恢复和实例恢复来说，第一个步骤都是通过redo日志的信息进行前滚。在做前滚时，通过redo日志文件里记录的数据库变化矢量，根据SCN的比对，提交到相关的数据文件上，从而使数据文件的状态向前滚动。undo表空间的变化也被记录在redo里，因此redo也会前滚。当前滚到最后一个可用的redo日志或者归档日志时，所有的数据库恢复层面的工作完成。介质恢复必须手工执行recover database或者recover datafile命令实现，而实例恢复是字典的。一般的，介质恢复是以一个恢复数据文件为起点的，所以要用到归档日志。

        6.两个问题需要解决，第一个问题是如何确保已经提交的事务不会丢失，第二个如何在数据库性能和实例恢复所需的时间上做平衡。解决第一个问题，是用log-force-at-commit，就是在事务提交时，和这个事务相关的redo日志数据，包括commit记录，都必须从日志缓冲区写到redo日志文件，此时事务提交成功的信息才能发送给用户进程。第二个问题是通过checkpoint机制实现的。某个数据块被写回文件的时间具有随机性，有些先修改的数据块可能比较晚才被写入文件，checkpoint补充了这种情况，当发生checkpoint时，ckpt进程要求dbwr进程将某个SCN一起的所有数据变更都已经存盘。如果之后发生实例故障，就只需要从这次checkpoint之后再进行了。

        7.如果数据文件的变化已经写盘，但是redo日志信息还在日志缓冲区中，没有写入redo日志，怎么办？这里有个write-ahead-log，日志写入优先机制。在某个缓冲区的修改变化矢量没有写入redo日志文件之前，这个修改后的数据不被允许写入数据文件，在对某个数据的undo信息的变化矢量没有被写入redo日志之前，这个缓冲区的修改不能被写入数据文件。

        8.cv，变化矢量，一个CV只针对一个数据块的变更，一个CV只包含一个变化。每个CV都包含了对文件的修改，都有一个OPCODE指出修改的类型，不同的OPCODE的CV，其组成也是不同的。redo记录是由一组CV组成的，这组CV完成对数据库的一个原子修改操作。当前台进程要对某个数据块进行修改时，首先形成相关的CV，然后把多个CV组成REDO记录，再把REDO记录写到日志缓冲区后，前台进程可以将CV提交到相关的数据块上。P147上有实验可以试试。

 

       第六章 理解Undo

       1.undo是事务层面的组件，实现数据库的事务回滚和一致性读。

       2.ITL，在一个数据块被格式化后，首先会默认创建数个ITL，当ITL空间不够时，系统会另外分配24B扩展一个新的ITL。一个事务要修改某个数据块中的某条记录时，首先找到一个空闲的ITL槽，然后将该ITL槽的序号登记在这个数据行的头部。

       3.同一个事务如果再一个block里修改了多条记录，只需要申请一个ITL槽，事务提交或者回滚后，ITL槽解除锁定，其他事务可以再次使用。如果块中已经无法再分配新的槽了，那么事务只能等待ITL，产生LMODE为4的TX行锁。

        4.一致性读也依赖TIL。如果读操作在读取某个数据块中的数据时，发现这个数据太新了，就会根据这条数据头部的ITC标示找到这个ITC通过ITL的UBA,并找到其修改前的前映像数据，从而读取较早的数据。

 

        1月28日 第7章 理解PGA、临时表空间和排序

        1.临时段管理是一种只分配不释放的算法，因此对于7.3以后的版本，临时表空间使用率接近100%是十分正常的，可通过V$sort_usage和v$sort_segments了解使用情况。

 

         第8章 理解ASM的结构

        1.ASM解决了裸设备难以使用的问题，只要将磁盘或逻辑卷放入disk group即可；磁盘组创建数据文件时，ASM会对文件进行条带化处理，安装文件类型，选取合适的条带值，将文件分布到所有的磁盘上，避免因某些磁盘访问过于频繁而造成的IO性能。Asm有更好的容错性，避免单点失败导致的数据丢失。

       2.ASM的存储结构：磁盘块、分配单元、扩展、ASM文件（对应数据文件）、ASM磁盘组（对应数据库）、ASM磁盘。

             

       第9章 理解数据块结构

       1.所有的数据块都包含相同的头结构kcbh，版本分为v7和v8。以V8为例，块头由20B组成，位于块的起始部分，结构如下：

       0 类型；1 格式；2,3 填充；4-7 RDBA；8-11 SCN BASE;12-13 SCN WRAP;14 序列号；15 标志；16-17 校验和；18-19 填充

       RDBA：该块的相对数据库地址，共32位，高10位表示相对文件号，低22位表示块号

       SCN BASE、SCN WRAP:对应当前redo生成的SCN.SCN由SCN base和scn wrap两部分组成。

       序列号：在当前的SCN下，该块可能会产生多次变化，使用序列号区分，如果SCN增长变化了，序列号复位为1.

       标志(flg_kcbh),由一些位值组合而成，这些位值包括：kcbhfnew 0x01 新建块;kcbhfdlc 0x02 数据块延迟清洗推进SCN和序列号；kcbhfckv 0x04 设置校验和；kcbhftmp 0x08 临时块

       校验和chkval_kcbh：可选，如果设置了db_block_checksum，将会企业校验和坚持数据块的一致性。

       数据块的最后4字节为块尾，配合块头校验数据块的一致性。如果一个块被标示为软损坏，那么块头的序列号为0xff,标志位0x00

       2.事务型的数据块存放表和索引的数据，由块头、事务层、数据层和块尾4部分组成。其中事务层由头结构和ITL组成。ITL是一个可变长的数组，当某个事务修改或准备修改(for update)该块中的行时，会首先在ITL中寻找一个空闲的插槽，如果没找到，就动态扩展ITL,然后再空闲插槽里填写相关的事务信息。事务层头结构如下：

0 块类型；1-3 填充；4-7 对象段号；8-15 最后清洗SCN，16-17 ITL数；18 标志；19 锁；20-23 块指针。

ITL数组的每个插槽由24个字节组成，结构为：

 0-1 回滚段；2-3 插槽号；4-7 undo wrap；8-14 undo 地址；15 保留；16-17 标志；18-19 SCN WRAP;20-23 SCN base

回滚段：对应事务所在的回滚段编号

插槽号：对应事务在回滚段事务表中的插槽号

undo wrap：对应事务在回滚段事务表中的wrap值。它和前面两个字段一起唯一标示一个事务，相当于事务的主键

undo地址：最后胜出的undo记录地址，格式为：undo dba(4字节)+序列号（2字节）+记录号（1字节）

如果某行在事务中被修改了多次，每次都会生成undo记录，这些记录被反向链接到一起，在回滚时，向前逐个实施undo记录，最终回滚到某个保存点活事务的启动。

标志：高4位表示事务的提交状态，低12位保存该事务修改的本块的行数。

 

       1月29日 第10章 理解表的结构

       1.块是oracle的最小访问单位，extent是最小的分配单位，因为块太小了，如果表中的存储数据按照块来分配，效率太低了，扩展是一组连续的块，oracle在给对象分配空间时，至少分配一个扩展。连续是指逻辑上的连续，在条带化前提下，在物理磁盘上并不一定是连续的磁盘。

        2.一组结构相同的扩展构成段，常见的段包括表、索引、表分区、索引分区、回滚段等。段存储在某个表空间里。

        3.行链：update时，记录所在的块已没有空闲空间能存放新的值，oracle会把这条记录整个迁移到另外一个有足够空闲的block中，而在原来记录的地方登记一个指向新位置的指针。

        4.所有数据访问都会在有效的扩展中进行，不会去扫描碎片所在的数据块，所以认定表空间碎片会影响性能是错误的。

        5.buffer busy waits等待事件，是热块。产生等待的可能是段头、数据块或Undo数据块，处理方式都不一样。

        6.p265页的案例写的非常精彩。

 

        1月30日 第11章 理解索引

         1.使得where 字段 like '%ABC'这样的结构使用索引，创建翻转索引create index 索引名 on table(col) reverse，这样并不能使用索引，where应写为reverse(col) like 'CBA%'。这是一个广泛流传的错误。P281页，可以证实下。

        2.p292页有个分析索引碎片化的脚本。

        3.在线重建索引是一个高风险的操作，最好再后台nohup方式执行。P293页

        4.awr里buffer get大的sql，一般是需要看看处理索引的语句。non-parse cpu比例低，是解析消耗CPU高。

        5.p296优化案例极好，反复理解几遍。

 

         第11章 理解分区

         1.每个分区都有独立的和表一样的存储结构、独立的段头、位图和高水位标志，这就绝对了在大并发时更有优势。

         2.一个表的并发更新非常频繁，虽然表不大，但表上的buffer busy waits等待很严重，用hash分区会更好，这有利于解决热块冲突。p310

         3.交换分区，在做历史数据归档时用着很方便。p313

         4.出现enq:HW或者enq:FB,这种锁等待是由高水位推进或者格式化数据块引起的，在RAC出现gc current grant也和高水位有关。插入数据时，如果没有空间了，就需要格式化新的数据块，默认为5，在格式化完成之前，所有要插入数据的会话等待HW/FB锁,rac出现gc current grant。

 

        1月31日 第13章 理解序列

         1.设置了cache后，第一个值从基表取，以后就从共享池取，设置较大的cache会有效的提示访问性能。大型系统中可能要设置1000，甚至5000.

         2.order选项强制严格的时间顺序，如果记录没有非常严格的时序，不要用，在RAC环境里，order属性会带来很严重的性能问题。

 

       第14章 问题分析综述

       1.作者提到的几个好习惯，是非常关键的。尤其一点，secureCRT的日志，这个千万要注意，以后要设置，这个在“文件”-“记录会话”。另外提到的解决问题后写一个文档，这点也必须要坚持，还有几点，都很中肯。

       关于secureCRT的日志设置如下：选项-全局选项-常规-默认会话，在弹出窗口点“编辑默认设置”，然后弹出窗口点“日志文件”，这里可以选择追加方式产生日志，另外，连接会话后，点开文件-记录会话，以后就会自动记录日志了。

      

       几个好习惯：

       去客户现场之前，要和客户先沟通一下，了解工作的范围和重点，针对性的做一些准备

       学会倾听，认真听取客户的想法

       操作之前，应打开各种日志，比如secureRT的日志

       事先编辑好脚本

       碰到无法把控的风险，尽量咨询下别人，或者自己隐藏到二线，不要轻易把自己置于未知的危险境地

       离开客户现场，要和相关负责人沟通，说明本次工作的内容，做了什么事情，有什么建议等。

       完成项目后，要尽快写一份记录本次工作的文档。

 

       第15章 DBA分析思路探讨

       1.在unix系统上，查看ora报错的相关信息：oerr ora 942，会显示case和action内容。

      

       下面该看part 3了，不看了，马上要过年了，只剩下3个工作日了，过年之后再看。总结一下：

        这本书从1月15号到今天，看了半个月，读了前15章，这个读书笔记里记录了一些我认为的要点，或是以前不知道的，或是以前理解错误的，我打算春节期间好好读读这个读书笔记，另外利用这11天的休息时间，再就某些点认真读读书。这第一遍还是非常粗略的，过年后，需要再读一遍，那时的读，就得是以操作为主了，对主题展开深入的探讨，做实验，记笔记了。

   

 

        2月17日 第15章 DBA分析思路的探讨

       1.问题分析总思路：积累自己的脚本、归类故障的类型：操作系统方面的故障、数据库功能故障、性能故障、net故障、SQL性能故障，另外提到一点，看日志，非常重要。

       2.性能分析的总体思路：

       起点：等待事件/系统开销

                  OS和数据库日志

                  系统和SQL情况：top sql/top session

                  下面是分支：如果是pl/sql的，用profiler,看执行计划，用autotrace,10046,awr,dbms_xplain；

                                       如果是系统的，用owi和性能分析，arw,ash,statspack，接着hangnaalyze分析，接着系统调用，用tusc,truss,pstack分析

       

 

 

      

      

 

     

 

       

       

      

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/263455/viewspace-752664/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/263455/viewspace-752664/