[20191128]11GR2 asm例項audit檔案.txt
[20191128]11GR2 asm例項audit檔案.txt
--//例行檢查,我發現asm例項產生大量audit檔案,一直沒有清理.感覺oracle在這方面設計不好.
# cd /u01/app/11.2.0/grid/rdbms/audit
$ ls -ltr | grep "2019-11-28" | awk '{print $6,$7}' | xargs -I{} date -d "{}" "+%Y-%m-%d:%T %s" | awk 'NR==1 {a=$1;b=$2} NR>1 {print $1,"-",a,$2-b;a=$1;b=$2}' | tail
2019-11-28:08:23:19 - 2019-11-28:08:08:18 901
2019-11-28:08:38:20 - 2019-11-28:08:23:19 901
2019-11-28:08:53:20 - 2019-11-28:08:38:20 900
2019-11-28:09:08:21 - 2019-11-28:08:53:20 901
2019-11-28:09:23:22 - 2019-11-28:09:08:21 901
2019-11-28:09:38:23 - 2019-11-28:09:23:22 901
2019-11-28:09:53:24 - 2019-11-28:09:38:23 901
2019-11-28:10:08:25 - 2019-11-28:09:53:24 901
2019-11-28:10:23:26 - 2019-11-28:10:08:25 901
2019-11-28:10:38:27 - 2019-11-28:10:23:26 901
--//很明顯15分鐘產生1個audit檔案.
--//注意我定義ls顯示時間部分與別人的系統不同,我喜歡顯示的格式如下.
$ alias ls
alias ls='ls --color=auto --time-style=+"%Y-%m-%d %H:%M:%S"'
--//如果按照這個規律一天大約1440/15 = 96.不過我也遇到一些奇怪的情況:
--//先清除2016年之前的檔案,不然ls -ltr感覺有點慢.
$ ls -ltr | grep "2017-01" | awk '{print $6}' | sort | uniq -c
99 2017-01-01
98 2017-01-02
65 2017-01-03
59 2017-01-09
98 2017-01-10
99 2017-01-11
98 2017-01-12
165 2017-01-13
99 2017-01-14
96 2017-01-15
110 2017-01-16
100 2017-01-17
112 2017-01-18
108 2017-01-19
83 2017-01-23
96 2017-01-24
96 2017-01-25
96 2017-01-26
96 2017-01-27
96 2017-01-28
96 2017-01-29
96 2017-01-30
96 2017-01-31
--//沒有2017-01-04 到 2017-01-08號的audit.
$ ls -ltr | grep "2017-11" | awk '{print $6}' | sort | uniq -c | head
98 2017-11-01
86 2017-11-02
5 2017-11-03
5 2017-11-04
3 2017-11-05
3 2017-11-06
4 2017-11-07
1 2017-11-08
7 2017-11-09
1 2017-11-10
--//2017.11.03 號減少許多.oracle這個版本產生的檔案是程式號+時間戳的,不可能出現重名情況.
$ ls -ltr | grep "2017-11-03"
-rw-r----- 1 grid oinstall 750 2017-11-03 10:52:09 +ASM1_ora_8436_20171103105209597022143795.aud
-rw-r----- 1 grid oinstall 752 2017-11-03 11:02:10 +ASM1_ora_20672_20171103110210032622143795.aud
-rw-r----- 1 grid oinstall 752 2017-11-03 14:52:18 +ASM1_ora_31213_20171103145218987768143795.aud
-rw-r----- 1 grid oinstall 752 2017-11-03 20:02:32 +ASM1_ora_22418_20171103200232746081143795.aud
-rw-r----- 1 grid oinstall 750 2017-11-03 22:02:37 +ASM1_ora_9347_20171103220237811439143795.aud
..
--//繼續1個月1個月查詢..
$ ls -ltr | grep "2018-05-" | awk '{print $6}' | sort | uniq -c | head -13
1 2018-05-01
2 2018-05-02
3 2018-05-03
3 2018-05-04
4 2018-05-05
1 2018-05-06
2 2018-05-07
1 2018-05-08
6 2018-05-09
53 2018-05-10
97 2018-05-11
97 2018-05-12
96 2018-05-13
--//奇怪到2018-05-10有開始回覆一天96個的情況.不知道什麼原因啟用這樣的操作.
--//觀察另外1個例項:
# ls -ltr | grep "2017-01" | awk '{print $6}' | sort | uniq -c
1 2017-01-01
21 2017-01-03
17 2017-01-09
1 2017-01-11
73 2017-01-13
1 2017-01-14
2 2017-01-15
27 2017-01-16
7 2017-01-19
10 2017-01-23
--//另外的例項依舊沒有2017-01-04 到 2017-01-08號的audit.
# ls -ltr | grep "2017-11" | awk '{print $6}' | sort | uniq -c | head
5 2017-11-01
47 2017-11-02
96 2017-11-03
96 2017-11-04
95 2017-11-05
96 2017-11-06
96 2017-11-07
97 2017-11-08
97 2017-11-09
97 2017-11-10
# ls -ltr | grep "2018-05-" | awk '{print $6}' | sort | uniq -c | head -13
98 2018-05-01
97 2018-05-02
97 2018-05-03
96 2018-05-04
98 2018-05-05
97 2018-05-06
97 2018-05-07
95 2018-05-08
96 2018-05-09
68 2018-05-10
10 2018-05-11
3 2018-05-12
3 2018-05-13
--//噢,跑到另外1個例項做這些操作.
--//像這樣的檔案命名格式不能使用logrotate清理.只能採用原始的方式:
2.建立指令碼如下:
# cat /usr/local/bin/purge_oracle_aud.sh
#! /bin/bash
# purge oracle audit log
echo
echo "start purge oracle audit asm at : " $(/bin/date +'%Y/%m/%d %T')
/usr/bin/find /u01/app/11.2.0/grid/rdbms/audit/ -mtime +90 -name "+ASM1_ora_*.aud" -print -delete
echo "end purge oracle audit asm at : " $(/bin/date +'%Y/%m/%d %T')
echo
--//注意另外例項要修改為-name "+ASM2_ora_*.aud".
# chmod 750 /usr/local/bin/purge_oracle_aud.sh
--//crontab.d目錄建立一個檔案加入如下:
32 6 * * * root /usr/local/bin/purge_oracle_aud.sh >> /var/log/purge_oracle_aud.log 2>&1
--///var/log/purge_oracle_aud.log的清理由logrotate完成.
# cat /etc/logrotate.d/oracle
/var/log/purge_oracle_aud.log
{
size=20M
rotate 5
copytruncate
compress
notifempty
missingok
}
3.我感到奇怪的是管理的exadata的機器竟然僅僅有2014年的audit檔案,以後零星的出現幾個,真不知道問題在哪裡.也不知道為什麼產生
這樣的情況.仔細檢視才明白....
--//exadata asm例項配置引數如下:
SQL> show parameter audit
NAME TYPE VALUE
-------------------- ----------- ------------------------------
audit_file_dest string /u01/app/11.2.0.4/grid/rdbms/audit
audit_sys_operations boolean FALSE
audit_syslog_level string LOCAL0.INFO
--//噢明白了,exadate oracle的實施人員修改引數audit_syslog_level指向了LOCAL0.INFO.不過audit_sys_operations=false
--//而且實施人員並沒有定義在/etc/rsyslog.conf配置引數中,有機會我給自己測試看看.
# grep -i local0 /etc/syslog.conf
# grep -i local0 /etc/rsyslog.conf
--//無顯示.
--//當前有問題的系統如下:
SQL> show parameter audit
NAME TYPE VALUE
-------------------- ----------- ------------------------------
audit_file_dest string /u01/app/11.2.0/grid/rdbms/audit
audit_sys_operations boolean FALSE
audit_syslog_level string
--//這部分內容參考:http://blog.itpub.net/267265/viewspace-2646161/=>[20190530]oracle Audit檔案管理.txt
--//我仔細檢查exadata的alert檔案發現如下:
Fri Oct 10 21:23:09 2014
ALTER SYSTEM SET cluster_interconnects='10.10.10.70:10.10.10.71' SCOPE=SPFILE SID='+ASM1';
ALTER SYSTEM SET cluster_interconnects='10.10.10.72:10.10.10.73' SCOPE=SPFILE SID='+ASM2';
ALTER SYSTEM SET sga_target='2048M' SCOPE=SPFILE SID='*';
ALTER SYSTEM SET pga_aggregate_target='400M' SCOPE=SPFILE SID='*';
ALTER SYSTEM SET memory_target='0' SCOPE=SPFILE SID='*';
ALTER SYSTEM SET processes=1024 SCOPE=SPFILE SID='*';
ALTER SYSTEM SET audit_syslog_level='local0.info' SCOPE=SPFILE SID='*';
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ALTER SYSTEM SET asm_power_limit=1 SCOPE=SPFILE SID='*';
Fri Oct 10 21:23:10 2014
ALTER SYSTEM SET memory_max_target='0' SCOPE=SPFILE SID='*';
ALTER SYSTEM RESET memory_max_target SCOPE=SPFILE SID='*';
Fri Oct 10 21:24:05 2014
--//很明顯實施人員有文件執行上面的步驟,確忘記了修改/etc/rsyslog.conf或者/etc/syslog.conf配置.導致我僅僅看見2014年的audit.
--//在exadata執行以上操作:
# grep "local0" /etc/rsyslog.conf
local0.info /var/log/oracleaudit.log
daemon.* /var/log/messages
# service rsyslog restart
Shutting down system logger: [ OK ]
Starting system logger: [ OK ]
--//在asm例項上登入執行如下:
SYS@+ASM1> select sysdate from dual ;
SYSDATE
---------
28-NOV-19
# cat /var/log/oracleaudit.log
2019-11-28T16:09:29.980476+08:00 dm01dbadm01 Oracle Audit[63191]: LENGTH : '143' ACTION :[7] 'CONNECT' DATABASE USER:[1]
'/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[0] '' STATUS:[1] '0' DBID:[0] ''
--//僅僅看到登入,沒有執行命令的審計.
--//修改/etc/logrotate.d/oracle,追加如下內容,定期清理審計,實際上這個大小足夠保持很久的內容.
/var/log/oracleaudit.log {
size=40M
rotate 4
copytruncate
delaycompress
notifempty
}
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/267265/viewspace-2666054/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- [20191128]oracle Audit檔案管理2.txtOracle
- 11gR2修改Grid軟體ASM例項引數檔案位置ASM
- 使用普通檔案建立ASM例項ASM
- Oracle單例項+ASM新增控制檔案Oracle單例ASM
- 【原創】使用普通檔案建立ASM例項ASM
- asm例項有沒有控制檔案嗎？ASM
- 不用ASMLIB建立11gr2 ASM例項ASM
- Oracle 11gR2 ASM例項記憶體管理OracleASM記憶體
- 如何複製控制檔案在ASM例項儲存ASM
- oracle 11gR2 配置goldengate連線asm例項OracleGoASM
- 驗證11gR2 RAC中ASM例項通過gpnp profile獲得spfile資訊來啟動ASM例項ASM
- oracle 11gR2 asm例項 不能啟動處理方法OracleASM
- ASM例項 10gR2升到11gR2ASM
- [20190530]oracle Audit檔案管理.txtOracle
- ASM之建立ASM例項ASM
- ASM單例項安裝後，需要手動設定ASM的引數檔案ASM單例
- 11gR2啟動ASM例項時遭遇ORA-29701ASM
- Oracle 11g單例項ASM遷移到檔案系統Oracle單例ASM
- 單例項刪除ASM例項單例ASM
- 管理 ASM 例項ASM
- 停止ASM例項ASM
- 【轉】11gR2啟動ASM例項時遭遇ORA-29701ASM
- 刪除ASM例項ASM
- 【例項】增加控制檔案
- ASM之建立ASM例項及ASM資料庫ASM資料庫
- 11gR2啟動ASM例項時遭遇ORA-29701, cssd dismon ohasASMCSS
- 建立ASM例項及ASM資料庫ASM資料庫
- 利用RMAN將資料庫從檔案系統遷移到ASM(單例項)資料庫ASM單例
- 給ASM例項增加diskgroupASM
- asm例項刪除方法ASM
- oracle 收集asm例項資訊OracleASM
- Java 例項 - 檔案寫入Java
- Vue單檔案模板例項Vue
- [20191129]oracle Audit檔案管理3.txtOracle
- 11GR2 Active Duplicate過程(單例項對單例項)單例
- RAC+DG(asm單例項)ASM單例
- Oracle 11.2.0.3 管理ASM例項OracleASM
- 單例項的duplicate(non ASM)單例ASM