oracle如何将表的历史数据归档

oracle如何将表的历史数据归档,第1张

归档日志(ArchiveLog)是非活动的重做日志备份通过使用归档日志,可以保留所有重做历史记录,当数据库处于ARCHIVELOG模式并进行日志切换式,后台进程ARCH会将重做日志的内容保存到归档日志中当数据库出现介质失败时,使用数据文件备份,归档日志和重做日志可以完全恢复数据库

日志 *** 作模式:ARCHIVELOGNOARCHIVELOG

1,改变日志 *** 作模式:

检查当前日志 *** 作模式

SELECTlog_modefromv$database;

关闭数据库,然后装载数据库

SHUTDOWNIMMEDIATE

STARTUPMOUNT

改变日志 *** 作模式,然后打开数据库

ALTERDATABASEARCHIVELOG;

ALTERDATABASEOPEN;

2,执行手工归档

从oracledatabase10g开始,当将日志 *** 作模式转变未ARCHIVELOG模式时,oracle会自动启动ARCH进程如果要使用手工归档那么在改变日志 *** 作模式时必须使用命令ALTERDATABASEARCHIVELOGMANUAL

需要注意,使用手工归档方式,数据库管理员必须手工执行归档命令如果没有执行手工归档命令,日志组的原有内容将不能被覆盖ALTERDATABASEARCHIVELOGMANUAL命令是为了与先前的版本兼容而保留的,将来的oracle版本会淘汰该命令,使用手工归档方式是,数据库管理员可以执行以下命令归档重做日志:

SLTERSYSTEMARCHIVELOGALL;

3,配置归档进程

初始化参数LOG_ARCHIVE_MAX_PROCESSES用于指定例程初始启动的最大归档进程个数,当将数据库转变为ARCHIVELOG模式时,默认情况下oracle会自动启动两个归档进程通过改变初始化参数LOG_ARCHIVE_MAX_PROCESS的值,可以动态地增加或降低归档进程的个数:

ALTERSYSTEMSETLOG_ARCHIVE_MAX_PROCESSES=3;

配置归档位置和文件格式

当数据库处于ARCHIVELOG模式时,如果进行日志切换,后台进程将自动生成归档日志,归档日志的默认位置为%oracle_home%rdbms,在oracledatabase10g中,归档日志的默认文件格式为ARC%S_%R%T为了改变归档日志的位置和名称格式,必须改变相应的初始化参数,

1,初始化参数LOG_ARCHIVE_FORMAT用于指定归档日志的文件名格式,设置该初始化参数时,可以指定以下匹配符:

%s:日志序列号:

%S:日志序列号(带有前导0)

%t:重做线程编号

%T:重做线程编号(带有前导0)

%a:活动ID号

%d:数据库ID号

%rRESETLOGS的ID值

从10g开始,配置归档日志文件格式时,必须带有%s,%t和%r匹配符,配置了归档文件格式后,必须重启数据库

2,使用LOG_ARCHIVE_DEST配置归档位置

如果不使用备用数据库,只需要将归档日志存放到本地目录配置本地归档位置可以使用初始化参数LOG_ARCHIVE_DEST和LOG_ARCHIVE_DUPLEX_DEST,其中,第一个参数用于设置第一个归档位置,第二个参数用于指定第二个归档位置

ALTERSYSTEMSETlog_archive_dest=’d:demoarchive1’;

ALTERSYSTEMSETlog_archive_duplex_dest=’d:demoarchive2’;

3,使用LOG_ARCHIVE_DEST_n配置多个归档位置

初始化参数LOG_ARCHIVE_DEST_n用于指定多个归档位置,该参数最多可以指定10个归档位置通过使用初始化参数LOG_ARCHIVE_DEST_n,不仅可以配置本地归档位置,还可以配置远程归档位置

如果既要在主节点上生成归档日志,又要将归档日志传递到备用节点,那么必须使用参数LOG_ARCHIVE_DEST_n该参数与LOG_ARCHIVE_DEST具有如下区别;

初始化参数LOG_ARCHIVE_DEST_n可以配置本地归档位置和远程归档位置,而初始化参数LOG_ARCHIVE_DEST和LOG_ARCHIVE_DUPLEX_DEST只能配置本地归档位置

