oracle数据库迁移redo log的方式有哪些？

简要说一下吧，相信这些步骤的具体 *** 作你都懂的

方案1:停止数据库实例迁移redo log

a、查询数据redo log

b、关闭数据库

c、拷贝redo log到新的存储路径

d、将数据库启动到mount状态

e、重命名redo log成员

f、打开数据库

g、检查确认日志迁移成功

方案2:在线迁移redo log

a、查询当前redo log组

b、添加新的redo log组

c、查看添加新日志组后的日志情况

d、删除旧的日志组

e、检查迁移后的redo log

f、检查之前的redo log文件是否已经成功删除，没有删除可以手动删除

还有以下Oracle数据库方面的知识可以去OTPUB网站进行进一步的了解。

Oracle的数据库日志称为Redo log 所有数据改变都记录Redo log 可以用于修复受损的数据库 Redo log 是用于恢复和一个高级特性的重要数据 一个redo条目包含了相应 *** 作导致的数据库变化的所有信息 所有redo条目最终都要被写入redo文件中去

Redo log buffer是为了避免Redo文件IO导致性能瓶颈而在sga中分配出的一块内存 一个redo条目首先在用户内存(PGA)中产生 然后由oracle服务进程拷贝到log buffer中 当满足一定条件时 再由LGWR进程写入redo文件 由于log buffer是一块 共享 内存 为了避免冲突 它是受到redo allocation latch保护的 每个服务进程需要先获取到该latch才能分配redo buffer 因此在高并发且数据修改频繁的oltp系统中 我们通常可以观察到redo allocation latch的等待 Redo写入redo buffer的整个过程如下

在PGA中生产Redo Enrey >服务进程获取Redo Copy latch(存在多个 CPU_COUNT* ) >服务进程获取redo allocation latch(仅 个) >分配log buffer >释放redo allocation latch >将Redo Entry写入Log Buffer >释放Redo Copy latch

shared strand

为了减少redo allocation latch等待 在oracle 中 引入了log buffer的并行机制 其基本原理就是 将log buffer划分为多个小的buffer 这些小的buffer被成为strand(为了和之后出现的private strand区别 它们被称之为shared strand) 每一个strand受到一个单独redo allocation latch的保护 多个shared strand的出现 使原来序列化的redo buffer分配变成了并行的过程 从而减少了redo allocation latch等待

shared strand的初始数据量是由参数log_paralleli *** 控制的在 g中 该参数成为隐含参数 并新增参数_log_paralleli *** _max控制shared strand的最大数量_log_paralleli *** _dynamic则控制是否允许shared strand数量在_log_paralleli *** 和_log_paralleli *** _max之间动态变化

HELLODBA >select  nam ksppinm val KSPPSTVL nam ksppdesc

    from    sys x$ksppi nam

            sys x$ksppsv val

    where nam indx = val indx

    AND   nam ksppinm LIKE _%

    AND   upper(nam ksppinm) LIKE %LOG_PARALLE%

KSPPINM                    KSPPSTVL   KSPPDESC

_log_paralleli ***                      Number of log buffer strands

_log_paralleli *** _max                 Maximum number of log buffer strands

_log_paralleli *** _dynamic   TRUE       Enable dynamic strands

每一个shared strand的大小 = log_buffer/(shared strand数量) strand信息可以由表x$kcrfstrand查到(包含shared strand和后面介绍的private strand g以后存在)

HELLODBA >select indx strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa !=

      INDX STRAND_SIZE_KCRFA

                   

                   

HELLODBA >show parameter log_buffer

NAME                                 TYPE        VALUE

log_buffer                           integer    

关于shared strand的数量设置 个cpu之内最大默认为 当系统中存在redo allocation latch等待时 每增加 个cpu可以考虑增加 个strand 最大不应该超过 并且_log_paralleli *** _max不允许大于cpu_count

注意 在 g中 参数_log_paralleli *** 被取消 shared strand数量由_log_paralleli *** _max _log_paralleli *** _dynamic和cpu_count控制

Private strand

为了进一步降低redo buffer冲突 在 g中引入了新的strand机制 Private strand Private strand不是从log buffer中划分的 而是在shared pool中分配的一块内存空间

HELLODBA >select * from V$sgastat where name like %strand%

POOL NAME BYTES

shared pool private strands

HELLODBA >select indx strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa =

INDX STRAND_SIZE_KCRFA

Private strand的引入为Oracle的Redo/Undo机制带来很大的变化 每一个Private strand受到一个单独的redo allocation latch保护 每个Private strand作为 私有的 strand只会服务于一个活动事务 获取到了Private strand的用户事务不是在PGA中而是在Private strand生成Redo 当flush private strand或者mit时 Private strand被批量写入log文件中 如果新事务申请不到Private strand的redo allocation latch 则会继续遵循旧的redo buffer机制 申请写入shared strand中 事务是否使用Private strand 可以由x$ktcxb的字段ktcxbflg的新增的第 位鉴定

HELLODBA >select decode(bitand(ktcxbflg ) ) used_private_strand count(*)

from x$ktcxb

where bitand(ksspaflg ) !=

and bitand(ktcxbflg ) !=

group by bitand(ktcxbflg )

USED_PRIVATE_STRAND COUNT(*)

