08-Oracle_10g_Undo表空间管理.ppt

1、对于DML语句来说，只要修改了数据块，Oracle数据库就会将修改前的数据块保留下来，保存在undosegment里面，而undosegment则保存在undo表空间中2、undo的管理1、自动undo管理（Oracle9i开始）AUM2、手工undo管理MUM9i以后，就建议使用AUM，因此就不再讨论MUM,一条DML语句的执行流程updatetsetcoll=Awherecoll=B1、在sharedpool里面进行解析，从而生成执行计划2、根据执行计划，得出coll=B的记录存放在10号数据文件的54号数据块里面3、服务器进程首先在buffercache寻找一个可用的undo数据块（如果一个事物已经提交，那么这个事务曾经使用过的undo数据块就可以被使用），如果没有发现，则到undo表空间里找到一个可用的undo数据块，并调入到buffercache。假设获得的undo数据块号为24号，位于11号undo数据文件里4、将改变前的值，也就是B放入24号undo数据块（buffercache中）5、由于undo数据块发生了变化（只要是数据块发生变化，那么就产生重做记录），于是产生重做记录，假设重做记录号是120,6、在buffercache里面找到54号数据块，如果没有，则从10号数据文件调入7、将改变后的值，也就是A放入54号数据块8、由于数据块发生了变化，于是产生重做记录，假设重做记录号是121,9、控制权返回给用户，如果使用SQLPLUS，那么表现为光标返回10、用户发出commit命令，触发LGWR，将120、121这两个重做记录写入联机重做日志文件中，将54号、24号两个数据块头部所记录的事务状态标记设置为已提交，控制权返回给用户，如果使用SQLPLUS，那么表现为光标返回11、这个时侯，54号和24号数据块并不一定被DBWr写入数据文件，只有在脏数据块的数量达到一定程度的时候才会被写入事务提交以后，该事务所使用的undo数据块就可以被覆盖，上面的例子中，第10步用户提交以后，24号undo数据块就可以被覆盖,Undo的作用1、提供读一执性2、回滚事务3、实例恢复,读一致性一个场景描述读一致性是相对脏读而言的，表T中有10000条记录，获取所有的记录需要15分钟的时间，当前时间为9点整，用户发出一条select*fromT命令，该语句在9：15完成。当用户执行该语句到9：10分的时候，另外一个用户发出了一条删除命令，将最后一条记录删除，并且进行了提交。到9点15分的时候，用户返回了多少条记录。如果是9999条，那么就是脏读、如果是10000条，那么就是读一致性。Oracle不会出现脏读，提供读一致性，而且没有阻塞DML操作,Oracle如何实现读一致性呢？1、用户在9点发出select语句的时候，服务器进程会记录9点那个时刻的SCN号（SCN号是以时间（timestamp）作为参数的一个函数返回值，调用函数（默认以timestamp为参数）随时可以返回这个时刻的SCN号，可以使用函数在SCN和timestamp之间进行转换），假设该SCN号是SCN9.00，那么SCN9.00一定大于等于记录在所有数据块头部的ITL槽中的SCN号（如果有多个ITL槽，SCN最大的哪个）2、服务器进程扫描T表的时候，会把扫描的数据块头部的ITL槽中的SCN号与SCN9.00进行比较，哪个更大。如果数据块头部的SCN小于SCN9.00，那么说明这个数据块在9：00以后没有更改过，可以直接读取，如果数据块头部的SCN号大于SCN9.00，则说明该数据块在9.00以后更改过，已经不是9.00那个时刻的数据了于是要借助undo块3、9点10分，用户更改了T表的最后一条记录并提交（无论是否提交，只要是更改了T表，用户就会去读undo数据块），假设被更改的是N号数据块，那么N号数据块头部的ITL槽中记录的SCN被修改为SCN.910，当服务器进程扫描到这个数据块的时候，发现ITL槽中的SCN9.10大于SCN9.00，说明该数据块在9.00以后被更新了，于是服务器进程到N号块的头部，找到SCN9.10所在ITL槽，由于ITL槽记录了对应的undo块的地址，于是服务器进程找到undo数据块，结合undo数据块给用户提供读一致性。,进一步复杂化问题1、9点10分，更新了数据并且进行了提交，9点11分又对该数据块进行了更新并且提交（假设数据块只有一个ITL槽）2、那么该ITL槽记录的就是SCN9.113、这种情况如何处理，秘密在于undo数据块中，除了记录改变前的数据以外，因为数据块的ITL槽也发生了变化，因此也进行了记录，而ITL槽中记录了undo块的地址9：00的时候数据块的ITL槽中记录了数据块的SCN是8.50和对应的undo块，9.10分的时候数据库的ITL槽中记录了数据块的SCN是9.10和对应的undo（undo1）9.11分的时候数据库的ITL槽中记录了数据块的SCN是9.11和对应的undo（undo2）Undo2中记录了9.10的数据，以及9.10数据的undo地址undo1，undo1中记录了9点以前的数据以及9点以前的undo数据,当用户进行查询的时候，服务器进程扫描到N号数据块，发现SCN9.11，大于SCN9.00，从ITL槽中找到undo块的地址（undo2），undo2中记录了改变前的数据和改变前的数据库的ITL槽，发现undo2对应的SCN是9.10还是大于9.00，根据undo里面记录的ITL槽的改变前信息，继续向前找，找到undo1，发现SCN是8.50，小于9.00，使用这个undo的数据如果在向前寻找的时候，没有找到SCN小于9.00的数据（因为时间比较长，而且事务已经提交，所以回滚段可能被覆盖），数据库就会出现一个经典的错误ORA-1555（snapshoottooold），但是不会出现脏读的情况。,最核心的就是：数据块的数据发生改变，ITL槽也发生改变。这两条信息都会存储到undo中。因此如果一个undo足够的大，那么一个数据块的所有的undo数据块是可以串联起来的。可以从最近一直找到非常远的过去。从数据块开始往前找，一直找到很久以前的SCN。这个数据块所有的变化都能够找到。ITL槽中记录着这个数据块的undo数据块的地址。一个数据块中存储很多条数据，update、insert、delete等DML操作，都会影响数据块的SCN号。数据块的SCN号反映了数据块的变化过程。,回滚事务：错误或者rollback命令都会产生回滚根据ITL槽中记录的undo数据块的地址，找到undo数据块，恢复数据。实例恢复回滚段的头部记录了事务表，每一个事务是否提交等信息都存储在里面。根据事务表的信息进行实例恢复。,配置AUM使用AUM需要配置两个参数,Oracle9i开始，我们不再使用手工的管理方式，因此“manual”不再使用，使用“auto”,指定这两个参数以后，剩余的工作让Oracle来处理，例如undosegment的创建、扩展、收缩、删除等。,如果指定了undo_management，但是在指定undo_tablespace的时候，指定了一个错误的回滚表空间，实例启动的时候，会报错。如果没有指定回滚段表空间，系统查找第一个可用的回滚段表空间，如果没有找到，那么就使用system表空间中的回滚段，这不是我们希望看到的，因为对性能影响很大。因此两个参数都要很好的规划,事务、undosegment发生DML操作的时候，服务器进程会选择一个undosegment，具体算法如下：1、首先尝试将每一个undosegment绑定一个事务，也就是每个undosegment上只有一个事务使用2、如果不能发现完全空闲的undosegment，所有的undosegment都与事务绑定3、系统尝试将脱机的undosegment联机4、如果没有可用的undosegment进行联机，则会尝试创建一个新的undosegment5、如果上面的步骤都没有成功（例如没有可用空间了，不能创建undosegment），算法会尝试寻找最早使用的undosegment，这种情况下，不同的多个事务会在同一个相同的undosegment里同时进行6、每隔12个小时会收缩一次，删除那些idle状态的extent7、DML操作需要undo时，发现空间不够，则会唤醒SMON进行一次收缩将undosegment里面暂时没有使用的extent拿过来使用,Oracle在提供一致性读的过程中，具体的步骤如下1、确认读时刻的SCN2、搜寻所有的数据块的SCN要求小于读时刻的SCN3、如果搜寻的SCN小于读时刻的SCN，直接读取4、如果搜寻的SCN大于读时刻的SCN，根据数据块里面的ITL槽里面记录的undo信息，找到改变前的数据、如果SCN还是大，顺着ITL槽信息串联起来的undo块继续向前找5、如果没有找到小于读时刻的SCN的数据块，那么就报错ORA-1555事务提交以后，undo回滚段就可以被覆盖，而且我们在寻找undo数据块的时候，这个被寻找的undo数据块很可能已经被提交，因此出现ORA-1555错误不可避免。Oracle是如何来解决这个问题的呢？,Oracle定义了一个参数undo_retention这个参数以秒为单位，表示当事务提交或者回滚以后，该事务所使用的undo块里的数据需要保留多长时间。当保留的时间超过undo_retention所指定的时间以后，该undo块才能够被其他事务覆盖。当我们使用AUM的时候，并且设置了undo_retention以后，undo块的状态就存在4种Active：表示正在使用该数据块的事务还没有提交或者回滚Inactive：该数据块上没有活动的事务，该状态的undo可以被其他事务覆盖Expired：该数据块持续inactive的时间超过undo_retention所指定的时间Freed：该数据块是空的，从来没有被使用过,在AUM模式中，事务可以在不同的undosegment之间动态交换undo空间，也就是在不同的undosegment里交换extents。我们来看一下，一个事务需要更多的undo空间的时候，是如何进行处理的？1、获取undo表空间里可用的、空的extents（segment的最小分配单元是extent）2、获取其他undosegment里的expired状态的extents3、如果undo表空间里的数据文件启用了自动扩展，则数据文件进行自动扩展4、如果undo表空间里的数据文件没有启用自动扩展，则获取undosegment里的inactive状态的extents5、如果还是没有获得可用空间，报空间不足的错误,1、undo表空间中一共存在5个undosegment2、每个undosegment包括7个extents3、当使用US5的事务需要额外的空间的时候，首先使用两个F状态的extent，如果还不够用，继续使用US4里面三个F状态的extents，如果还不够用，使用US3里面X状态的extents，如果还不够用，继续使用US1里面I状态的extent，如果好不够用，报空间不足的错误。假设上面的数据文件没有配置自动扩展,1、AUM里面分配extent的方式是高效率的，而且尽量避免使用I状态的extent。2、在Oracle10g里面，如果undo表空间足够，那么Oracle会将undo信息保留的时间与当前运行时间最长的查询所需要的时间相同（一个很好的优势，最大限度的避免了ORA-1555）3、默认情况下，oracle每隔30秒就收集统计信息来自动调整undoretention，收集的信息包括运行时间最长的查询产生undo的速度我们通过设置undo_retention为0，那么就使用上面的自动调整功能，而且以900秒为最低限如果我们设置了undo_retention，那么就使用这个参数作为undo_retention的值，不再支持动态的调整undo_retention,4、如果undo_retention设置为0，则实例会获取运行时间最长的那个查询所需要的时间，例如N秒，然后将undo信息保留N秒，当undo表空间尺寸太小时，而不能保留这个最长时间，则尽可能的利用现有空间来让undo保留的时间尽可能的长，并不会立刻扩展undo数据文件，除非要覆盖的undo信息是在900秒以内发生的，才会去扩展数据文件。,管理undo表空间1、一些常规性的操作，例如添加数据文件、重命名数据文件、将数据文件联机或者脱机，和普通的表空间操作没什么两样。可以通过EM来进行操作2、一个数据库可以有多个undo表空间，但是在一个时刻，只能有一个undo表空间起作用，通过参数undo_tablespace设置来指定一个undo表空间,上面做了一个undo表空间的切换1、旧的表空间上有事务正在执行，则该旧的表空间变成pendingoffline。2、用户事务正常运行，切换操作结束，不会等待旧的undo表空间的事务结束3、切换以后，所有新的事务所产成的undo数据不会存放在旧的undo表空间，而是会使用新的undo表空间4、pendingoffline状态的undo表空间不能被删除5、旧的undo表空间上的所有的事务都提交以后，旧的undo表空间从pendingoffline状态变成offline状态，表空间可以删除6、droptablespaceundotbs1相当于droptablespaceundotbs1includingcontents7、如果undo表空间包含inactive状态的undo数据块，不影响被删除，但是可能产生ORA-1555错误，因此最好等待超过undo_retention以后，再删除表空间,显示当前的活动事务，以及对undo的使用。,Undose