初始化参数LOG_ARCHIVE_DEST_n可以配置多达10个归档位置,而初始化参数LOG_ARCHIVE_DEST和LOG_ARCHIVE_DUPLEX_DEST最多只能配置两个归档位置

初始化参数LOG_ARCHIVE_DEST_n不能与初始化参数LOG_ARCHIVE_DEST和LOG_ARCHIVE_DUPLEX_DEST同时使用

因为初始化参数LOG_ARCHIVE_DEST_n不能与初始化参数LOG_ARCHIVE_DEST和LOG_ARCHIVE_DUPLEX_DEST同时使用,所以必须禁用初始化参数LOG_ARCHVE_DEST和LOG_ARCHIVE_DUPLEX_DEST当使用初始化参数LOG_ARCHIVE_DEST_n配置本地归档位置时,需要指定LOCALTION选项当配置远程归档位置时,需要指定SERVICE选项

示例如下:

ALTERSYSTEMSETlog_archive_duplex_dest=’’;

ALTERSYSTEMSETlog_archive_dest=’’;

ALTERSYSTEMSETlog_archive_dest_1=’location=d:demoarchive1’;

ALTERSYSTEMSETlog_archive_dest_2=’location=d:demoarchive2’;

ALTERSYSTEMSETlog_archive_dest_3=’location=d:demoarchive3’;

ALTERSYSTEMSETlog_archive_dest_4=’service=standby’;

配置远程归档位置时,SERVICE选项需要指定远程数据库的网络服务名(在tnsnamesora文件中配置)

4,使用LOG_ARCHIVE_DEST_n选项

使用初始化参数LOG_ARCHIVE_DEST_n配置归档位置时,可以在归档位置上指定OPTIONAL或MANDATORY选项指定MANDATORY选项时,可以设置REOPEN属性

OPTIONAL:该选项是默认选项使用该选项时,无论归档是否成功,都可以覆盖重做日志

MANDATORY:强制归档使用该选项时,只有在归档成功之后,重做日志才能被覆盖

REOPEN:该属性用于指定重新归档的时间间隔,默认值为300秒,必须跟在MANDATORY后

例:

Altersystemsetlog_archive_dest_1=’location=d:demoarchive1mandatory’;

Altersystemsetlog_archive_dest_2=’location=d:demoarchive2mandatoryreopen=500’;

Altersystemsetlog_archive_dest_3=’location=d:demoarchive3optional’;

5,控制本地归档成功的最小个数

使用初始化参数LOG_ARCHIVE_MIN_SUCCEED_DEST控制本地归档的最小成功个数

Altersystemsetlog_archive_min_succeed_dest=2;

6,使用初始化参数LOG_ARCHIVE_DEST_STATE_n控制归档位置的可用性设置该参数为ENABLE(默认值),表示会激活相应的归档位置;设置该参数为DEFER,表示禁用相应归档位置当归档日志所在磁盘损坏或填满时,DBA需要暂时禁用该归档位置

Altersystemsetlog_archive_dest_state_3=defer;(禁用)

Altersystemsetlog_archive_dest_state_3=enable;(启用)

显示归档日志信息

1,使用ARCHIVELOGLIST命令可以显示日志 *** 作模式,归档位置,自动归档机器要归档的日志序列号等信息

2显示日志 *** 作模式

SELECTname,log_modeFROMv$database;

3,显示归档日志信息

Colnameformata40

Selectname,swquence#,first_change#FROMv$archived_log;

Name用于表示归档日志文件名,sequence#用于表示归档日志对应的日志序列号,firs_change#用于标识归档日志的起始SCN值

4执行介质恢复时,需要使用归档日志文件,此四必须准确定位归档日志的存放位置通过查询动态性能视图v$archive_dest可以取得归档日志所在目录

SELECTdestinationFROMv$archivedest;

5,显示日志历史信息

SELECTFROMv$loghist;

THREAD#用于标识重做线程号,SEQUNCE#用于标识日志序列号,FIRST_CHANGE#用于标识日志序列号对应的起始SCN值,FIRST_TIME用于标识起始SCN的发生时间SWICTH_CHANGE#用于标识日志切换的SCN值