对于使用Private strand的事务 无需先申请Redo Copy Latch 也无需申请Shared Strand的redo allocation latch 而是flush或mit是批量写入磁盘 因此减少了Redo Copy Latch和redo allocation latch申请/释放次数 也减少了这些latch的等待 从而降低了CPU的负荷 过程如下

事务开始 >申请Private strand的redo allocation latch (申请失败则申请Shared Strand的redo allocation latch) >在Private strand中生产Redo Enrey >Flush/Commit >申请Redo Copy Latch >服务进程将Redo Entry批量写入Log File >释放Redo Copy Latch >释放Private strand的redo allocation latch

注意 对于未能获取到Private strand的redo allocation latch的事务 在事务结束前 即使已经有其它事务释放了Private strand 也不会再申请Private strand了

每个Private strand的大小为 K g中 shared pool中的Private strands的大小就是活跃会话数乘以 K 而 g中 在shared pool中需要为每个Private strand额外分配 k的管理空间 即 数量* k

g:

SQL>select * from V$sgastat where name like %strand%

POOL NAME BYTES

shared pool private strands

HELLODBA >select trunc(value * KSPPSTVL / ) * *

from (select value from v$parameter where name = transactions ) a

(select val KSPPSTVL

from sys x$ksppi nam sys x$ksppsv val

where nam indx = val indx

AND nam ksppinm = _log_private_paralleli *** _mul ) b

TRUNC(VALUE*KSPPSTVL/ )* *

g:

HELLODBA >select * from V$sgastat where name like %strand%

POOL NAME BYTES

shared pool private strands

HELLODBA >select trunc(value * KSPPSTVL / ) * ( + ) *

from (select value from v$parameter where name = transactions ) a

(select val KSPPSTVL

from sys x$ksppi nam sys x$ksppsv val

where nam indx = val indx

AND nam ksppinm = _log_private_paralleli *** _mul ) b

TRUNC(VALUE*KSPPSTVL/ )*( + )*

Private strand的数量受到 个方面的影响 logfile的大小和活跃事务数量

参数_log_private_mul指定了使用多少logfile空间预分配给Private strand 默认为 我们可以根据当前logfile的大小(要除去预分配给log buffer的空间)计算出这一约束条件下能够预分配多少个Private strand

HELLODBA >select bytes from v$log where status = CURRENT

BYTES

HELLODBA >select trunc(((select bytes from v$log where status = CURRENT ) (select to_number(value) from v$parameter where name = log_buffer ))*

(select to_number(val KSPPSTVL)

from sys x$ksppi nam sys x$ksppsv val

where nam indx = val indx

AND nam ksppinm = _log_private_mul ) / / )

as calculated private strands

from dual

calculated private strands

HELLODBA >select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa =

actual private strands

当logfile切换后(和checkpoint一样 切换之前必须要将所有Private strand的内容flush到logfile中 因此我们在alert log中可能会发现日志切换信息之前会有这样的信息 Private strand flush not plete 这是可以被忽略的) 会重新根据切换后的logfile的大小计算对Private strand的限制

HELLODBA >alter system switch logfile

System altered

HELLODBA >select bytes from v$log where status = CURRENT

BYTES

HELLODBA >select trunc(((select bytes from v$log where status = CURRENT ) (select to_number(value) from v$parameter where name = log_buffer ))*

(select to_number(val KSPPSTVL)

from sys x$ksppi nam sys x$ksppsv val

where nam indx = val indx

AND nam ksppinm = _log_private_mul ) / / )

as calculated private strands

from dual

calculated private strands

HELLODBA >select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa =

actual private strands

参数_log_private_paralleli *** _mul用于推算活跃事务数量在最大事务数量中的百分比 默认为 Private strand的数量不能大于活跃事务的数量

HELLODBA >show parameter transactions

NAME TYPE VALUE

transactions integer

transactions_per_rollback_segment integer

HELLODBA >select trunc((select to_number(value) from v$parameter where name = transactions ) *

(select to_number(val KSPPSTVL)

from sys x$ksppi nam sys x$ksppsv val

where nam indx = val indx

AND nam ksppinm = _log_private_paralleli *** _mul ) / )

as calculated private strands

from dual

calculated private strands

HELLODBA >select count( ) actual private strands from x$kcrfstrand where last_buf_kcrfa =

actual private strands

注 在预分配Private strand时 会选择上述 个条件限制下最小一个数量 但相应的shared pool的内存分配和redo allocation latch的数量是按照活跃事务数预分配的

lishixinzhi/Article/program/Oracle/201311/16501

第一步：首先在spfile中添加一下内容： UTL_FILE_DIR=C:\TEST(该路径任意取)第二步：重启数据库，让第一步配置的参数生效第三步：创建字典文件： EXEC DBMS_LOGMNR_D.BUILD('A.ORA','C:\TEST')第四步：将待查询内容的日志文件添加到字典中去 EXEC DBMS_LOGMNR.ADD_LOGFILE('C:\oracle\product\10.2.0\oradata\haige\REDO01.LOG',DBMS_LOGMNR.NEW)如果还要添加日志文件，则将DBMS_LOGMNR.NEW改为DBMS_LOGMNR.ADDFILE第五步：分析数据 EXEC DBMS_LOGMNR.START_LOGMNR(DICTFILENAME=>'C:\TEST\HAIGE.ORA')第六部：查看内容 数据均存在于V$LOGMNR_CONTENTS中； SELECT TIMESTAMP,USERNAME,SQL_REDO FROM V$LOGMNR_CONTENTS

---