在Oracle數(shù)據(jù)庫(kù)集群中筐摘，有3個(gè)資源對(duì)于維持?jǐn)?shù)據(jù)庫(kù)服務(wù)有著至關(guān)重要的作用，分別是網(wǎng)絡(luò)資源(監(jiān)聽資源)船老、ASM磁盤組資源咖熟、數(shù)據(jù)庫(kù)服務(wù)資源。往往其中任何一個(gè)資源故障后柳畔，都會(huì)影響對(duì)應(yīng)節(jié)點(diǎn)的實(shí)例上數(shù)據(jù)庫(kù)對(duì)外提供服務(wù)馍管。
昨天早上到公司不久，發(fā)現(xiàn)日常使用的一套數(shù)據(jù)庫(kù)上的所有節(jié)點(diǎn)上的系統(tǒng)負(fù)載降到5.0以下了(前一段時(shí)間使用swingbench壓力測(cè)試工具對(duì)數(shù)據(jù)庫(kù)進(jìn)行壓測(cè))薪韩，壓測(cè)期間系統(tǒng)負(fù)載基本維持在100左右确沸，差不多消耗掉了CPU所有的性能。
但是早上看到的情況完全不一樣俘陷，系統(tǒng)負(fù)載降到不到5.0罗捎，CPU使用率也不到10%，然后登錄到swingbench工具的窗口拉盾，看到了非常奇怪的一幕桨菜，swingbench工具并沒有出現(xiàn)hung死的現(xiàn)象，但是swingbench中反應(yīng)業(yè)務(wù) TPS 和 TPM 的曲線統(tǒng)統(tǒng)沒有數(shù)據(jù)捉偏，反應(yīng)數(shù)據(jù)庫(kù)延遲的Response相應(yīng)時(shí)間的曲線變得特別高(響應(yīng)時(shí)間大概在13w-15w的樣子)倒得。
隨后登錄了數(shù)據(jù)庫(kù)實(shí)例所在的節(jié)點(diǎn)，查看了數(shù)據(jù)庫(kù)的狀態(tài)和ASM磁盤組的狀態(tài)夭禽，數(shù)據(jù)庫(kù)實(shí)例和ASM實(shí)例的狀態(tài)都是正常的霞掺，而且ASM實(shí)例沒有發(fā)生掉盤事件。隨后對(duì)事件進(jìn)行了分析讹躯，以下是分析過程：
操作系統(tǒng)層面
一般應(yīng)用程序出現(xiàn)問題后菩彬，或多或少和離不開操作系統(tǒng)的關(guān)系缠劝。因此，我也是首先查看了操作系統(tǒng)有沒有發(fā)生過重啟挤巡，通過 uptime 查看到數(shù)據(jù)庫(kù)實(shí)例所在的節(jié)點(diǎn)已經(jīng)運(yùn)行了好幾天剩彬，顯然，并不是因?yàn)椴僮飨到y(tǒng)重啟導(dǎo)致的矿卑；
# uptime
09:44:10 up 3 days, 49 min, 1 user, load average: 0.570, 0.510, 1.29
緊接著查看了內(nèi)存使用情況喉恋，早上查看到的內(nèi)存因?yàn)閿?shù)據(jù)庫(kù)已經(jīng)沒有壓力，內(nèi)存也釋放了一部分母廷，從目前的使用率來講看不出來什么轻黑；但是考慮到應(yīng)用程序在服務(wù)過程匯總可能會(huì)發(fā)生內(nèi)存泄漏的問題，我有查看了系統(tǒng)是否發(fā)生過crash(一般應(yīng)用程序占據(jù)大量?jī)?nèi)存時(shí),操作系統(tǒng)內(nèi)存不夠用的情況下會(huì)觸發(fā)操作系統(tǒng)crash來強(qiáng)制中斷消耗內(nèi)存的進(jìn)程)琴昆，通過 ls /var/crash/ 查看是否存在前天晚上的crash日志氓鄙，然而也沒有crash日志，說明內(nèi)存是可用的业舍，并不是因?yàn)閮?nèi)存引起的數(shù)據(jù)庫(kù)延遲響應(yīng)高
# free -lh
total used free shared buff/cache available
Mem: 124G 76G 32G 7.2G 16G 35G
Low: 124G 96G 28G
High: 0B 0B 0B
Swap: 15G 0B 15G
# ls /var/crash/
隨后查看了系統(tǒng)空間使用率抖拦，安裝Orale數(shù)據(jù)庫(kù)軟件的目錄空間也是正常的
# df -lh
Filesystem Size Used Avail Use% Mounted on
...
/dev/rhel/rhel-opt 100G 78G 23G 78% /opt
...
數(shù)據(jù)庫(kù)層面
操作系統(tǒng)上檢查了CPU、內(nèi)存舷暮、目錄空間外态罪，并沒有發(fā)現(xiàn)有什么異常。既然操作系統(tǒng)上沒有出現(xiàn)故障下面，那么數(shù)據(jù)庫(kù)響應(yīng)延遲的問題很可能出現(xiàn)在數(shù)據(jù)庫(kù)上了复颈。以下是數(shù)據(jù)庫(kù)上的分析過程。
首先還是查看數(shù)據(jù)庫(kù)狀態(tài)和ASM磁盤組資源狀態(tài)沥割，看起來沒什么問題
#crsctl stat res -t
...
ora.rac.db
1 ONLINE ONLINE node1 Open
2 ONLINE ONLINE node2 Open
# asmcmd lsdg
State Type Rebal Sector Logical_Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED NORMAL N 512 512 4096 1048576 614400 651 204800 -102074 0 N LOGDG/
MOUNTED NORMAL N 512 512 4096 1048576 31561244 377434 10767954 -5195260 0 N DATADG/
MOUNTED NORMAL N 512 512 4096 4194304 18432 17224 6144 5540 0 Y OCRVOTE/
隨后使用oracle用戶登錄耗啦，查看數(shù)據(jù)庫(kù)下的告警日志(alert.log)，日志中從前天晚上8點(diǎn)48左右開始出現(xiàn)報(bào)錯(cuò)机杜，大致意思是LOGDG對(duì)應(yīng)的磁盤組沒有剩余可用空間了帜讲，空間耗盡了。
2022-03-10T20:37:59.178535+08:00
Thread 1 advanced to log sequence 4315 (LGWR switch), current SCN: 27195258674
Current log# 10 seq# 4315 mem# 0: +LOGDG/RAC/ONLINELOG/group_10.265.1095247821
2022-03-10T20:40:00.952685+08:00
ARC3 (PID:2830): Archived Log entry 21 added for T-1.S-4314 ID 0x9fed2859 LAD:1
2022-03-10T20:48:24.680608+08:00
Thread 1 advanced to log sequence 4316 (LGWR switch), current SCN: 27204160847
Current log# 11 seq# 4316 mem# 0: +LOGDG/RAC/ONLINELOG/group_11.266.1095247855
2022-03-10T20:48:25.734541+08:00
ARC0 (PID:2822): Unable to create archive log file '+LOGDG'
2022-03-10T20:48:25.759606+08:00
Errors in file /opt/oracle/diag/rdbms/rac/rac1/trace/rac1_arc0_2822.trc:
ORA-19504: failed to create file "+LOGDG"
ORA-17502: ksfdcre:4 Failed to create file +LOGDG
ORA-15041: diskgroup "LOGDG" space exhausted
ARC0 (PID:2822): Error 19504 Creating archive log file to '+LOGDG'
ARC0 (PID:2822): Stuck archiver: insufficient local LADs
ARC0 (PID:2822): Stuck archiver condition declared
2022-03-10T20:48:25.905755+08:00
Errors in file /opt/oracle/diag/rdbms/rac/rac1/trace/rac1_arc0_2822.trc:
ORA-16038: log 10 sequence# 4315 cannot be archived
ORA-19504: failed to create file ""
ORA-00312: online log 10 thread 1: '+LOGDG/RAC/ONLINELOG/group_10.265.1095247821'
ARC0 (PID:2822): Archival error occurred on a closed thread, archiver continuing
2022-03-10T20:48:25.905894+08:00
ORACLE Instance rac1, archival error, archiver continuing
并且在數(shù)據(jù)庫(kù)的alert告警日志中看到了一些 Unable to create archive log file 的打印椒拗，這里就有點(diǎn)奇怪了舒帮，這套數(shù)據(jù)庫(kù)之前使用的過程中并沒有開啟過歸檔，而日志中的打印確實(shí)是創(chuàng)建歸檔文件失敗陡叠。
盡管如此，我還是先看了ASM磁盤組的狀態(tài)肢执。再次看ASM磁盤組時(shí)枉阵，果然發(fā)現(xiàn)了一些問題，LOGDG對(duì)應(yīng)的磁盤組可用空間(Usable_file_MB)變成負(fù)的了
# asmcmd lsdg
State Type Rebal Sector Logical_Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED NORMAL N 512 512 4096 1048576 614400 651 204800 -102074 0 N LOGDG/
MOUNTED NORMAL N 512 512 4096 1048576 31561244 377434 10767954 -5195260 0 N DATADG/
MOUNTED NORMAL N 512 512 4096 4194304 18432 17224 6144 5540 0 Y OCRVOTE/
這個(gè)時(shí)候我并不清楚LOGDG對(duì)應(yīng)的ASM磁盤組空間為什么會(huì)變成負(fù)的预茄，重新以oracle用戶登錄進(jìn)入數(shù)據(jù)庫(kù)中兴溜，查看redo日志組的使用情況侦厚，大部分的redo日志組處于非活躍狀態(tài)(INACTIVE)，以為是因?yàn)閞edo日志暴增導(dǎo)致的磁盤組空間溢出拙徽，因此準(zhǔn)備刪除幾組redo日志刨沦。根據(jù)正常情況下，Oracle數(shù)據(jù)庫(kù)中的INACTIVE狀態(tài)的redo log日志文件是可以被刪除的膘怕，但是這次刪除的時(shí)候想诅，卻報(bào)錯(cuò)了。
> set linesize 2000
> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES BLOCKSIZE MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME NEXT_CHANGE# NEXT_TIME CON_ID
---------- ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------------- ------------ ------------------- ----------
6 1 4320 1.0737E+10 512 1 NO INACTIVE 2.7240E+10 2022-03-10 21:30:25 2.7249E+10 2022-03-10 21:40:56 0
7 1 4321 1.0737E+10 512 1 NO INACTIVE 2.7249E+10 2022-03-10 21:40:56 2.7258E+10 2022-03-10 21:51:22 0
8 1 4322 1.0737E+10 512 1 NO INACTIVE 2.7258E+10 2022-03-10 21:51:22 2.7267E+10 2022-03-10 22:01:42 0
9 1 4323 1.0737E+10 512 1 NO CURRENT 2.7267E+10 2022-03-10 22:01:42 9.2954E+18 0
10 1 4315 1.0737E+10 512 1 NO INACTIVE 2.7195E+10 2022-03-10 20:37:59 2.7204E+10 2022-03-10 20:48:24 0
11 1 4316 1.0737E+10 512 1 NO INACTIVE 2.7204E+10 2022-03-10 20:48:24 2.7213E+10 2022-03-10 20:58:59 0
12 1 4317 1.0737E+10 512 1 NO INACTIVE 2.7213E+10 2022-03-10 20:58:59 2.7222E+10 2022-03-10 21:09:37 0
13 1 4318 1.0737E+10 512 1 NO INACTIVE 2.7222E+10 2022-03-10 21:09:37 2.7231E+10 2022-03-10 21:20:02 0
14 1 4319 1.0737E+10 512 1 NO INACTIVE 2.7231E+10 2022-03-10 21:20:02 2.7240E+10 2022-03-10 21:30:25 0
16 2 4476 1.0737E+10 512 1 NO CURRENT 2.7259E+10 2022-03-10 21:52:04 9.2954E+18 0
17 2 4468 1.0737E+10 512 1 NO INACTIVE 2.7187E+10 2022-03-10 20:27:59 2.7196E+10 2022-03-10 20:38:25 0
18 2 4469 1.0737E+10 512 1 NO INACTIVE 2.7196E+10 2022-03-10 20:38:25 2.7205E+10 2022-03-10 20:49:06 0
19 2 4470 1.0737E+10 512 1 NO INACTIVE 2.7205E+10 2022-03-10 20:49:06 2.7214E+10 2022-03-10 20:59:56 0
20 2 4471 1.0737E+10 512 1 NO INACTIVE 2.7214E+10 2022-03-10 20:59:56 2.7223E+10 2022-03-10 21:10:21 0
21 2 4472 1.0737E+10 512 1 NO INACTIVE 2.7223E+10 2022-03-10 21:10:21 2.7232E+10 2022-03-10 21:20:47 0
22 2 4473 1.0737E+10 512 1 NO INACTIVE 2.7232E+10 2022-03-10 21:20:47 2.7241E+10 2022-03-10 21:31:12 0
23 2 4474 1.0737E+10 512 1 NO INACTIVE 2.7241E+10 2022-03-10 21:31:12 2.7250E+10 2022-03-10 21:41:35 0
24 2 4475 1.0737E+10 512 1 NO INACTIVE 2.7250E+10 2022-03-10 21:41:35 2.7259E+10 2022-03-10 21:52:04 0
根據(jù)刪除時(shí)候提示的報(bào)錯(cuò)岛心，redo日志需要?dú)w檔才能刪除来破。也就是說，雖然現(xiàn)在數(shù)據(jù)庫(kù)中的redo log日志文件已經(jīng)處于INACTIVE狀態(tài)忘古，但是并沒有經(jīng)過歸檔徘禁，此時(shí)日志文件是無法刪除的。
> alter database drop logfile group 6;
alter database drop logfile group 6
*
ERROR at line 1:
ORA-00350: log 6 of instance rac1 (thread 1) needs to be archived
ORA-00312: online log 6 thread 1: '+LOGDG/RAC/ONLINELOG/group_6.261.1095247683'
> alter database drop logfile group 24;
alter database drop logfile group 24
*
ERROR at line 1:
ORA-00350: log 24 of instance rac2 (thread 2) needs to be archived
ORA-00312: online log 24 thread 2: '+LOGDG/RAC/ONLINELOG/group_24.279.1095248311'
果然髓堪，和數(shù)據(jù)庫(kù)告警日志中的報(bào)錯(cuò)重合了送朱，是因?yàn)閿?shù)據(jù)庫(kù)歸檔出的問題(這個(gè)時(shí)候才反應(yīng)過來，一方面是因?yàn)闅w檔不是我開的干旁，所以沒往那想)驶沼。在數(shù)據(jù)庫(kù)中查看歸檔的配置，沒有問題疤孕，數(shù)據(jù)庫(kù)確實(shí)開了歸檔(log_archive_dest_1)商乎，而且保存歸檔的路徑正好是LOGDG。
LOGDG磁盤組是為了存放redo日志創(chuàng)建的一個(gè)磁盤組祭阀，本身的容量并不是很大鹉戚，加上之前redo文件已經(jīng)消耗了一部分空間，剩余的可用空間本來也不多专控，這下開了數(shù)據(jù)庫(kù)歸檔抹凳，更是雪上加霜了，直接導(dǎo)致磁盤組空間溢出了伦腐。
這里也能解釋為什么數(shù)據(jù)庫(kù)狀態(tài)正常的情況下赢底，數(shù)據(jù)庫(kù)的延遲響應(yīng)會(huì)特別高。存放redo日志的磁盤組本身空間已經(jīng)溢出柏蘑，導(dǎo)致新產(chǎn)生的數(shù)據(jù)庫(kù)事務(wù)對(duì)應(yīng)的redo日志無法寫入到對(duì)應(yīng)的磁盤組中(磁盤組空間炸了)幸冻，而根據(jù)Oracle的redo機(jī)制(日志先行)寫不下去日志的情況下，應(yīng)該是觸發(fā)了數(shù)據(jù)庫(kù)自身的保護(hù)機(jī)制咳焚，將業(yè)務(wù)hung住洽损，提高數(shù)據(jù)庫(kù)的響應(yīng)時(shí)間來保證事務(wù)所產(chǎn)生的日志能夠被記錄上。猜想是寫不下去日志就不讓新事務(wù)產(chǎn)生
09:58:17 sys@ rac1>show parameter log_archive
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_config string
log_archive_dest string
log_archive_dest_1 string location=+LOGDG
log_archive_dest_2 string
log_archive_dest_3 string
...
log_archive_dest_state_1 string enable
log_archive_dest_state_2 string enable
log_archive_dest_state_3 string enable
查看數(shù)據(jù)庫(kù)redo日志的歸檔情況革半，發(fā)現(xiàn)只有兩組日志是歸檔的碑定，其他的redo日志組都是沒有歸檔過的
> select * from v$archive;
GROUP# THREAD# SEQUENCE# ISC CUR FIRST_CHANGE# CON_ID
---------- ---------- ---------- --- --- ------------- ----------
6 1 4320 NO NO 2.7240E+10 0
7 1 4321 NO NO 2.7249E+10 0
8 1 4322 NO NO 2.7258E+10 0
9 1 4323 YES YES 2.7267E+10 0
10 1 4315 NO NO 2.7195E+10 0
11 1 4316 NO NO 2.7204E+10 0
12 1 4317 NO NO 2.7213E+10 0
13 1 4318 NO NO 2.7222E+10 0
14 1 4319 NO NO 2.7231E+10 0
16 2 4476 YES YES 2.7259E+10 0
17 2 4468 NO NO 2.7187E+10 0
18 2 4469 NO NO 2.7196E+10 0
19 2 4470 NO NO 2.7205E+10 0
20 2 4471 NO NO 2.7214E+10 0
21 2 4472 NO NO 2.7223E+10 0
22 2 4473 NO NO 2.7232E+10 0
23 2 4474 NO NO 2.7241E+10 0
24 2 4475 NO NO 2.7250E+10 0
顯然流码，問題原因已經(jīng)找到了。剩下的就是數(shù)據(jù)庫(kù)的恢復(fù)工作了延刘。
數(shù)據(jù)庫(kù)恢復(fù)
既然是因?yàn)闅w檔日志導(dǎo)致的空間溢出漫试，那么首要的就是刪除歸檔文件，關(guān)閉歸檔碘赖，兩者沒有先后之分驾荣。
進(jìn)入ASM磁盤組中，GI中提供了asmcmd命令行工具對(duì)asm磁盤組進(jìn)行管理崖疤，找到ARCHIVELOG目錄秘车，刪除其下的歸檔日志文件，釋放磁盤組空間
# asmcmd
ASMCMD> ls
LOGDG/
DATADG/
OCRVOTE/
ASMCMD> cd LOGDG/
ASMCMD> ls
ASM/
RAC/
ASMCMD> cd RAC/
ASMCMD> ls
ARCHIVELOG/
ONLINELOG/
redo01.log
redo02.log
redo03.log
redo04.log
ASMCMD> cd ARCHIVELOG/
ASMCMD> ls
2022_03_09/
2022_03_10/
ASMCMD> cd 2022_03_09/
ASMCMD> ls
thread_1_seq_4224.260.1098891701
thread_1_seq_4225.280.1098893501
thread_1_seq_4235.283.1098897523
thread_1_seq_4237.285.1098898563
thread_2_seq_4379.270.1098891701
thread_2_seq_4380.281.1098893501
thread_2_seq_4387.282.1098897519
thread_2_seq_4390.284.1098898561
ASMCMD> rm thread_1_seq_4224.260.1098891701
ASMCMD> rm thread_1_seq_4225.280.1098893501
ASMCMD> rm thread_1_seq_4235.283.1098897523
ASMCMD> rm thread_1_seq_4237.285.1098898563
ASMCMD> rm thread_2_seq_4379.270.1098891701
ASMCMD> rm thread_2_seq_4380.281.1098893501
ASMCMD> rm thread_2_seq_4387.282.1098897519
ASMCMD> rm thread_2_seq_4390.284.1098898561
ASMCMD> ls
ASMCMD-8002: entry '2022_03_09' does not exist in directory '+LOGDG/RAC/ARCHIVELOG/'
ASMCMD> cd ..
ASMCMD> ls
2022_03_10/
ASMCMD> cd 2022_03_10/
ASMCMD> ls
thread_1_seq_4308.286.1098992135
thread_1_seq_4309.288.1098992773
thread_1_seq_4310.290.1098993385
thread_1_seq_4311.292.1098993999
thread_1_seq_4312.294.1098994625
thread_1_seq_4313.296.1098995251
thread_1_seq_4314.298.1098995879
thread_2_seq_4462.287.1098992135
thread_2_seq_4463.289.1098992777
thread_2_seq_4464.291.1098993405
thread_2_seq_4465.293.1098994031
thread_2_seq_4466.295.1098994657
thread_2_seq_4467.297.1098995279
ASMCMD> ls -lh
Type Redund Striped Time Sys Name
ARCHIVELOG MIRROR COARSE MAR 10 19:00:00 Y thread_1_seq_4308.286.1098992135
ARCHIVELOG MIRROR COARSE MAR 10 19:00:00 Y thread_1_seq_4309.288.1098992773
ARCHIVELOG MIRROR COARSE MAR 10 19:00:00 Y thread_1_seq_4310.290.1098993385
ARCHIVELOG MIRROR COARSE MAR 10 20:00:00 Y thread_1_seq_4311.292.1098993999
ARCHIVELOG MIRROR COARSE MAR 10 20:00:00 Y thread_1_seq_4312.294.1098994625
ARCHIVELOG MIRROR COARSE MAR 10 20:00:00 Y thread_1_seq_4313.296.1098995251
ARCHIVELOG MIRROR COARSE MAR 10 20:00:00 Y thread_1_seq_4314.298.1098995879
ARCHIVELOG MIRROR COARSE MAR 10 19:00:00 Y thread_2_seq_4462.287.1098992135
ARCHIVELOG MIRROR COARSE MAR 10 19:00:00 Y thread_2_seq_4463.289.1098992777
ARCHIVELOG MIRROR COARSE MAR 10 19:00:00 Y thread_2_seq_4464.291.1098993405
ARCHIVELOG MIRROR COARSE MAR 10 20:00:00 Y thread_2_seq_4465.293.1098994031
ARCHIVELOG MIRROR COARSE MAR 10 20:00:00 Y thread_2_seq_4466.295.1098994657
ARCHIVELOG MIRROR COARSE MAR 10 20:00:00 Y thread_2_seq_4467.297.1098995279
ASMCMD> rm thread_1_seq_4308.286.1098992135
ASMCMD> rm thread_1_seq_4309.288.1098992773
ASMCMD> rm thread_1_seq_4310.290.1098993385
ASMCMD> rm thread_1_seq_4311.292.1098993999
ASMCMD> rm thread_1_seq_4313.296.1098995251
ASMCMD> rm thread_1_seq_4312.294.1098994625
ASMCMD> rm thread_1_seq_4314.298.1098995879
ASMCMD> rm thread_2_seq_4463.289.1098992777
ASMCMD> rm thread_2_seq_4464.291.1098993405
ASMCMD> rm thread_2_seq_4465.293.1098994031
ASMCMD> rm thread_2_seq_4466.295.1098994657
ASMCMD> rm thread_2_seq_4467.297.1098995279
ASMCMD> rm thread_2_seq_4462.287.1098992135
ASMCMD> exit
# asmcmd lsdg
State Type Rebal Sector Logical_Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED NORMAL N 512 512 4096 1048576 614400 206870 204800 1035 0 N LOGDG/
MOUNTED NORMAL N 512 512 4096 1048576 31561244 377434 10767954 -5195260 0 N DATADG/
MOUNTED NORMAL N 512 512 4096 4194304 18432 17224 6144 5540 0 Y OCRVOTE/
刪除掉數(shù)據(jù)庫(kù)的歸檔日志后劫哼，再次查看磁盤組叮趴，可以看到LOGDG對(duì)應(yīng)的磁盤組可用空間被釋放出來了。接著關(guān)掉數(shù)據(jù)庫(kù)的歸檔(不關(guān)歸檔估計(jì)撐不過一天磁盤組又滿了)权烧，關(guān)閉數(shù)據(jù)庫(kù)眯亦，將數(shù)據(jù)庫(kù)啟動(dòng)到mount狀態(tài)(所有的數(shù)據(jù)庫(kù)實(shí)例節(jié)點(diǎn))，使用 alter database noarchivelog; 關(guān)閉數(shù)據(jù)庫(kù)歸檔
刪除數(shù)據(jù)庫(kù)歸檔需要在數(shù)據(jù)庫(kù)狀態(tài)為mount狀態(tài)下進(jìn)行般码，open狀態(tài)下的數(shù)據(jù)庫(kù)無法完成歸檔開啟/關(guān)閉操作
> archive log list ;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination +LOGDG
Oldest online log sequence 4315
Next log sequence to archive 4315
Current log sequence 4323
> alter database noarchivelog;
alter database noarchivelog
*
ERROR at line 1:
ORA-01126: database must be mounted in this instance and not open in any instance
> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
> startup mount
ORACLE instance started.
Total System Global Area 5.3687E+10 bytes
Fixed Size 37223248 bytes
Variable Size 9126805504 bytes
Database Buffers 4.4426E+10 bytes
Redo Buffers 96993280 bytes
Database mounted.
> alter database noarchivelog;
Database altered.
> archive log list
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination +LOGDG
Oldest online log sequence 4316
Current log sequence 4324
關(guān)閉歸檔后妻率，將數(shù)據(jù)庫(kù)啟動(dòng)到Open狀態(tài)
> alter database open;
Database altered.
至此，數(shù)據(jù)庫(kù)恢復(fù)正常板祝，通過swingbench曲線看到表示數(shù)據(jù)庫(kù)事務(wù)的TPS 和 TPM數(shù)據(jù)曲線恢復(fù)正常宫静。
參考：數(shù)據(jù)庫(kù)關(guān)閉歸檔部分參考 Oracle數(shù)據(jù)庫(kù)開啟與關(guān)閉歸檔模式