6显示归档进程信息

进行日志切换时,ARCH进程会自动将重做日志内容复制到归档日志中,为了加快归档速度,应该启用多个ARCH进程通过查询动态性能视图V$ARCHIVE_PROCESSES可以显示所有归档进程的信息!

SELECTFROMv$archive_processes;

Porcess用于标识ARCH进程的编号,status用于标识ARCH进程的状态(ACTIVE:活动,STOPPED:未启动),log_sequence用于标识正在进行归档的日志序列号,state用于标识ARCH进程的工作状态

对于重要的生产业务建议开启归档模式,通过对在线日志的归档,可以在数据丢失时进行数据恢复、部分 *** 作也只有在归档模式下才能实施、分析日志内容等。

对于非归档数据库开启归档功能 *** 作如下:

1)SQL

2)SQL

3)SQL

4)SQL

5)SQL

6)SQL

7)SQL

第一种方法

select name,log_mode from v$database;

-----------------------------------------------------------

第二种方法

archive log list

2,oracle启动归档模式?

startup mount

alter database archivelog;

alter database open;

alter system set log_archive_start=true scope=spfile;

修改数据库参数文件c:\oracle\admin\oradb\pfile\initora,

取消以下语句的#注释

log_archive_start = true

log_archive_dest_1 = "location=C:\Oracle\oradata\oradb\archive"

log_archive_format = %%ORACLE_SID%%T%TS%SARC

关闭数据库,重新启动

查看C:\Oracle\oradata\oradb\archive目录下,可以看到类似ORADBT001S01201ARC的文件,说明归档成功

解释initora参数文件中关于归档重做日志参数项的含义

归档模式是自动还是手工,true为自动,false为手工

log_archive_start = true

归档日志文件所保存的路径

log_archive_dest_1 = "location=C:\Oracle\oradata\oradb\archive"

归档日志文件的命名方法

log_archive_format = %%ORACLE_SID%%T%TS%SARC

2、禁止归档

a 关闭数据库shutdown immediate

b startup mount

c alter database noarchivelog

d alter database open

一 更改日志 *** 作模式三步走

默认情况下 Oracle数据库采用的是非归档模式 但是 非归档模式不能够防止因物理损坏而导致丢失数据问题 为此数据库管理员可能需要把日志 *** 作模式从非归档模式转换为归档模式 其实 要进行这个转换的话 只需要通过简单的三个步骤即可 不过在进行 *** 作之前 要需要注意 以下的 *** 作都必须要求用户具有数据库管理员的权限 即只有SYSDBA或者SYSOPER身份才能够执行如下的 *** 作

要更改日志 *** 作模式 具体 *** 作步骤如下

第一步 先确定当前的日志 *** 作模式 当数据库管理员更改当前 *** 作日志模式之前 需要先确定一下当前日志 *** 作模式 此时数据库管理员可以查询动态性能视图 来确认当前日志 *** 作模式 如可以利用如下语句来查询我们所需要的信息 动态性能视图中存储著很多数据库运行信息 从中我们数据库管理员可以获取很多有用的信息 如现在要了解当前数据库的日志 *** 作模式 就可以从数据库动态性能视图中获知

第二步 关闭数据库 如果确认数据库当前的日志 *** 作模式为非归档模式 需要把它改为归档 *** 作模式 需要先关闭当前运行的数据库 然后重新装载数据库 需要注意的是 更改日志 *** 作模式只能够在MOUNT状态下进行 因此必须首先关闭数据库 然后重新装载数据库 另外 如果需要更改日志 *** 作模式 那么在关闭数据库时不能够使用SHUTDOWN ABORT命令 SHUTDOWN ABORT命令的作用其实跟KILL进程具有同样的效果 若利用这个命令的话 可能会给数据库带来一些不利的因素 如可能导致文件状态不一致 在数据库正常关闭的时候 数据库会同步校验各个文件 使得重新启动的时候文件时间点一致并且不用进行崩溃修复 而使用这个命令不会进行这个检验 所以 采用SHUTDOWN ABORT命令关闭数据库的时候 可能会导致数据库启动出错 导致已经递交的数据丢失 甚至出现数据库崩溃的噩梦 所以 无论是在更换数据库日志 *** 作模式 又或者其他原因需要关闭数据库的 最好不要采用这个命令 只有在采用其他关闭数据库命令不能够奏效的情况下 才能够使用这个命令 笔者建议通过SHUTDOWN IMMEDIATE命令来关闭数据库

