如何启动或关闭数据库的归档模式

1.管理员身份连接数据库

C:\Users\Administrator>sqlplus

sys/sys@xxxxx

as

sysdba

2.查看当前归档模式，是归档还是非归档

SQL>

archive

log

list

Database

log

mode

No

Archive

Mode

（此状态为非归档状态）

3.关闭数据库

SQL>

shutdown

immediate

Database

closed.

Database

dismounted.

ORACLE

instance

shut

down.

4.启动数据库到mount状态

SQL>

startup

mount

5.启动归档模式

SQL>

alter

database

archivelog

（此命令为将归档模式启用）

Database

altered.

SQL>

archive

log

list

Database

log

mode

Archive

Mode

（此状态为归档状态）

6.启动数据库

SQL>

alter

database

open

Database

altered.

7.关闭归档模式

SQL>

shutdown

immediate

Database

closed.

Database

dismounted.

ORACLE

instance

shut

down.

SQL>

startup

mount

ORACLE

instance

started.

SQL>

alter

database

noarchivelog

（此命令为将归档模式关闭）

Database

altered.

SQL>

archive

log

list

Database

log

mode

No

Archive

Mode

selectname,log_mode,open_mode from v$database

NAME LOG_MODE OPEN_MODE

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

CKDB ARCHIVELOG READ WRITE

若是归档模式，则LOG_MODE=ARCHIVELOG

若是非归档模式，则LOG_MODE=NOARCHIVELOG

模拟事务，测试是否会归档

[db2inst1@seagull archive]$ ls /db2home/db2inst1/db2inst1/NODE0000/SQL00001/SQLOGDIR/

S0000000.LOG S0000001.LOG S0000002.LOG

[db2inst1@seagull archive]$ db2 "insert into staff select * from staff"

DB20000I The SQL command completed successfully.

...重复执行该语句，直到报SQL0964C错误

[db2inst1@seagull archive]$ db2 "insert into staff select * from staff"

DB21034E The command was processed as an SQL statement because it was not a

valid Command Line Processor command. During SQL processing it returned:

SQL0964C The transaction log for the database is full. SQLSTATE=57011

#活动日志目录里面先前的日志文件不见了，只剩下了first active ->current的log，个数正好小于等于logprimary(3) + logseconday(2)

[db2inst1@seagull archive]$ ls /db2home/db2inst1/db2inst1/NODE0000/SQL00001/SQLOGDIR/

S0000007.LOG S0000008.LOG S0000009.LOG S0000010.LOG S0000011.LOG

[db2inst1@seagull C0000000]$ db2 get db cfg|grep "First active log file"

First active log file = S0000007.LOG

#可以看到归档目录下已经有了归档文件，且活动日志目录里面的文件被归档后就删除了，归档设置成功!

[db2inst1@seagull C0000000]$ ls

S0000000.LOG S0000001.LOG S0000002.LOG S0000003.LOG S0000004.LOG S0000005.LOG S0000006.LOG

此时的LOGRETAIN参数实际还是OFF的，也可以归档，我觉得原因是db2有两种设置归档模式的方法:

1)一种是设置USEREXIT=ON,此时对应的LOGRETAIN必须为ON,归档由USEREXIT指定的用户程序来执行归档

2)另外一种是设置LOGARCHMETH1参数(还有一些相关参数，参考后续介绍)，此参数可取值如下

a.OFF :表示非归档

b.LOGRETAIN:等价于将 LOGRETAIN 配置参数设置为 RECOVERY，如果指定此值，将自动更新LOGRETAIN参数

c.USEREXIT :且等价于将 USEREXIT 配置参数设置为 ON，如果指定此值，将自动更新USEREXIT参数

d.DISK :日志文件将在其中归档,

e.TSM :将日志文件归档在本地 TSM 服务器上

f.VENDOR :指定将使用供应商库来归档日志文件。此值后必须紧跟冒号（:）和库的名称

结论：

1)我的试验里，设置了LOGARCHMETH1=DISK:/xx/xx，就可以归档了，LOGRETAIN=OFF或者RECOVERY无所谓

2)如果执行db2 update db cfg for sample using LOGRETAIN=ON,则相应的LOGARCHMETH1从DISK:/xx/xx自动

变成了LOGRETAIN，而不管其原值是什么，此时不会自动归档，必须设置USEREXIT,或者再更新LOGARCHMETH1参数为DISK:/xx/xx

3)更改db cfg后，一定要connect reset，否则可能不起作用

4)不用模拟事务，可以利用db2 archive log for db sample 命令来强制归档，同样可以看到归档是否生效

---