問題1 ，數據庫恢復報錯 ORA-19504
SYMPTOMS
Restore database to ASM location failing with errors
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to +DATA/< path>/<db file name>
channel ORA_DISK_1: restoring datafile 00002 to +DATA/< path>/<db file name>
channel ORA_DISK_1: restoring datafile 00003 to +DATA/< path>/<db file name>
channel ORA_DISK_1: restoring datafile 00004 to +DATA/< path>/<db file name>
channel ORA_DISK_1: restoring datafile 00005 to +DATA/<db file name>
channel ORA_DISK_1: restoring datafile 00006 to +DATA/<db file name>
channel ORA_DISK_1: restoring datafile 00007 to +DATA/<db file name>
channel ORA_DISK_1: reading from backup piece /<backup piece path>/<backup piece name>
channel ORA_DISK_1: ORA-19870: error while restoring backup piece /<backup piece path>/<backup piece name>
ORA-19504: failed to create file "+DATA/<db file name>"
ORA-17502: ksfdcre:3 Failed to create file +DATA/<db file name>
ORA-15001: diskgroup "DATA" does not exist or is not mounted
ORA-15040: diskgroup is incomplete
SQL> select status from v$instance;
STATUS
------------
STARTED
SQL> select name, state from v$asm_diskgroup;
NAME STATE
------------------------------ -----------
RECO MOUNTED
DATA MOUNTED
CAUSE
New Envirnoment.
SOLUTION
Issue is related to permission issue
The Grid home is owned by oinstall
ls -lrt /<oracle home>/bin/oracle
-rwsr-s--x 1 oracle oinstall 327811823 Oct 2 16:50 /<oracle home>/bin/oracle
The ASMdisks would be owned by grid:asmadmin so if the database needs to access those disks then the oracle binaries have to be oracle:asmadmin.
Change the group to asmadmin :-
chgrp asmadmin /<oracle home>/bin/oracle
ls -lrt /<oracle home>/bin/oracle
問題2， 程序總是循環發起，消耗了大量redo 資源
日志切換快，是應用發起delete操作刪除大量數據，跑批存在問題，delete操作又被回滾
1． 應用跑批發起delete操作
2． 應用跑批存在問題，delete操作被回滾
相關delete操作
4wzufsb9yg7ka
DELETE FROM tabWHERE ClassifyDate='2020/06/29'
以上操作單次刪除的數據量為13255454
BEGIN_INTERVAL_TIME END_INTERVAL_TIME SQL_ID EXECUTIONS ROWS_PROCESSED
-------------------------------------- -------------------------------------- -------------------------- ---------------- --------------------
2020-06-30 05:00:24 2020-06-30 05:15:54 4wzufsb9yg7ka 0 0
2020-06-30 05:15:54 2020-06-30 05:30:21 4wzufsb9yg7ka 1 13255454
2020-06-30 05:30:21 2020-06-30 05:45:55 4wzufsb9yg7ka 1 13255454
我們在5點21分觀察到delete操作，5點24分沒有delete操作的情況下，依然在快速切換日志
獲取5點23分和5點24分的歸檔日志進行分析：
SQL> select OPERATION,count(*) cnt from v$logmnr_contents group by OPERATION order by cnt;
OPERATION CNT
-------------------------------- ----------
UPDATE 81
COMMIT 1183
START 1183
INTERNAL 2944065 <<<<< internal操作為數據庫內部操作
INSERT 2945122 <<<<< 存在大量insert操作
SQL> select TABLE_NAME,ROLLBACK,count(*) cnt from v$logmnr_contents where OPERATION = 'INTERNAL' group by TABLE_NAME,ROLLBACK;
ROLLBACK CNT
---------- ----------
1 2944009 <<<<<< internal 操作為回滾產生
0 56
SQL> select TABLE_NAME,ROLLBACK,count(*) cnt from v$logmnr_contents where OPERATION = 'INSERT' group by TABLE_NAME,ROLLBACK;
TABLE_NAME ROLLBACK CNT
-------------------------------- ---------- ----------
OBJ# 87412 0 9
OBJ# 87417 0 12
OBJ# 87434 0 1
OBJ# 87429 0 1
OBJ# 87498 0 24
OBJ# 87460 0 24
OBJ# 87491 0 12
OBJ# 87415 0 9
OBJ# 87720 1 2944010 <<<<<< 大量的insert為回滾產生，與object 87720有關。object 87720經查詢為user.CLASSIFY_RECORD，為上述delete操作的表
OBJ# 91051 0 981
OBJ# 87449 0 30
OBJ# 87428 0 9
#############問題3. 為何一張19G 表查詢數據很慢，90G 表查詢很快
這個是一種錯覺，19G 是完全查詢完才回表，90G 表是 查詢100條左右記錄就回表數據，實際上要完整查詢90G 的表需要遠遠多的時間。
測試方法：
--只顯示執行計划和統計信息，不顯示sql執行結果。
SQL> set autotrace traceonly;
設置Autotrace的命令。
分別在執行sql前設置set autotrace 的不同參數，得到不同的想觀察的效果
用法: SET AUTOT[RACE] {OFF | ON | TRACE[ONLY]} [EXP[LAIN]] [STAT[ISTICS]]
--關閉跟蹤執行計划和統計信息功能（默認關閉）。
SQL> set autotrace off;
--執行計划和統計信息都顯示
SQL> set autotrace on ;
--只顯示執行計划和統計信息，不顯示sql執行結果。
SQL> set autotrace traceonly;
--只顯示執行計划
SQL> set autotrace on explain;
--只顯示統計信息
SQL> set autotrace on statistics;
使用autotrace功能時，oracle啟用了兩個session。
一個用來執行SQL。另一個用來記錄執行計划和輸出結果。
來自 “ ITPUB博客 ” ，鏈接：http://blog.itpub.net/25542870/viewspace-2144764/，如需轉載，請注明出處，否則將追究法律責任。
轉載於:http://blog.itpub.net/25542870/viewspace-2144764/