数据库关闭之后 再利用Startup命令 把数据库启动到MOUNT状态 再次提醒一次 只有在Mount状态下才能够更改日志 *** 作模式

第三步 更改日志 *** 作模式 以上准备工作做好之后 就可以利用相关命令来更改日志 *** 作模式 我们可以利用如下命令来进行更改

然后重新打开数据库之后 设置就生效了

二 手工对重做日志文件进行归档

有时候出于某些原因 数据库管理员可能需要手工对重做日志进行归档 在 G以后的版本中 默认情况下 当将日志 *** 作模式从非归档模式转换为归档 *** 作模式的时候 Oracle数据库会在后台自动启动一个ARCH进程 这个进程就是负责重做日志的备份任务 通常情况下 归档模式下 数据库会自动备份重做日志

若需要手工备份重做日志的话 即手工归档 则必须在改变 *** 作日志模式中明确说明 即在上面的命令中 加入MANUAL参数 如果加入这个参数后 则数据库管理员就必须手工执行归档命令 如果数据库管理员没有手工执行归档命令的话 则日志组中的内容就无法被进行覆盖 所以通常情况下 除了一些特殊的需要 如数据库测试 才使用手工归档方式 否则的话 就还是采用自动归档方式更加的合理 值得一提的是 根据笔者了解 这个参数只是一个过渡参数 主要为了跟以前的Oracle数据库版本兼容 估计在不久之后 这个手工归档的参数会取消掉

三 设置归档文件的存储位置

在 *** 作系统管理中 系统管理员往往会重新设置我的文档 IE收藏夹等存储位置 以防止系统奔溃时这些数据的丢失 其实 在Oracle归档日志文件管理中也是如此 当数据库管理员把日志 *** 作模式从非归档模式转换为归档模式时 需要根据实际情况 重新设置归档文件的存储位置

当数据库处于归档模式时 如果进行日志切换 后台进程将自动生成归档日志文件 归档日志文件的默认存储位置为Oracle数据库安装目录下的RDBMS下 而在实际工作中 数据库管理员往往会改变其存储位置 如出于空间的考虑或者安全方面的考虑 会把归档日志存放在数据文件不同的硬盘中 等等

如果需要更改归档日志的 *** 作文件 则需要变更相应的初始化参数 参数Log Archive Dest就是用来控制归档日志的存储路径的 通常情况下 若是没有备用数据库的话 则只需要把归档日志存放到服务器上的独立的硬盘中即可 而不需要进行异地备份 如果需要配置本地归档日志的存储路径 则可以通过以上的初始化参数以及Log Archive Duples_Dest参数 其中前面一个参数用来指定第一个归档日志的位置 第二个参数用来指定第二个归档日志的位置 当分别对以上两个参数进行配置后 数据库系统在进行日志切换时 后台进程就会生成两份完全相同的归档日志 分别存储在上面两个不同的路径中 这里需要强调的一点是 存放在两个不同路径中的归档日志文件是完全相同的 这主要是出于数据安全的需要 一般情况下 只需要一个归档日志即可 若不放心的话 则可以设置多个归档日志存放位置 不过这些归档日志最好能够存放到不同的磁盘上 否则的话 就没有多少的实际意义

除了以上这个配置参数之外 平时工作中 我们还经常会使用Log Archive Dest_N这个参数 这个参数主要用于指定多个归档位置 通常情况下 可以多大十个归档位置 这个参数跟先前提到的两个参数有比较大的不同 数据库管理员要对此有清晰的认识 只有如此 才能够根据自己的需要 选择合适的初始化参数 他们的差异主要有以下几点

