标签:用户登录 active 修改 执行 卸载 fixed 状态 组织 app
Oracle数据库有联机重做日志,这个日志是记录对数据库所做的修改,包括对表作的数据改变,对系统做的改变等。可以使用它,来维护数据的完整性,以及进行数据库的恢复,可以进行日志挖掘。
日志文件分为在线日志文件和归档日志文件两类。归档日志文件是在线日志文件的历史备份。
日志文件的位置:C:\app\QIN\oradata\orcl(此路径为我的电脑的日志文件路径,仅供参考)
LGWR进程把日志缓冲区中的重做条目写到联机日志文件中去,就是写到redo01.log等(select不写日志)
举个例子:
用户修改了记录,然后commit,之后数据库宕机了,所以我们重启数据库,可能会用到redo01.log
数据库启动的时候,有前滚、回滚,可以达到的效果是:只要用户commit的记录,都不会丢失;只要是用户没有commit的记录,都不会被保存。
日志按照组来组织,每一个组里面有多个文件。日志组按照循环方式来工作,所以ORACLE中,至少应该有两个日志组,当一个联机重做日志组被写满的时候,就会发生日志切换,这时联机重做日志组2成为当前使用的日志,当联机重做日志组2写满的时候,又会发生日志切换,去写联机重做日志组1,就这样反复进行。
如果数据库处于非归档模式,联机日志在切换时就会丢弃。而在归档模式下,当发生日志切换的时候,被切换的日志会进行归档。比如,当前在使用联机重做日志1,当1写满的时候,发生日志切换,开始写联机重做日志2,这时联机重做日志1的内容会被拷贝到另外一个指定的目录下。这个目录叫做归档目录,拷贝的文件叫归档重做日志。
数据库使用归档方式运行时才可以进行灾难性恢复。
Oracle 数据库可以运行在两种归档方式:
非归档日志方式可以避免实例故障(例如:计算机死机),但无法避免介质故障(例如:硬盘坏了)。在此方式下,数据库只能实施冷备份
归档日志方式产生归档日志,用户可以使用归档日志完全恢复数据库。
举个例子:
数据库从2019年01月01日开始运行,一直到现在;突然存在这样一个要求,需要将数据库恢复到2019年10月1日这个时点的状态上。如果是归档模式,而且归档日志完整的话,是可以恢复的。
归档日志方式下数据库的工作原理:
上述图中的步骤可以是并行的,也就是说在备份日志文件的时候就已经打开新的日志文件开始写日志。
查看当前数据库的归档方式,以及归档位置
-- 先使用sys用户登录数据库后才能执行
archive log list
将归档模式由非归档修改为归档
SQL> archive log list -- 查看归档方式
数据库日志模式 非存档模式
自动存档 禁用
存档终点 USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列 1029
当前日志序列 1031
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount
ORACLE 例程已经启动。
Total System Global Area 1.3662E+10 bytes
Fixed Size 2188728 bytes
Variable Size 6878661192 bytes
Database Buffers 6744440832 bytes
Redo Buffers 37195776 bytes
数据库装载完毕。
SQL> alter database archivelog;
数据库已更改。
SQL> alter database open;
数据库已更改。
SQL> archive log list; -- 查看归档方式
数据库日志模式 存档模式
自动存档 启用
存档终点 USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列 1029
下一个存档日志序列 1031
当前日志序列 1031
SQL> show parameter db_reco -- 查看日志归档的位置
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string C:\app\QIN\flash_recovery_area
db_recovery_file_dest_size big integer 3912M
接着我们可以到路径 C:\app\QIN\flash_recovery_area下查看
我们执行以下命令,进行日志切换
-- 切换日志,旧的日志归档
alter system switch logfile;
-- 查看归档日志的存放位置
SQL> show parameter log_archive_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest string
log_archive_dest_1 string
log_archive_dest_10 string
log_archive_dest_11 string
log_archive_dest_12 string
log_archive_dest_13 string
log_archive_dest_14 string
log_archive_dest_15 string
log_archive_dest_16 string
log_archive_dest_17 string
log_archive_dest_18 string
...省略.....
-- 修改log_archive_dest_1的存放路径
alter system set log_archive_dest_1=‘location=e:\arch‘;
-- 再次查看,发现参数修改有效
SQL> show parameter log_archive_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest string
log_archive_dest_1 string location=e:\arch
log_archive_dest_10 string
log_archive_dest_11 string
log_archive_dest_12 string
log_archive_dest_13 string
log_archive_dest_14 string
log_archive_dest_15 string
log_archive_dest_16 string
log_archive_dest_17 string
log_archive_dest_18 string
......省略
-- 设置归档状态为不可用
alter system set log_archive_dest_state_1=‘defer‘;
由于联机日志文件的重要性,因此应该以组的方式建立日志文件,数据库中至少要有两个日志文件组,同时每一个日志文件组至少要包含两个日志文件,每一个日志组里的所有的日志成员的内容都完全相同,如果一个日志文件损坏,只有组内的其他日志文件仍然可用,则该组仍然对外提供日志操作,不会宕机。
--查看日志文件组
seelct * from v$log
--查看每个日志文件的情况
select * from v$logfile
-- 给日志组增加日志文件
alter database add logfile member ‘C:\app\QIN\oradata\orcl\redo02a.log‘ to group 2;
-- 添加日志组
alter database add logfile group 4 ‘C:\app\QIN\oradata\orcl\redo04.log‘ size 10m;
不同日志组可以不同大小,但是同一个组内的所有日志文件必须同样大小。
联机日志文件组的四种常见状态:
(1)CURRENT:表示这是当前正在使用的联机日志文件组
(2)ACTIVE:表示这个日志文件组中,所记录的重做记录所对应的内存中的脏数据块还没有被完全写入到数据文件中。
(3)INACTIVE:表示这个日志文件组中,所记录的重做记录所对应的内存中的脏数据块已经被写入到数据文件中。
(4)UNUSED:表示还没有被使用过。
使用alter database clear logfile group <group号>;可以清除联机日志文件组内的所有成员,适用于日志文件组损坏了部分成员的情况,被清除的日志组必须是INACTIVE状态。清除后的日志组的状态变成UNUSED。
标签:用户登录 active 修改 执行 卸载 fixed 状态 组织 app
原文地址:https://www.cnblogs.com/OliverQin/p/12748805.html