一是不带N的初始化参数(即前面的两个参数)只能够用来配置本地归档位置 而后面谈到的这个参数这可以用来配置本地归档位置与远程归档位置 也就是说 如果数据库管理员要把归档日志文件保存在网络上的其它主机中时 就必须利用后面的参数进行配置 这个区别是几个参数之间最大的差异 不过由于网络传输等方面的限制 笔者并不建议把归档日志保存在其它主机上 而是建议在数据库服务器中增加一块独立的硬盘用来保存归档日志文件即可 因为硬盘之间数据的复制要比网络传输要快的多 这可以避免重做日志归档时对网络资源过多的占用 从而降低网络的性能

二是前面两个参数只能够配置两个不同的归档日志位置;而后面一个参数则可以配置多大十个归档日志文件位置 这是两者数量上的差异 不过没什么作用 对于大部分企业来说 可能两个归档日志文件存放位置已经可以满足他们的需求了 另外一个小的差异就是 后面这个参数不能够跟前面两个参数共存 为此 当使用后者这个参数时 就需要先把前面两个参数禁用掉 因为数据库默认情况下 是启动第一个初始化参数的

三是具体的配置也有所不同 利用后者参数指定归档日志存储位置时 如果配置本地归档位之 则需要指定Location选项;如果是配置远程归档日志位置时 则就需要制定Service选项 这个选项主要用来指定远程数据库的网络服务名 通常情况下 数据库管理员可以同时配置本地归档位置与远程归档位置

lishixinzhi/Article/program/Oracle/201311/18259

1、

切换至oracle用户

2、进入Oracle安装目录下的app文件夹

3、新建目录并创建脚本文件(一定要在oracle用户下 *** 作)

arcclearsh 脚本内容如下

4、给文件分配权限(一定要在oracle用户下 *** 作)

5、给Oracle 用户创建计划任务(一定要在oracle用户下 *** 作)

新增内容

crontab 计划任务时间设置说明

6、重启 crontab 服务

这里是Oracle使用其硬线路的位置 由于转储的数据文件不能恢复到与其他文件一致的位置 所以可能存在中断的数据并且Oracle不允许正常打开数据库

第 步 设置未文档化的实例参数并打开数据库

在初始化参数文件中首先需要将job_queue_processes设置为 然后设置_allow_resetlogs_corruption=TRUE 更改该参数后 切换到保存新控制文件的目录 第一步创建的位置 然后以 SYSDBA连接并运行新的控制文件创建脚本

此时数据库可以打开了

SQL> SELECT COUNT() FROM OE orders;

第 步 执行导出并提取数据

在这一步可以很容易的看到那些表导出了全部的数据

第 步 转储备份的数据库

这一步 以及下面两步可选 这三步结合在一起允许提取更多的数据 这一步从备份的数据库转储可以高效的撤销任何由于使用_allow_resetlogs_corruption参数造成的毁坏 因此 这一步不会恢复任何丢失的数据文件

第 步 使毁坏的数据文件offline

ALTER DATABASE DATAFILE /u /oradata/PRD/ordtab dbf OFFLINE;

这一步得到数据库的完全一致性状态

第 步 执行导出并提取额外的数据

这一步可能能够提取从第四步不能提取的额外数据 如索引中的数据

第 步 转储数据库

这是最后一次转储数据库 这一步正式回滚数据库到使用隐含参数前那一刻 然后将数据库返回到正常状态 如果从第五步转储以来没有更新任何数据 可以跳过这一步

第 步 删除有问题的表空间

首先需要查看是否有完整性约束限制 使用以下查询

SELECT CR constraint_nameFROM dba_constraints CR dba_constraints CP dba_tables TP dba_tables TRWHERE CR r_owner = CP ownerAND CR r_constraint_name = CP constraint_nameAND CR constraint_type = R AND CP constraint_type IN ( P U )AND CP table_name = TP table_nameAND CP owner = TP ownerAND CR table_name = TR table_nameAND CR owner = TR ownerAND TR tablespace_name <> ORDTAB AND TP tablespace_name = ORDTAB ;

如果有约束 可能需要创建重建脚本 如果使用export dump重建数据 约束可以从导出文件转储

DROP TABLESPACE ordtab INCLUDING CONTENTS CASCADE CONSTRAINTS;

第 步 重建表空间

第 步 重建数据

执行导入后 结束

lishixinzhi/Article/program/SQL/201311/16188

环境:

AIX61

Oracle 11g RAC

故障:

数据库频繁出现归档日志空间不够,导致数据库无法登陆的故障。一查发现原因是归档日志切换频繁, *** 作系统空间不够。

确定原因:

[aix01@oracle]/oracle>df -g

Filesystem GB blocks Free %Used Iused %Iused Mounted on

/dev/hd4 050 028 44% 13674 17% /

/dev/hd2 300 067 78% 49208 23% /usr

/dev/hd9var 100 037 63% 9285 10% /var

/dev/hd3 200 103 49% 2407 1% /tmp

/dev/fwdump 100 099 2% 30 1% /var/adm/ras/platform

/dev/hd1 025 018 28% 465 2% /home

/dev/hd11admin 025 025 1% 5 1% /admin

/proc - - - - - /proc

/dev/hd10opt 050 028 44% 10241 14% /opt

/dev/livedump 025 025 1% 12 1% /var/adm/ras/livedump

/dev/oraclelv 3000 1129 63% 161681 6% /oracle

/dev/installlv 1500 338 78% 6478 1% /install

/dev/crslv 1000 335 67% 7807 1% /crs

/dev/wmsapplv 3000 1749 42% 15537 1% /wmprod

/dev/archivelv 2925 2925 1% 4 1% /arch1

/dev/backuplv 40000 10713 74% 306 1% /sysbackup

aix02:arch2 3025 064 99% 3 1% /arch2

可以看到,/arch2里文件系统空间已经达到99%,/arch2是用来存放归档日志的文件系统,进而导致数据库出错。

提出问题:

这下问题来了,/arch2的空间是30G,每天备份脚本都会自动rman备份归档日志,并自动清除归档日志文件,按照正常情况下,数据库不可能一天产生这么大的归档日志量。

如何查询归档日志都是由什么应用产生的,这就是logminer的用途。

使用方法:

-- 1指定要分析的日志文件

exec sysdbms_logmnradd_logfile(logfilename => '/arch2/2_825_733092736dbf',options => dbms_logmnrnew);

-- 2使用本地的在线数据字典分析归档日志

exec sysdbms_logmnrstart_logmnr(options => sysdbms_logmnrdict_from_online_catalog);

-- 3查询分析出来的归档日志内容,例如统计最大修改量的Schema

select seg_owner,count() from v$logmnr_contents group by seg_owner;

-- 4增加别的日志文件

exec sysdbms_logmnradd_logfile(logfilename=>'/arch2/2_825_733092736dbf');

-- 5结束分析归档日志

exec sysdbms_logmnrend_logmnr;

下面是具体的过程:

SQL> exec sysdbms_logmnradd_logfile(logfilename => '/arch2/2_825_733092736dbf',options => dbms_logmnrnew);

PL/SQL procedure successfully completed

SQL> exec sysdbms_logmnrstart_logmnr(options => sysdbms_logmnrdict_from_online_catalog);

PL/SQL procedure successfully completed

SQL> select seg_owner,count() from v$logmnr_contents group by seg_owner;

SEG_OWNER COUNT()

-------------------------------- ----------

2237

SYS 688

TMS 60

SPHSY 70

SINOSYNEW 30

SINOSY 381

WAS 4551934

7 rows selected

SQL> execute dbms_logmnrend_logmnr ;

PL/SQL procedure successfully completed

结论:

从上面查询结果可以看出 *** 作量最大的用户是WAS用户,再具体看下v$logmnr_contents可以发现基本修改的内容是一致的。

与开发人员沟通后,最终确认是一个执行update过程存在问题,where条件未正确定位到记录,每执行一次都会导致大规模的修改数据。

以上就是关于oracle如何将表的历史数据归档全部的内容,包括:oracle如何将表的历史数据归档、oracle数据库归档的必要性以及如何进行归档(oracle归档日志干嘛的)、如何查看数据库是否处于归档模式等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/sjk/9785161.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-02
下一篇 2023-05-02

发表评论

登录后才能评论

评论列表(0条)

保存