「认真就输」的评论

数据库爱好者对《 Oracle DBA必备脚本：傻子都可以一眼就定位SQL慢在什么地方》的评论

数据库爱好者 — Fri, 15 Aug 2025 00:33:46 +0000

厉害厉害

hi 对《案例分享:医院行业数据泵迁移案例》的评论

hi — Mon, 30 Jun 2025 08:54:49 +0000

掐指一算，这个客户在重庆

csdw 对《 ORA-01031通过truss分析》的评论

csdw — Mon, 02 Feb 2015 11:14:11 +0000

是 1031

csdw 对《一次RMAN还原慢的分析》的评论

csdw — Wed, 24 Sep 2014 12:19:40 +0000

哈哈,,黄大师,总结得好

huangtingzhong 对《如何在nbu中配置清洗带》的评论

huangtingzhong — Mon, 04 Aug 2014 08:12:27 +0000

tpclean使用 tpclean，您不仅可以监视介质管理器磁带驱动器的使用情况，还可以将磁带驱动器配置为自动清洗。（此功能不适用于 ACS 或 TLH 机械手中的驱动器，也不适用于 QIC 驱动器。）-C drive_name启动机械手中某个驱动器的清洗。必须在机械手中定义了该驱动器，并且在介质管理器卷配置中定义了清洗磁带。装入时间被重置为零。驱动器名称是在配置中添加该驱动器时为其指定的名称。[root@nbu71 bin]# tpclean -C IBM.ULT3580-TD4.000-L输出清洗统计数据。（在 UNIX 和 Linux 系统上，它输出到 stdout。）[root@nbu71 bin]# tpclean -LDrive Name Type Mount Time Frequency Last Cleaned Comment********** **** ********** ********* **************** *******IBM.ULT3580-TD4.000 hcart 0.0 0 N/A IBM.ULT3580-TD4.001 hcart 0.0 0 N/A IBM.ULT3580-TD4.002 hcart* 0.0 0 N/A IBM.ULT3580-TD4.003 hcart 0.0 0 N/A IBM.ULT3580-TD4.004 hcart 0.0 0 N/A IBM.ULT3580-TD4.005 hcart* 0.0 1000 16:05 10/13/2012IBM.ULT3580-TD5.000 hcart2* 0.0 0 N/A IBM.ULT3580-TD5.001 hcart2* 0.0 0 N/A -priority number为作业指定 tpclean 在获取资源的介质-驱动器对时的新优先级。新优先级将覆盖默认的作业优先级。-M drive_name指示已手动清洗了驱动器。装入时间被重置为零。驱动器名称是在设备配置中添加驱动器时为其指定的名称。[root@nbu71 bin]# tpclean -M IBM.ULT3580-TD4.000-F drive_name cleaning_frequency将指定驱动器的清洗频率设置为 cleaning_frequency 小时。驱动器名称是在添加驱动器时为其指定的名称。cleaning_frequency 的值必须介于零 (0) 小时和10,000 小时之间。[root@nbu71 bin]# tpclean -F IBM.ULT3580-TD4.000 100[root@nbu71 bin]# tpclean -LDrive Name Type Mount Time Frequency Last Cleaned Comment********** **** ********** ********* **************** *******IBM.ULT3580-TD4.000 hcart 0.0 100 16:20 10/13/2012

huangtingzhong 对《 SPM中加载提示执行计划》的评论

huangtingzhong — Thu, 26 Jun 2014 02:51:39 +0000

Loading Hinted Execution Plans into SQL Plan Baseline. (Doc ID 787692.1) To BottomTo Bottom Modified:19-Jun-2013Type:HOWTO Rate this document Email link to this document Open document in new window Printable PageIn this DocumentGoalSolutionReferencesAPPLIES TO:Oracle Database – Enterprise Edition – Version 11.1.0.6 to 11.2.0.2 [Release 11.1 to 11.2]Information in this document applies to any platform.Oracle Server Enterprise Edition – Version: 11.1.0.6 to 11.1.0.7GOALThis note will show how to create SQL Plan Baseline for- SQL coming from an application where the SQL can’t be modified- SQL need hints to run a good execution planPlease note that PLAN_HASH_VALUE is different than HASH_VALUE for the SQLIn the following section , PLAN_HASH_VALUE is only used and not HASH_VALUESOLUTION1- Capture sql plan baseline for the original SQL .var res number ;exec :res := dbms_spm.load_plans_from_cursor_cache(sql_id => ‘&original_sql_id’, plan_hash_value => ‘&original_plan_hash_value’ );2- Execute the hinted SQL.3- Find the SQL_ID and plan_hash_value from V$SQL or directly running this command after the SQL is successfully completed ( keep note of the SQL_ID and plan_hash_value for the hinted SQL , these will be used at step5)select * from table(dbms_xplan.display_cursor);4- Verify original SQL baseline exist . ( keep note of the sql_handle for the original SQL, will be used in step5 )select sql_text, sql_handle, plan_name, enabled, accepted from dba_sql_plan_baselines;5- Associate the hinted execution plan to the original sql_handle.var res numberexec :res := dbms_spm.load_plans_from_cursor_cache( -sql_id => ‘&hinted_SQL_ID’, -plan_hash_value => &hinted_plan_hash_value, -sql_handle => ‘&sql_handle_for_original’);6- Verify the new baseline was added.select sql_text, sql_handle, plan_name, enabled, accepted from dba_sql_plan_baselines;7- If the original plan captured initially is not needed, it can be dropped, or disabled.exec :res :=DBMS_SPM.DROP_SQL_PLAN_BASELINE (‘&original_sql_handle’,’&original_plan_name’);8- Execute the SQL from application and verify that SQL is now using the the SQL Plan baseline, run the SQL against V$SQLselect SQL_PLAN_BASELINE from V$SQL where SQL_ID=’&original_SQL_ID’The hinted Plan that is loaded into the SPM repository is marked as acceptable and enabledand becomes part of sql plan baseline as it is manual load, so make sure to loadwell tuned and plans that has been well verified for performance.A test case is uploaded to this note which is implementing the steps above.Document 215187.1 SQLTXPLAIN offers a script ( ./utl/coe_load_sql_baseline.sql ) to automate the steps, review the script before running itReference:Oracle Database PL/SQL Packages and Types Reference11g Release 1 (11.1)Part Number B28419-03Using DBMS_SPMREFERENCESNOTE:215187.1 – SQLT (SQLTXPLAIN) – Tool that helps to diagnose a SQL statement performing poorly or one that produces wrong resultsNOTE:456518.1 – How to Use SQL Plan Management (SPM) – Example UsageNOTE:92202.1 – How to Specify Hidden Hints (Outlines) on SQL Statements in Oracle 8i

huangtingzhong 对《 ORACLE 分布式事务处理（一般情况）》的评论

huangtingzhong — Thu, 19 Jun 2014 15:46:45 +0000

Manually Resolving In-Doubt Transactions: Different Scenarios (文档 ID 126069.1)修改时间:2014-4-30类型:BULLETINAPPLIES TO:Oracle Database – Enterprise Edition – Version 9.2.0.1 to 12.1.0.1 [Release 9.2 to 12.1]Information in this document applies to any platform.PURPOSEThis note is intended to serve as an additional aid for both Analysts and Customers when studying or being confronted with in-doubt transactions.SCOPEThis note provides examples of failing distributed transactions and how to resolve them manually. Failures at different stages of the two phase-commit are identified and studied, together with guidelines to troubleshoot them.Scripts are included at the bottom to setup the environment that will help simulate failing distributed transactions. Please feel free to adjust them to your personal needs.In reality, you should only need to resolve an in-doubt transaction in the following cases:- the in-doubt transaction has locks on critical data or rollback segments- the cause of the machine, network or software failure cannot be repaired quicklyThe RECO background process (Distributed Recovery process) of an Oracle instance automatically resolves failures involving distributed transactions, when the machine, network, or software problem is resolved. Until RECO can resolve the transaction, the data is locked for both reads and writes. Oracle blocks reads because it cannot determine which version of the data to display for a query.Please note that the information here only relates to Oracle distributed transactions. The transaction is done entirely within Oracle or in other words Oracle coordinates the transaction. There are transaction monitors that can be used to coordinate the transactions,instead of Oracle. One example of those is Tuxedo, where the X/A interface is used. There could be also a situation where a non-Oracle database could be part of a distributed transaction through a means of Transparent Gateway. Both of those are outside the scope of this article.The examples given here are limited to distributed transactions between Two nodes as this is the most common encountered environment.If you are not familiar with the two phase-commit, and handling distributed transactions within Oracle, then you will find useful to consult the additional documentation included at the end of this note. These materials provide background information and terminology related to Oracle Distributed Systems.DETAILSThe Two Phase-CommitThe two phase-commit mechanism is used to ensure data integrity in a distributed transaction. It is automatically used during all distributed transactions and coordinates either commit or roll back of all the changes in the transaction as a single unit.Commit CommentTo intentionally induce a failure during the two-phase commit phases of a distributed transaction, the following is included in the COMMENT parameter (see sample script crash_1.sql, in section 5):COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-n’;where n is one of the following integers:n Effect1 Crash commit point site after collect2 Crash non-commit point site after collect3 Crash before prepare (non-commit point site)4 Crash after prepare (non-commit point site)5 Crash commit point site before commit6 Crash commit point site after commit7 Crash non-commit point site before commit8 Crash non-commit point site after commit9 Crash commit point site before forget10 Crash non-commit point site before forget- Note that you can still examine the DBA_2PC_PENDING and DBA_2PC_NEIGHBORS views on all participating sites. This is established by disabling the distributed recovery process (see sample script crash_1.sql, in section 5) before initiating the failing transaction. More detailed info can be found in the related documentation at the end of this note.- distributed transaction consists of DML on remote tableNOTE:Through in this case transaction will occurr on table/site “dept@v817.be.oracle.com”through means of a local synonym “s_dept” and DML on local table “emp”(see script crash_1.sql, in section 5).Stages towards and during the TWO PHASE COMMITSTAGES PHASE CRASH-TEST-NR’s———— ——– —————(02) -> (06) PREPARE 1, 2, 3, 4(07) -> (13) COMMIT 5, 6, 7, 8, 9(14) -> (16) FORGET 10(01) The global coordinator initiates and commits the distributed transaction.During execution of the SQL statements within the transaction, the definition of the session tree is completed (-> dba_2pc_neighbors).(02) The commit point site is determined (commit_point_strength) and the SCNs (System Change Number) of the communicating nodes are coordinated.The highest SCN at all nodes is determined. This will be the commit SCN at the commit point site later on (-> highest global SCN -> global integrity !!!).(03) The global coordinator asks participating(参于) nodes other than the commit point site to promise to commit or roll back (-> prepare message) the transaction, even if there is a failure. If any node cannot prepare, the transaction is rolled back.(04) Every participating node allocates resources it needs to commit or rollback the transaction if data is changed.It saves redo records corresponding to changes made by the transaction to its online redo log. This makes it possible to recover the database back to the prepare state in case of an instance failure.The node guarantees that locks held for the transaction are able to survive a failure.(05) All participating nodes place a distributed lock on modified tables preventing reads/writes.(06) All participating nodes respond with a prepared message to their global/local coordinator and wait until a commit or rollback request is received from the global/local coordinator.After the nodes are prepared, the distributed transaction is said to be in-doubt.Note that all participating nodes need to be prepared for the two phase commit to continue to the next phase (-> commit phase).(07) The global coordinator instructs the commit point site to commit.(08) The commit point site commits with the highest SCN (see step 02).(09) The commit point site informs(通知) the global coordinator of the commit.(10) The global/local coordinator instructs all the participating nodes to commit.(11) Every node commits the local portion of the distributed transaction and releases locks.(12) Every node records an additional redo entry in the local redo log indicating that the transaction has commited.(13) The participating nodes notify the global coordinator that they have committed.On completion of the commit phase, the data on all nodes of the distributed system is consistent with one another.(14) After receiving notice from the global coordinator that all nodes have committed, the commit point site erases status information about this transaction.(15) The commit point site informs the global coordinator that it has erased the status information.(16) The global coordinator erases its own information about the transaction.II Manually Resolving In-Doubt Transactions: Sample Scenarios1. Setup & Introduction to Scenarios———————————The following describes some constants during this note.V817REP.BE.ORACLE.COM- global coordinator ( = origin of distributed transaction)global coordinator is also local coordinator in the examples below commit_point_strength = 5V817.BE.ORACLE.COM- commit point site ( = highest commit_point_strength value)- commit_point_strength = 10DISTRIBUTED TRANSACTION STARTED/* DML remote -> v817.be.oracle.com */insert into s_dept values ();/* DML local -> v817rep.be.oracle.com */insert into emp values ();All scenarios in this document are based on:- one and the same script differing only in the way the transaction is forced to fail. Comments can be included in the COMMENT parameter of the COMMIT statement.Please refer to the Section 5, Scripts, for a copy of the scripts used in this note.2. Sample Scenarios—————-Refer to the scripts provided in Section 5 to work through the scenarios below.In each of the commit crash tests a failure is provoked and methodical investigation and troubleshoot of the transaction is provided. This will involve looking at the errors, the alert.log files and querying the dictionary to understand and resolve the in-doubt transaction given the information gathered.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~2.1. COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-1’~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Crash commit point site after collect-> after step (06) above2.1.1. Observations – Scenario 1ERROR RECEIVED:ORA-02054: transaction 1.8.238 in-doubtORA-02059: ORA-2PC-CRASH-TEST-1 in commit commentORA-02063: preceding line from V817ALERT FILE V817REP.BE.ORACLE.COM:Tue Dec 12 16:23:25 2000Error 2059 trapped in 2PC on transaction 1.8.238. Cleaning up.Error stack returned to user:ORA-02054: transaction 1.8.238 in-doubtORA-02059: ORA-2PC-CRASH-TEST-1 in commit commentORA-02063: preceding line from V817Tue Dec 12 16:23:25 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.1.8.238is local tran 1.8.238 (hex=01.08.ee)insert pending prepared tran, scn=194671 (hex=0.0002f86f)ALERT FILE V817.BE.ORACLE.COM:Tue Dec 12 16:23:25 2000Error 2059 trapped in 2PC on transaction 2.10.176. Cleaning up.Error stack returned to user:ORA-02059: ORA-2PC-CRASH-TEST-1 in commit commentDBA_2PC_PENDING@v817rep.be.oracle.com:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|——————————|——–|—|———-|——-1.8.238 |V817REP.BE.ORACLE.COM.89f6eafb|prepared|no |BE-ORACLE-|194671|.1.8.238 | | |NTbel449 |DBA_2PC_NEIGHBORS@v817rep.be.oracle.com:LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT————-|——|————————-|—————|—1.8.238 |in | |SCOTT |N1.8.238 |out |V817.BE.ORACLE.COM |SCOTT |CDBA_2PC_PENDING@v817.be.oracle.com:no rows selectedDBA_2PC_NEIGHBORS@v817.be.oracle.com:no rows selected2.1.2. What do we learn from the Output – Scenario 1V817REP.BE.ORACLE.COM:- state -> prepared (-> dba_2pc_pending)The node has prepared and may or may not have acknowledged this to its global/local coordinator with a prepared message. However, no commit request has been received. The node remains prepared, holding any local resource locks necessary for the transaction to commit.- global coordinator (LOCAL_TRAN_ID = LOCAL_TRAN_ID of GLOBAL_TRAN_ID) – V817.BE.ORACLE.COM (DATABASE column of DBA_2PC_NEIGHBORS) points to database link used to access information on a remote server.- V817.BE.ORACLE.COM is the commit point site (IN_OUT=out, INTERFACE=c, DATABASE=v817.be.oracle.com -> dba_2pc_neighbors)V817.BE.ORACLE.COM:- no output from both dba_2pc_pending and dba_2pc_neighbors since ‘nothing’ happened at this end- did never commit because of crash (never got the instruction from the global coordinator) (COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-1’)Remark :Note that at this moment there is a distributed lock on table emp@v817rep.be.oracle.com. A select will result in ORA-1591 : lock held by in-doubt distributed transaction 1.8.238.We will decide to manually resolve the in-doubt transaction because of this lock.2.1.3. Solution – Scenario 1We can force a transaction in either two ways:ROLLBACK FORCE ‘transaction_id’;-OR-COMMIT FORCE ‘transaction_id’,commit#;where transaction_id is either the LOCAL_TRAN_ID or GLOBAL_TRAN_ID column from dba_2pc_pending and commit# is the COMMIT# from the same view.Remark:when specifying a commit# with the COMMIT FORCE, be sure to use the highest for all nodes involved to assure global integrity!Back to our example where a rollback of the local portion of the transaction is needed:rollback force ‘V817REP.BE.ORACLE.COM.89f6eafb.1.8.238’;-OR-rollback force ‘1.8.238’;DBA_2PC_PENDING@v817rep.be.oracle.com after the manual rollback:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|——————————|——–|—|———-|——-1.8.238 |V817REP.BE.ORACLE.COM.89f6eafb|forced |no |BE-ORACLE-|194671|.1.8.238 |rollback| |NTbel449 |To purge the in-doubt transaction entry:execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘1.8.238’);** see NOTE1 at the end of this document if DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY fails with ORA-30019The manual rollback action above can also be found in the alert file of v817rep.be.oracle.com:Tue Dec 12 16:42:13 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.1.8.238is local tran 1.8.238 (hex=01.08.ee)change pending prepared tran, scn=194671 (hex=0.0002f86f)to pending forced rollback tran, scn=194671 (hex=0.0002f86f)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~2.2. COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-2’~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Crash non-commit point site after collect-> after step (05) above2.2.1. Observations – Scenario 2ERROR RECEIVED:ORA-02050: transaction 3.4.270 rolled back, some remote DBs may be in-doubtORA-02059: ORA-2PC-CRASH-TEST-2 in commit commentALERT FILE V817REP.BE.ORACLE.COM:Thu Dec 14 11:50:04 2000Error 2059 trapped in 2PC on transaction 3.4.270. Cleaning up.Error stack returned to user:ORA-02050: transaction 3.4.270 rolled back, some remote DBs may be in-doubtORA-02059: ORA-2PC-CRASH-TEST-2 in commit commentThu Dec 14 11:50:04 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.3.4.270is local tran 3.4.270 (hex=03.04.10e)insert pending collecting tran, scn=196918 (hex=0.00030136)ALERT FILE V817.BE.ORACLE.COM:No entriesDBA_2PC_PENDING@v817rep.be.oracle.com:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|———————-|———-|—|———-|——-3.4.270 |V817REP.BE.ORACLE.COM.|collecting|no |BE-ORACLE-|196918|89f6eafb.3.4.270 | | |NTbel449 |DBA_2PC_NEIGHBORS@v817rep.be.oracle.com:LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT————-|——|————————-|—————|—3.4.270 |in | |SCOTT |N3.4.270 |out |V817.BE.ORACLE.COM |SCOTT |CDBA_2PC_PENDING@v817.be.oracle.com:no rows selectedDBA_2PC_NEIGHBORS@v817.be.oracle.com:no rows selected2.2.2. What do we learn from the output – Scenario 2At V817REP.BE.ORACLE.COM:- collecting (the node is currently collecting information from other nodes)This node (global coordinator) currently is waiting for a prepared message from a non-commit point site (itself , in this case also global coordinator) which crashed (COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-2’)- V817.BE.ORACLE.COM (DATABASE column of DBA_2PC_NEIGHBORS) points to database link used to access information on a remote server.- V817.BE.ORACLE.COM is the commit point site (IN_OUT=out, INTERFACE=c, DATABASE=v817.be.oracle.com)V817.BE.ORACLE.COM:- commit point site (as indicated above)- no output from both dba_2pc_pending and dba_2pc_neighbors since ‘nothing’ happened (commit/rollback) at this endThe error message we received earlier, tells us the local transaction 3.4.270 rolled back. This means the global coordinator aborted the transaction because it never received a prepared state from the crashing non-commit point site.Note that there are no local distributed locks because of this, since this site never entered the prepared state and already rolled back the local portion of the transaction.2.2.3. SOLUTION – Scenario 2A rollback force in this case will not work because this node is still in collecting state. A rollback/commit force will only work for nodes in a prepared state. Note also that the local portion of the transaction was already rolled back.If you try so, you will receive the following error:ORA-02058: no prepared transaction found with ID V817REP.BE.ORACLE.COM.89f6eafb.3.4.270All we can do here is a purge of the in-doubt transaction entry:execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘3.4.270’); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~2.3. COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-3’~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Crash before prepare (non-commit point site) -> after step (03) above2.3.1. Observations – Scenario 3ERROR RECEIVED:ORA-02050: transaction 2.12.254 rolled back, some remote DBs may be in-doubtORA-02059: ORA-2PC-CRASH-TEST-3 in commit commentALERT FILE V817REP.BE.ORACLE.COM:Thu Dec 14 14:34:05 2000Error 2059 trapped in 2PC on transaction 2.12.254. Cleaning up.Thu Dec 14 14:34:05 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.2.12.254is local tran 2.12.254 (hex=02.0c.fe)Thu Dec 14 14:34:05 2000Error stack returned to user:ORA-02050: transaction 2.12.254 rolled back, some remote DBs may be in-doubtORA-02059: ORA-2PC-CRASH-TEST-3 in commit commentinsert pending collecting tran, scn=199054 (hex=0.0003098e)ALERT FILE V817.BE.ORACLE.COM:No entriesDBA_2PC_PENDING@v817rep.be.oracle.com:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|———————-|———-|—|———-|——-2.12.254 |V817REP.BE.ORACLE.COM.|collecting|no |BE-ORACLE-|199054|89f6eafb.2.12.254 | | |NTbel449 |DBA_2PC_NEIGHBORS@v817rep.be.oracle.com:LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT————-|——|————————-|—————|—2.12.254 |in | |SCOTT |N2.12.254 |out |V817.BE.ORACLE.COM |SCOTT |CDBA_2PC_PENDING@v817.be.oracle.com:no rows selectedDBA_2PC_NEIGHBORS@v817.be.oracle.com:no rows selected2.3.2. What do we learn from the output – Scenario 3At V817REP.BE.ORACLE.COM:- collecting (the node is currently collecting information from other nodes) This node (global coordinator) currently is waiting for aprepared message from a non-commit point site (itself, in this case also the global coordinator) which crashed before it could prepare (COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-3’).- V817.BE.ORACLE.COM (DATABASE column of DBA_2PC_NEIGHBORS) points to database link used to access information on a remote server.- V817.BE.ORACLE.COM is the commit point site (IN_OUT=out, INTERFACE=c, DATABASE = v817.be.oracle.com).V817.BE.ORACLE.COM:- commit point site (as indicated above).- no output from both dba_2pc_pending and dba_2pc_neighbors since ‘nothing’ happened at this end.The error message we received earlier, tells us the local transaction 2.12.254 rolled back. This means the global coordinator aborted the transaction because it never received a prepared state from the crashing non-commit point site.Note that there are no local distributed locks because of this, since this site never entered the prepared state.2.3.3. Solution – Scenario 3A rollback force in this case will not work because this node is still in collecting state. If you try so, you will receive the following error:ORA-02058: no prepared transaction found with ID V817REP.BE.ORACLE.COM.89f6eafb.2.12.154All we can do here is a purge of the in-doubt transaction entry:execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘2.12.254’);~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~2.4. COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-4’~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Crash after prepare (non-commit point site)-> after step (05) above2.4.1. Observations – Scenario 4————————-ERROR RECEIVED:ORA-02054: transaction 1.26.248 in-doubtORA-02059: ORA-2PC-CRASH-TEST-4 in commit commentALERT FILE V817REP.BE.ORACLE.COM:Error 2059 trapped in 2PC on transaction 1.26.248. Cleaning up.Thu Dec 14 14:46:39 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.1.26.248is local tran 1.26.248 (hex=01.1a.f8)insert pending prepared tran, scn=199226 (hex=0.00030a3a)Thu Dec 14 14:46:39 2000Error stack returned to user:ORA-02054: transaction 1.26.248 in-doubtORA-02059: ORA-2PC-CRASH-TEST-4 in commit commentALERT FILE V817.BE.ORACLE.COM:No entriesDBA_2PC_PENDING@v817rep.be.oracle.com:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|——————————|——–|—|———-|——-1.26.248 |V817REP.BE.ORACLE.COM.89f6eafb|prepared|no |BE-ORACLE-|199226|.1.26.248 | | |NTbel449|DBA_2PC_NEIGHBORS@v817rep.be.oracle.com:LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT————-|——|————————-|—————|—1.26.248 |in | |SCOTT |N1.26.248 |out |V817.BE.ORACLE.COM |SCOTT |CDBA_2PC_PENDING@v817.be.oracle.com:no rows selectedDBA_2PC_NEIGHBORS@v817.be.oracle.com:no rows selected2.4.2. What do we learn from the output – Scenario 4———————————————At V817REP.BE.ORACLE.COM:- prepared (to commit/rollback the local portion of transaction).The non-commit point site crashed after it actually prepared (COMMITCOMMENT ‘ORA-2PC-CRASH-TEST-4’).- V817.BE.ORACLE.COM (DATABASE column of DBA_2PC_NEIGHBORS) points to database link used to access information on a remote server.- V817.BE.ORACLE.COM is the commit point site (IN_OUT=out, INTERFACE=c,DATABASE=v817.be.oracle.com).V817.BE.ORACLE.COM:- commit point site (as indicated above).- no output from both dba_2pc_pending and dba_2pc_neighbors since ‘nothing’ happened at this end.2.4.3. Solution – Scenario 4———————rollback force ‘V817REP.BE.ORACLE.COM.89f6eafb.1.26.248’;-OR-rollback force ‘1.26.248’;DBA_2PC_PENDING@v817rep.be.oracle.com after the manual rollback:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|——————————|——–|—|———-|——-1.26.248 |V817REP.BE.ORACLE.COM.89f6eafb|forced |no |BE-ORACLE-|199226|.1.26.248 |rollback| |NTbel449 |To purge the in-doubt transaction entry:execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘1.26.248’);The manual rollback action above can also be found in the alert file of v817rep.be.oracle.com:Thu Dec 14 15:06:51 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.1.26.248is local tran 1.26.248 (hex=01.1a.f8)change pending prepared tran, scn=199226 (hex=0.00030a3a)to pending forced rollback tran, scn=199226 (hex=0.00030a3a)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~2.5. COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-5’~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Crash commit point site before commit-> after step (07) above2.5.1. Observations – Scenario 5————————-ERROR RECEIVED:ORA-02054: transaction 3.7.279 in-doubtORA-02059: ORA-2PC-CRASH-TEST-5 in commit commentORA-02063: preceding line from V817ALERT FILE V817REP.BE.ORACLE.COM:Error 2059 trapped in 2PC on transaction 3.7.279. Cleaning up.Error stack returned to user:ORA-02054: transaction 3.7.279 in-doubtORA-02059: ORA-2PC-CRASH-TEST-5 in commit commentORA-02063: preceding line from V817Thu Dec 14 15:14:25 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.3.7.279is local tran 3.7.279 (hex=03.07.117)insert pending prepared tran, scn=199599 (hex=0.00030baf)ALERT FILE V817.BE.ORACLE.COM:Error 2059 trapped in 2PC on transaction 3.16.186. Cleaning up.Error stack returned to user:ORA-02059: ORA-2PC-CRASH-TEST-5 in commit commentDBA_2PC_PENDING@v817rep.be.oracle.com:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|——————————|——–|—|———-|——-3.7.279 |V817REP.BE.ORACLE.COM.89f6eafb|prepared|no |BE-ORACLE-|199599|.3.7.279 | | |NTbel449 |DBA_2PC_NEIGHBORS@v817rep.be.oracle.com:LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT————-|——|————————-|—————|—3.7.279 |in | |SCOTT |N3.7.279 |out |V817.BE.ORACLE.COM |SCOTT |CDBA_2PC_PENDING@v817.be.oracle.com:no rows selectedDBA_2PC_NEIGHBORS@v817.be.oracle.com:no rows selected2.5.2. What do we learn from the output – Scenario 5———————————————At V817REP.BE.ORACLE.COM:- prepared (to commit/rollback the local portion of transaction).The commit point site crashed before it actually committed (COMMITCOMMENT ‘ORA-2PC-CRASH-TEST-5’) although the commit point site did receive the request to commit from the global coordinator.- V817.BE.ORACLE.COM (DATABASE column of DBA_2PC_NEIGHBORS) points to database link used to access information on a remote server.- V817.BE.ORACLE.COM is the commit point site (IN_OUT=out, INTERFACE=c,DATABASE=v817.be.oracle.com).V817.BE.ORACLE.COM:- commit point site (as indicated above).- no output from both dba_2pc_pending and dba_2pc_neighbors since ‘nothing’ happened at this end.2.5.3. Solution – Scenario 5———————rollback force ‘V817REP.BE.ORACLE.COM.89f6eafb.3.7.279’;-OR-rollback force ‘3.7.279’;DBA_2PC_PENDING@v817rep.be.oracle.com after the manual rollback:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|——————————|——–|—|———-|——-3.7.279 |V817REP.BE.ORACLE.COM.89f6eafb|forced |no |BE-ORACLE-|199599|.3.7.279 |rollback| |NTbel449 |To purge the in-doubt transaction entry:execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘3.7.279’);The manual rollback action above can also be found in the alert file ofv817rep.be.oracle.com:Thu Dec 14 15:19:38 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.3.7.279is local tran 3.7.279 (hex=03.07.117)change pending prepared tran, scn=199599 (hex=0.00030baf)to pending forced rollback tran, scn=199599 (hex=0.00030baf)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~2.6. COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-6’~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Crash commit point site after commit-> after step (08) above2.6.1. Observations – Scenario 6————————-ERROR RECEIVED:ORA-02054: transaction 3.38.281 in-doubtORA-02053: transaction 2.39.179 committed, some remote DBs may be in-doubtORA-02059: ORA-2PC-CRASH-TEST-6 in commit commentORA-02063: preceding 2 lines from V817ALERT FILE V817REP.BE.ORACLE.COM:Error 2053 trapped in 2PC on transaction 3.38.281. Cleaning up.Error stack returned to user:ORA-02054: transaction 3.38.281 in-doubtORA-02053: transaction 2.39.179 committed, some remote DBs may be in-doubtORA-02059: ORA-2PC-CRASH-TEST-6 in commit commentORA-02063: preceding 2 lines from V817Thu Dec 14 16:09:16 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.3.38.281is local tran 3.38.281 (hex=03.26.119)insert pending prepared tran, scn=201050 (hex=0.0003115a)ALERT FILE V817.BE.ORACLE.COM:Thu Dec 14 16:09:16 2000Error 2059 trapped in 2PC on transaction 2.39.179. Cleaning up.Error stack returned to user:ORA-02053: transaction 2.39.179 committed, some remote DBs may be in-doubtORA-02059: ORA-2PC-CRASH-TEST-6 in commit commentThu Dec 14 16:09:16 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.3.38.281is local tran 2.39.179 (hex=02.27.b3)insert pending committed tran, scn=201052 (hex=0.0003115c)DBA_2PC_PENDING@v817rep.be.oracle.com:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|——————————|——–|—|———-|——-3.38.281 |V817REP.BE.ORACLE.COM.89f6eafb|prepared|no |BE-ORACLE-|201050|.3.38.281 | | |NTbel449 |DBA_2PC_NEIGHBORS@v817rep.be.oracle.com:LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT————-|——|————————-|—————|—3.38.281 |in | |SCOTT |N3.38.281 |out |V817.BE.ORACLE.COM |SCOTT |CDBA_2PC_PENDING@v817.be.oracle.com:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|——————————|——–|—|———-|——-2.39.179 |V817REP.BE.ORACLE.COM.89f6eafb|committe|no |BE-ORACLE-|201052|.3.38.281 |d | |NTbel449 |DBA_2PC_NEIGHBORS@v817.be.oracle.com:LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT————-|——|————————-|—————|—2.39.179 |in |V817REP.BE.ORACLE.COM |SCOTT |C2.6.2. What do we learn from the Output – Scenario 6———————————————At V817REP.BE.ORACLE.COM:- prepared (to commit/rollback the local portion of transaction).The commit point site crashed after it actually committed(COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-6’). Because of the crash, the commit point site could not inform the global coordinator about this fact.- V817.BE.ORACLE.COM (DATABASE column of DBA_2PC_NEIGHBORS) points to database link used to access information on a remote server.- V817.BE.ORACLE.COM is the commit point site (IN_OUT=out, INTERFACE=c,DATABASE=v817.be.oracle.com)V817.BE.ORACLE.COM:- commit point site (as indicated above).- state ‘committed’. This node already committed the local transaction after which it crashed.- the global coordinator is still waiting for the ‘commit’ response from the commit point site.2.6.3. Solution – Scenario 6———————commit force ‘V817REP.BE.ORACLE.COM.89f6eafb.3.38.281′,’201052’;-OR-commit force ‘3.38.281’,’201052′;Note that we use the commit# of the commit point site(highest global commit#) to assure global integrity!DBA_2PC_PENDING@v817rep.be.oracle.com after the manual commit:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|——————————|——|—|———-|——-3.38.281 |V817REP.BE.ORACLE.COM.89f6eafb|forced|no |BE-ORACLE-|201052|.3.38.281 |commit| |NTbel449 |To purge the in-doubt transaction entry at v817rep.be.oracle.com:execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘3.38.281’);To purge the in-doubt transaction entry at v817.be.oracle.com:execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘2.4.179’);The manual commit action above can also be found in the alert file ofv817rep.be.oracle.com:Thu Dec 14 16:12:35 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.3.38.281is local tran 3.38.281 (hex=03.26.119)change pending prepared tran, scn=201050 (hex=0.0003115a)to pending forced commit tran, scn=201052 (hex=0.0003115c)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~2.7. COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-7’~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Crash non-commit point site before commit-> after step (10) above2.7.1. Observations – Scenario 7————————-ERROR RECEIVED:ORA-02054: transaction 2.9.260 in-doubtORA-02059: ORA-2PC-CRASH-TEST-7 in commit commentALERT FILE V817REP.BE.ORACLE.COM:Thu Dec 14 16:21:34 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.2.9.260is local tran 2.9.260 (hex=02.09.104)insert pending prepared tran, scn=201244 (hex=0.0003121c)Thu Dec 14 16:21:34 2000Error stack returned to user:ORA-02054: transaction 2.9.260 in-doubtORA-02059: ORA-2PC-CRASH-TEST-7 in commit commentALERT FILE V817.BE.ORACLE.COM:Thu Dec 14 16:21:34 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.2.9.260is local tran 1.46.176 (hex=01.2e.b0)insert pending committed tran, scn=201246 (hex=0.0003121e)DBA_2PC_PENDING@v817rep.be.oracle.com:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|——————————|——–|—|———-|——-2.9.260 |V817REP.BE.ORACLE.COM.89f6eafb|prepared|no |BE-ORACLE-|201244|.2.9.260 | | |NTbel449 |DBA_2PC_NEIGHBORS@v817rep.be.oracle.com:LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT————-|——|————————-|—————|—2.9.260 |in | |SCOTT |N2.9.260 |out |V817.BE.ORACLE.COM |SCOTT |CDBA_2PC_PENDING@v817.be.oracle.com:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|———————-|———|—|———-|——-1.46.176 |V817REP.BE.ORACLE.COM.|committed|no |BE-ORACLE-|201246|89f6eafb.2.9.260 | | |NTbel449 |DBA_2PC_NEIGHBORS@v817.be.oracle.com:LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT————-|——|————————-|—————|—1.46.176 |in |V817REP.BE.ORACLE.COM |SCOTT |C2.7.2. What do we learn from the Output – Scenario 7———————————————At V817REP.BE.ORACLE.COM:- prepared (to commit/rollback the local portion of transaction).The non-commit point site crashed before it actually committed(COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-7’) while the commit point site has alreadycommitted.- V817.BE.ORACLE.COM (DATABASE column of DBA_2PC_NEIGHBORS) points to database link used to access information on a remote server.- V817.BE.ORACLE.COM is the commit point site (IN_OUT=out, INTERFACE=c,DATABASE=v817.be.oracle.com).V817.BE.ORACLE.COM:- commit point site (as indicated above)- state ‘committed’. This node already committed the local transaction as asked by the global coordinator.- the global coordinator is waiting for the ‘commit’ response from the non-commit point site.2.7.3. Solution – Scenario 7———————commit force ‘V817REP.BE.ORACLE.COM.89f6eafb.2.9.260′,’201246’;-OR-commit force ‘2.9.260’,’201246′;Note that we use the commit# of the commit point site to assure global integrity!DBA_2PC_PENDING@v817rep.be.oracle.com after the manual commit:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|——————————|——|—|———-|——-2.9.260 |V817REP.BE.ORACLE.COM.89f6eafb|forced|no |BE-ORACLE-|201246|.2.9.260 |commit| |NTbel449 |To purge the in-doubt transaction entry at v817rep.be.oracle.com:execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘2.9.260’);To purge the in-doubt transaction entry at v817.be.oracle.com:execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘1.46.176’);The manual commit action above can also be found in the alert file ofv817rep.be.oracle.com:DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.2.9.260is local tran 2.9.260 (hex=02.09.104)change pending prepared tran, scn=201244 (hex=0.0003121c)to pending forced commit tran, scn=201246 (hex=0.0003121e)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~2.8. COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-8’~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Crash non-commit point site after commit-> after step (12) above2.8.1. Observations – Scenario 8————————-ERROR RECEIVED:ORA-02053: transaction 3.16.283 committed, some remote DBs may be in-doubtORA-02059: ORA-2PC-CRASH-TEST-8 in commit commentALERT FILE V817REP.BE.ORACLE.COM:Thu Dec 14 16:45:52 2000Error 2059 trapped in 2PC on transaction 3.16.283. Cleaning up.Error stack returned to user:ORA-02053: transaction 3.16.283 committed, some remote DBs may be in-doubtORA-02059: ORA-2PC-CRASH-TEST-8 in commit commentThu Dec 14 16:45:52 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.3.16.283is local tran 3.16.283 (hex=03.10.11b)insert pending committed tran, scn=201607 (hex=0.00031387)ALERT FILE V817.BE.ORACLE.COM:Thu Dec 14 16:45:52 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.3.16.283is local tran 2.44.179 (hex=02.2c.b3)insert pending committed tran, scn=201607 (hex=0.00031387)DBA_2PC_PENDING@v817rep.be.oracle.com:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|———————-|———|—|———-|——-3.16.283 |V817REP.BE.ORACLE.COM.|committed|no |BE-ORACLE-|201607|89f6eafb.3.16.283 | | |NTbel449 |DBA_2PC_NEIGHBORS@v817rep.be.oracle.com:LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT————-|——|————————-|—————|—3.16.283 |in | |SCOTT |N3.16.283 |out |V817.BE.ORACLE.COM |SCOTT |CDBA_2PC_PENDING@v817.be.oracle.com:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|———————-|———|—|———-|——-2.44.179 |V817REP.BE.ORACLE.COM.|committed|no |BE-ORACLE-|201607|89f6eafb.3.16.283 | | |NTbel449 |DBA_2PC_NEIGHBORS@v817.be.oracle.com:LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT————-|——|————————-|—————|—2.44.179 |in |V817REP.BE.ORACLE.COM |SCOTT |C2.8.2. What do we learn from the Output – Scenario 8———————————————At V817REP.BE.ORACLE.COM:- commited. This node has completed the transaction(COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-8’). The crash does not allow to confirm this towards the global coordinator.- V817.BE.ORACLE.COM (DATABASE column of DBA_2PC_NEIGHBORS) points to database link used to access information on a remote server.- V817.BE.ORACLE.COM is the commit point site (IN_OUT=out, INTERFACE=c,DATABASE=v817.be.oracle.com).V817.BE.ORACLE.COM:- commit point site (as indicated above)- state ‘committed’. This node already committed the local transaction as asked by the global coordinator.2.8.3. Solution – Scenario 8——————–Since all sites committed the transaction already, it will do by purging the in-doubt transaction entries.To purge the in-doubt transaction entry at v817rep.be.oracle.com:execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘3.16.283’);To purge the in-doubt transaction entry at v817.be.oracle.com:execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘2.44.179’);~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~2.9. COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-9’~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Crash commit point site before forget -> after step (13) above2.9.1. Observations – Scenario 9————————-ERROR RECEIVED:ORA-02053: transaction 3.26.284 committed, some remote DBs may be in-doubtORA-02053: transaction 2.12.180 committed, some remote DBs may be in-doubtORA-02059: ORA-2PC-CRASH-TEST-9 in commit commentORA-02063: preceding 2 lines from V817ALERT FILE V817REP.BE.ORACLE.COM:Error 2053 trapped in 2PC on transaction 3.26.284. Cleaning up.Error stack returned to user:ORA-02053: transaction 3.26.284 committed, some remote DBs may be in-doubtORA-02053: transaction 2.12.180 committed, some remote DBs may be in-doubtORA-02059: ORA-2PC-CRASH-TEST-9 in commit commentORA-02063: preceding 2 lines from V817Fri Dec 15 09:41:56 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.3.26.284is local tran 3.26.284 (hex=03.1a.11c)insert pending committed tran, scn=202022 (hex=0.00031526)ALERT FILE V817.BE.ORACLE.COM:Fri Dec 15 09:41:55 2000Error 2059 trapped in 2PC on transaction 2.12.180. Cleaning up.Error stack returned to user:ORA-02053: transaction 2.12.180 committed, some remote DBs may be in-doubtORA-02059: ORA-2PC-CRASH-TEST-9 in commit commentFri Dec 15 09:41:56 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.3.26.284is local tran 2.12.180 (hex=02.0c.b4)insert pending committed tran, scn=202022 (hex=0.00031526)DBA_2PC_PENDING@v817rep.be.oracle.com:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|———————-|———|—|———-|——-3.26.284 |V817REP.BE.ORACLE.COM.|committed|no |BE-ORACLE-|202022|89f6eafb.3.26.284 | | |NTbel449 |DBA_2PC_NEIGHBORS@v817rep.be.oracle.com:LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT————-|——|————————-|—————|—3.26.284 |in | |SCOTT |N3.26.284 |out |V817.BE.ORACLE.COM |SCOTT |CDBA_2PC_PENDING@v817.be.oracle.com:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|———————-|———|—|———-|——-2.12.180 |V817REP.BE.ORACLE.COM.|committed|no |BE-ORACLE-|202022|89f6eafb.3.26.284 | | |NTbel449 |DBA_2PC_NEIGHBORS@v817.be.oracle.com:LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT————-|——|————————-|—————|—2.12.180 |in |V817REP.BE.ORACLE.COM |SCOTT |C2.9.2. What do we learn from the Output – Scenario 9———————————————At V817REP.BE.ORACLE.COM:- commited. This node has completed the transaction(COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-9’). The global coordinator is aware of this but cannot communicate this towards the commit point site.- V817.BE.ORACLE.COM (DATABASE column of DBA_2PC_NEIGHBORS) points to database link used to access information on a remote server.- V817.BE.ORACLE.COM is the commit point site (IN_OUT=out, INTERFACE=c,DATABASE=v817.be.oracle.com).V817.BE.ORACLE.COM:- commit point site (as indicated above).- state ‘committed’. This node already committed the local transaction as asked by the global coordinator.2.9.3. Solution – Scenario 9———————Since all sites committed the transaction already, it will do by purging the in-doubt transaction entries.To purge the in-doubt transaction entry at v817rep.be.oracle.com:execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘3.26.284’);To purge the in-doubt transaction entry at v817.be.oracle.com:execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘2.12.180’);~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~2.10. COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-10’~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Crash non-commit point site before forget-> after step (14) above2.10.1. Observations – Scenario 10————————–ERROR RECEIVED:ORA-02053: transaction 1.10.255 committed, some remote DBs may be in-doubtORA-02059: ORA-2PC-CRASH-TEST-10 in commit commentALERT FILE V817REP.BE.ORACLE.COM:Fri Dec 15 09:53:33 2000Error 2059 trapped in 2PC on transaction 1.10.255. Cleaning up.Error stack returned to user:ORA-02053: transaction 1.10.255 committed, some remote DBs may be in-doubtORA-02059: ORA-2PC-CRASH-TEST-10 in commit commentFri Dec 15 09:53:33 2000DISTRIB TRAN V817REP.BE.ORACLE.COM.89f6eafb.1.10.255is local tran 1.10.255 (hex=01.0a.ff)insert pending committed tran, scn=202241 (hex=0.00031601)ALERT FILE V817.BE.ORACLE.COM:No entriesDBA_2PC_PENDING@v817rep.be.oracle.com:LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#————-|———————-|———|—|———-|——-1.10.255 |V817REP.BE.ORACLE.COM.|committed|no |BE-ORACLE-|202241|89f6eafb.1.10.255 | | |NTbel449 |DBA_2PC_NEIGHBORS@v817rep.be.oracle.com:LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT————-|——|————————-|—————|—1.10.255 |in | |SCOTT |N1.10.255 |out |V817.BE.ORACLE.COM |SCOTT |CDBA_2PC_PENDING@v817.be.oracle.com:no rows selectedDBA_2PC_NEIGHBORS@v817.be.oracle.com:no rows selected2.10.2. What do we learn from the Output – Scenario 10———————————————-At V817REP.BE.ORACLE.COM:- commited. This node has completed the transaction(COMMIT COMMENT ‘ORA-2PC-CRASH-TEST-10’). The commit point site alreadyforgot about the transaction.- V817.BE.ORACLE.COM (DATABASE column of DBA_2PC_NEIGHBORS) points to database link used to access information on a remote server.- V817.BE.ORACLE.COM is the commit point site (IN_OUT=out, INTERFACE=c,DATABASE=v817.be.oracle.com).V817.BE.ORACLE.COM:- commit point site (as indicated above).- state ‘committed’. This node already committed the local transaction as asked by the global coordinator.2.10.3. Solution – Scenario 10———————-Since all sites committed the transaction already, it will do by Purging the in-doubt transaction entries.To purge the in-doubt transaction entry at v817rep.be.oracle.com:execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘1.10.255’);5. Scripts used in this Note=========================SETUP_REM.SQL – setup remote db users/objects and privilegesSETUP_LOC.SQL – setup local db users/objects and privilegesCRASH_1.SQL – sample crash scenario for CRASHT TEST1COLLECT_INFO.SQL – queries to troubleshoot scenarios–>>>>>>>>>> Begin of setup_rem.sql <<<<<<<<<<–/* Execute at the remote site */connect sys/change_on_install@v817create user scott identified by tigerdefault tablespace userstemporary tablespace temp;grant dba to scott;grant force transaction,force any transaction to scott;/* To be able to crash a distributed transaction withCOMMIT COMMENT ‘ORA-2PC-CRASH-n’; */grant alter system to scott;/* To be able to do ALTER SYSTEM DISABLE/ENABLE DISTRIBUTEDRECOVERY; */grant delete on sys.pending_trans$ to scott;grant delete on sys.pending_sessions$ to scott;grant delete on sys.pending_sub_sessions$ to scott;/* To be able to use DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY */connect scott/tiger@v817create database link v817rep.be.oracle.com connect to scottidentified by tiger using ‘v817rep.be.oracle.com’;SET TERMOUT OFFSET ECHO OFFCREATE TABLE DEPT(DEPTNO NUMBER(2) CONSTRAINT PK_DEPT PRIMARY KEY,DNAME VARCHAR2(14) ,LOC VARCHAR2(13) ) ;CREATE TABLE EMP(EMPNO NUMBER(4) CONSTRAINT PK_EMP PRIMARY KEY,ENAME VARCHAR2(10),DEPTNO NUMBER(2) CONSTRAINT FK_DEPTNO REFERENCES DEPT);INSERT INTO DEPT VALUES (10,’ACCOUNTING’,’NEW YORK’);INSERT INTO DEPT VALUES (20,’RESEARCH’,’DALLAS’);INSERT INTO DEPT VALUES (30,’SALES’,’CHICAGO’);INSERT INTO DEPT VALUES (40,’OPERATIONS’,’BOSTON’);INSERT INTO EMP VALUES (1000,’SMITH’,20);INSERT INTO EMP VALUES (1001,’ALLEN’,30);INSERT INTO EMP VALUES (1002,’WARD’,30);INSERT INTO EMP VALUES (1003,’JONES’,20);COMMIT;CREATE SYNONYM S_DEPT FOR DEPT@v817rep.be.oracle.com;CREATE SYNONYM S_EMP FOR EMP@v817rep.be.oracle.com;SET TERMOUT ONSET ECHO ON–>>>>>>>>>> End of setup_rem.sql <<<<<<<<<<—->>>>>>>>>> Begin of setup_loc.sql <<<<<<<<<<–/* Execute at the local site */connect sys/change_on_install@v817repcreate user scott identified by tigerdefault tablespace userstemporary tablespace temp;grant dba to scott;grant force transaction,force any transaction to scott;/* To be able to crash a distributed transaction with COMMIT COMMENT ‘ORA-2PC-CRASH-n’; */grant alter system to scott;/* To be able to do ALTER SYSTEM DISABLE/ENABLE DISTRIBUTED RECOVERY; */grant delete on sys.pending_trans$ to scott;grant delete on sys.pending_sessions$ to scott;grant delete on sys.pending_sub_sessions$ to scott;/* To be able to use DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY */connect scott/tiger@v817repcreate database link v817.be.oracle.com connect to scottidentified by tiger using ‘v817.be.oracle.com’;SET TERMOUT OFFSET ECHO OFFCREATE TABLE DEPT(DEPTNO NUMBER(2) CONSTRAINT PK_DEPT PRIMARY KEY,DNAME VARCHAR2(14) ,LOC VARCHAR2(13) ) ;CREATE TABLE EMP(EMPNO NUMBER(4) CONSTRAINT PK_EMP PRIMARY KEY,ENAME VARCHAR2(10),DEPTNO NUMBER(2) CONSTRAINT FK_DEPTNO REFERENCES DEPT);INSERT INTO DEPT VALUES (10,’ACCOUNTING’,’NEW YORK’);INSERT INTO DEPT VALUES (20,’RESEARCH’,’DALLAS’);INSERT INTO DEPT VALUES (30,’SALES’,’CHICAGO’);INSERT INTO DEPT VALUES (40,’OPERATIONS’,’BOSTON’);INSERT INTO EMP VALUES (1000,’SMITH’,20);INSERT INTO EMP VALUES (1001,’ALLEN’,30);INSERT INTO EMP VALUES (1002,’WARD’,30);INSERT INTO EMP VALUES (1003,’JONES’,20);COMMIT;CREATE SYNONYM S_DEPT FOR DEPT@v817.be.oracle.com;CREATE SYNONYM S_EMP FOR EMP@v817.be.oracle.com;SET TERMOUT ONSET ECHO ON–>>>>>>>>>> End of setup_loc.sql <<<<<<<<<<—->>>>>>>>>> Begin of crash_1.sql <<<<<<<<<<–/* Crash Scenario 1 *//* Crash commit point site after collect */connect scott/tiger@v817repalter system disable distributed recovery;/* DML remote *//* object s_dept is a synonym for table dept@v817.be.oracle.com */insert into s_dept values (41,’SUPPORT’,’BRUSSELS’);/* DML local */insert into emp values (1041,’MULDER’,10);commit comment ‘ORA-2PC-CRASH-TEST-1’;Related Information===================Oracle8i Documentation – Distributed Database SystemsChapter 4 : Distributed Transactions ConceptsChapter 5 : Managing Distributed TransactionsOracle9i Documentation – Database Administrator’s GuideChapter 31 : Distributed Transactions ConceptsChapter 32 : Managing Distributed TransactionsOracle10g Documentation – Database Administrator’s GuideChapter 32 : Distributed Transactions ConceptsChapter 33 : Managing Distributed TransactionsOracle University Course:Oracle8i Distributed SystemsPart 1 : Distributed Database ImplementationChapter 7 : Monitoring Distributed Transactionsnote:13229.1note:100664.1note:67590.1note:62301.1bug:2191458** NOTE1: If using Oracle 9i or later and DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY fails withORA-30019: Illegal rollback Segment operation in Automatic Undo mode, use thefollowing workaround:In 9i:SQL> alter session set “_smu_debug_mode” = 4;SQL> commit; <– MUST BE ADDED TO PREVENT ORA-1453SQL>execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(‘local_tran_id’); NOTE: From 10g and later, _smu_debug_mode cannot be set at session level, it needs to be set at system level insteaad.Thus in 10g onwards use ALTER SYSTEM for setting _smu_debug_mode and reset this value to its original value afterwards; defaulat value is 0:To reset value to its default, use:SQL> alter system set “_smu_debug_mode” = 0;Still have questions ?To discuss this information further with Oracleexperts and industry peers, we encourage you to review, join or start a discussion via My OracleSupport Streams and Distributed Database CommunityEnjoy a short Video about OracleÃÂ´s Support Communities – to quickly understand itÃÂ´s benefits for you right now (http://bcove.me/tlygjitz)NOTE: Direct or manual DML or dba_2pc* view or sys.pending_* tables is is unsupported and does not resolve any in-doubt transactionREFERENCESNOTE:13229.1 – Distributed Database, Transactions and Two Phase CommitNOTE:62301.1 – ALERT: Distributed Transactions may fail when using COMMIT/ROLLBACK in PLSQLNOTE:100664.1 – Master Note for Troubleshooting Oracle Managed Distributed TransactionsNOTE:67590.1 – PROCEDURE DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY Specification

huangtingzhong 对《 ORA-01210: data file header is media corrupt 》的评论

huangtingzhong — Wed, 11 Jun 2014 13:29:34 +0000

下面是ASM磁盘头的部分ASM DATA DISK1 ASM DATA DISK1 ASM ARCH DISK1kfbh.endian: 1 ; 0x000: 0x01 1 1 ; kfbh.hard: 130 ; 0x001: 0x82 130 130 ; kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD 1 1 ; kfbh.datfmt: 1 ; 0x003: 0x01 1 1 ; kfbh.block.blk: 0 ; 0x004: T=0 NUMB=0x0 0 0 ; kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0 2147483649 2147483648 ; kfbh.check: 2196044811 ; 0x00c: 0x82e4fc0b 2196041737 1363709710 ; kfbh.fcn.base: 0 ; 0x010: 0x00000000 0 0 ; kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 0 0 ; kfbh.spare1: 0 ; 0x018: 0x00000000 0 0 ; kfbh.spare2: 0 ; 0x01c: 0x00000000 0 0 ; kfdhdb.driver.provstr: ORCLDISK ; 0x000: length=8 ORCLDISK ORCLDISK ; kfdhdb.driver.reserved[0]: 0 ; 0x008: 0x00000000 0 0 ; kfdhdb.driver.reserved : 0 ; 0x00c: 0x00000000 0 0 ; kfdhdb.driver.reserved : 0 ; 0x010: 0x00000000 0 0 ; kfdhdb.driver.reserved : 0 ; 0x014: 0x00000000 0 0 ; kfdhdb.driver.reserved : 0 ; 0x018: 0x00000000 0 0 ; kfdhdb.driver.reserved : 0 ; 0x01c: 0x00000000 0 0 ; kfdhdb.compat: 168820736 ; 0x020: 0x0a100000 168820736 168820736 ; kfdhdb.dsknum: 0 ; 0x024: 0x0000 1 0 ; kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL 1 1 ; kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER 3 3 ; kfdhdb.dskname: DATA_0000 ; 0x028: length=9 DATA_0001 ARCH_0000 ; kfdhdb.grpname: DATA ; 0x048: length=4 DATA ARCH ; kfdhdb.fgname: DATA_0000 ; 0x068: length=9 DATA_0001 ARCH_0000 ; kfdhdb.capname: ; 0x088: length=0 ; kfdhdb.crestmp.hi: 32990918 ; 0x0a8: HOUR=0x6 DAYS=0x16 MNTH=0x9 YEAR=0x7dd 32990918 32990918 ; kfdhdb.crestmp.lo: 1457410048 ; 0x0ac: USEC=0x0 MSEC=0x394 SECS=0x2d MINS=0x15 1457410048 2373730304 ; kfdhdb.mntstmp.hi: 32990918 ; 0x0b0: HOUR=0x6 DAYS=0x16 MNTH=0x9 YEAR=0x7dd 32990918 32990918 ; kfdhdb.mntstmp.lo: 1464157184 ; 0x0b4: USEC=0x0 MSEC=0x151 SECS=0x34 MINS=0x15 1464157184 2381979648 ; kfdhdb.secsize: 512 ; 0x0b8: 0x0200 512 512 ; kfdhdb.blksize: 4096 ; 0x0ba: 0x1000 4096 4096 ; kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000 1048576 1048576 ; kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80 113792 113792 ; kfdhdb.dsksize: 1024 ; 0x0c4: 0x00000400 2048 3072 ; kfdhdb.pmcnt: 2 ; 0x0c8: 0x00000002 2 2 ; kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001 1 1 ; kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002 2 2 ; kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002 0 2 ; kfdhdb.redomirrors[0]: 0 ; 0x0d8: 0x0000 0 0 ; kfdhdb.redomirrors : 0 ; 0x0da: 0x0000 0 0 ; kfdhdb.redomirrors : 0 ; 0x0dc: 0x0000 0 0 ; kfdhdb.redomirrors : 0 ; 0x0de: 0x0000 0 0 ; kfdhdb.dbcompat: 168820736 ; 0x0e0: 0x0a100000 168820736 168820736 ; kfdhdb.grpstmp.hi: 32990918 ; 0x0e4: HOUR=0x6 DAYS=0x16 MNTH=0x9 YEAR=0x7dd 32990918 32990918 ; kfdhdb.grpstmp.lo: 1457384448 ; 0x0e8: USEC=0x0 MSEC=0x37b SECS=0x2d MINS=0x15 1457384448 2373709824 ; kfdhdb.ub4spare[0]: 0 ; 0x0ec: 0x00000000 0 0 ; kfdhdb.ub4spare : 0 ; 0x0f0: 0x00000000 0 0 ; kfdhdb.ub4spare : 0 ; 0x0f4: 0x00000000 0 0 ; kfdhdb.ub4spare : 0 ; 0x0f8: 0x00000000 0 0 ; kfdhdb.ub4spare : 0 ; 0x0fc: 0x00000000 0 0 ; kfdhdb.ub4spare : 0 ; 0x100: 0x00000000 0 0 ; kfdhdb.ub4spare : 0 ; 0x104: 0x00000000 0 0 ; kfdhdb.ub4spare : 0 ; 0x108: 0x00000000 0 0 ; kfdhdb.ub4spare : 0 ; 0x10c: 0x00000000 0 0 ; kfdhdb.ub4spare : 0 ; 0x110: 0x00000000 0 0 ; kfdhdb.ub4spare[10]: 0 ; 0x114: 0x00000000 0 0 ; kfdhdb.ub4spare[11]: 0 ; 0x118: 0x00000000 0 0 ; kfdhdb.ub4spare[12]: 0 ; 0x11c: 0x00000000 0 0 ; kfdhdb.ub4spare[13]: 0 ; 0x120: 0x00000000 0 0 ; kfdhdb.ub4spare[14]: 0 ; 0x124: 0x00000000 0 0 ; kfdhdb.ub4spare[15]: 0 ; 0x128: 0x00000000 0 0 ; kfdhdb.ub4spare[16]: 0 ; 0x12c: 0x00000000 0 0 ; kfdhdb.ub4spare[17]: 0 ; 0x130: 0x00000000 0 0 ; kfdhdb.ub4spare[18]: 0 ; 0x134: 0x00000000 0 0 ; kfdhdb.ub4spare[19]: 0 ; 0x138: 0x00000000 0 0 ; kfdhdb.ub4spare[20]: 0 ; 0x13c: 0x00000000 0 0 ; kfdhdb.ub4spare[21]: 0 ; 0x140: 0x00000000 0 0 ; kfdhdb.ub4spare : 0 ; 0x144: 0x00000000 0 0 ; kfdhdb.ub4spare[23]: 0 ; 0x148: 0x00000000 0 0 ; kfdhdb.ub4spare[24]: 0 ; 0x14c: 0x00000000 0 0 ; kfdhdb.ub4spare[25]: 0 ; 0x150: 0x00000000 0 0 ; kfdhdb.ub4spare[26]: 0 ; 0x154: 0x00000000 0 0 ; kfdhdb.ub4spare[27]: 0 ; 0x158: 0x00000000 0 0 ; kfdhdb.ub4spare[28]: 0 ; 0x15c: 0x00000000 0 0 ; kfdhdb.ub4spare[29]: 0 ; 0x160: 0x00000000 0 0 ; kfdhdb.ub4spare[30]: 0 ; 0x164: 0x00000000 0 0 ; kfdhdb.ub4spare[31]: 0 ; 0x168: 0x00000000 0 0 ; kfdhdb.ub4spare[32]: 0 ; 0x16c: 0x00000000 0 0 ; kfdhdb.ub4spare[33]: 0 ; 0x170: 0x00000000 0 0 ; kfdhdb.ub4spare[34]: 0 ; 0x174: 0x00000000 0 0 ; kfdhdb.ub4spare[35]: 0 ; 0x178: 0x00000000 0 0 ; kfdhdb.ub4spare[36]: 0 ; 0x17c: 0x00000000 0 0 ; kfdhdb.ub4spare[37]: 0 ; 0x180: 0x00000000 0 0 ; kfdhdb.ub4spare[38]: 0 ; 0x184: 0x00000000 0 0 ; kfdhdb.ub4spare[39]: 0 ; 0x188: 0x00000000 0 0 ; kfdhdb.ub4spare[40]: 0 ; 0x18c: 0x00000000 0 0 ; kfdhdb.ub4spare[41]: 0 ; 0x190: 0x00000000 0 0 ; kfdhdb.ub4spare[42]: 0 ; 0x194: 0x00000000 0 0 ; kfdhdb.ub4spare[43]: 0 ; 0x198: 0x00000000 0 0 ; kfdhdb.ub4spare[44]: 0 ; 0x19c: 0x00000000 0 0 ; kfdhdb.ub4spare[45]: 0 ; 0x1a0: 0x00000000 0 0 ; kfdhdb.ub4spare[46]: 0 ; 0x1a4: 0x00000000 0 0 ; kfdhdb.ub4spare[47]: 0 ; 0x1a8: 0x00000000 0 0 ; kfdhdb.ub4spare[48]: 0 ; 0x1ac: 0x00000000 0 0 ; kfdhdb.ub4spare[49]: 0 ; 0x1b0: 0x00000000 0 0 ; kfdhdb.ub4spare[50]: 0 ; 0x1b4: 0x00000000 0 0 ; kfdhdb.ub4spare[51]: 0 ; 0x1b8: 0x00000000 0 0 ; kfdhdb.ub4spare[52]: 0 ; 0x1bc: 0x00000000 0 0 ; kfdhdb.ub4spare[53]: 0 ; 0x1c0: 0x00000000 0 0 ; kfdhdb.ub4spare[54]: 0 ; 0x1c4: 0x00000000 0 0 ; kfdhdb.ub4spare[55]: 0 ; 0x1c8: 0x00000000 0 0 ; kfdhdb.ub4spare[56]: 0 ; 0x1cc: 0x00000000 0 0 ; kfdhdb.ub4spare[57]: 0 ; 0x1d0: 0x00000000 0 0 ; kfdhdb.acdb.aba.seq: 0 ; 0x1d4: 0x00000000 0 0 ; kfdhdb.acdb.aba.blk: 0 ; 0x1d8: 0x00000000 0 0 ; kfdhdb.acdb.ents: 0 ; 0x1dc: 0x0000 0 0 ; kfdhdb.acdb.ub2spare: 0 ; 0x1de: 0x0000 0 0 ;

huangtingzhong 对《 ORA-19809: limit exceeded for recovery files 》的评论

huangtingzhong — Tue, 10 Jun 2014 03:45:01 +0000

RMAN backup to Flash Recovery Area failed with ORA-19809 (文档 ID 831225.1) 转到底部转到底部修改时间:2013-11-6类型:PROBLEM 为此文档评级通过电子邮件发送此文档的链接在新窗口中打开文档可打印页In this DocumentSymptomsCauseSolutionReferencesAPPLIES TO:Oracle Database – Enterprise Edition – Version 10.2.0.1 to 11.2.0.2.0 [Release 10.2 to 11.2]Information in this document applies to any platform.***Checked for relevance on 06-Nov-2013***SYMPTOMSRMAN backup of the database to Flash Recovery Area ( FRA ) failed with ORA-19809: limit exceeded for recovery files NOTE : since 11gRelease2 ‘Flash Recovery Area’ has been renamed to ‘Fast Recovery Area’Error——RMAN-03009: failure of backup command on ORA_DISK_4 channel at 12/18/2007 09:53: 44 ORA-19809: limit exceeded for recovery files ORA-19804: cannot reclaim 1561238528 bytes disk space from 21474836480 limitCAUSEBy default RMAN backup goes to Flash Recovery Area if it is set . Whenever there is space pressure, the RDBMS will try to delete obsolete backups in FRA in order to make more space. In case its not able to make more space and required space exceeds the limit of flash recovery area then its fails with those error message.Its because of the FRA’s space limit. Flash Recovery Area has a defined size when the required space exceed the limit of the FRA those errors are expected. SOLUTION Make more space in FRA by either increasing the size of FRA or by deleting unwanted backups or by taking existing FRA contents backup to tape.- Increase the size of FRA SQL> alter system set db_recovery_file_dest_size=xG SCOPE=BOTH; — Higher_size – Take a backup of FRA to tapeRMAN> BACKUP RECOVERY AREA; You can also delete the unwanted backups. Its recommended to delete it via RMAN only. Please note in case you are deleting manually then you need to execute a CROSSCHECK and DELETE EXPIRED in order to get those information reflected in FRA size.For more on FRA space issue refer Note 829755.1 : Space issue in Flash Recovery Area( FRA )REFERENCESNOTE:305648.1 – What is a Flash Recovery Area and how to configure it ?NOTE:829755.1 – Space issue in Flash Recovery Area( FRA )

huangtingzhong 对《 ORA-19809: limit exceeded for recovery files 》的评论

huangtingzhong — Tue, 10 Jun 2014 03:44:46 +0000

Database Crashed With ORA-19815 ORA-19809 ORA-16038 (文档 ID 829254.1) 转到底部转到底部修改时间:2014-1-23类型:PROBLEM 为此文档评级通过电子邮件发送此文档的链接在新窗口中打开文档可打印页In this DocumentSymptomsCauseSolutionReferencesAPPLIES TO:Oracle Database – Enterprise Edition – Version 10.2.0.1 to 11.2.0.2.0 [Release 10.2 to 11.2]Information in this document applies to any platform.***Checked for relevance on 08-Mar-2013***SYMPTOMSInstance terminated due to error 16038 as its not able to archive the log in FRAORA-19815: WARNING: db_recovery_file_dest_size of 99614720000 bytes is 100.00% used, and has 0 remaining bytes available. Sat Mar 8 00:57:07 2008 ************************************************************************ You have following choices to free up space from flash recovery area: 1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard, then consider changing RMAN ARCHIVELOG DELETION POLICY. 2. Back up files to tertiary device such as tape using RMAN BACKUP RECOVERY AREA command. 3. Add disk space and increase db_recovery_file_dest_size parameter to reflect the new space. 4. Delete unnecessary files using RMAN DELETE command. If an operating system command was used to delete files, then use RMAN CROSSCHECK and DELETE EXPIRED commands. ************************************************************************ Sat Mar 8 00:57:07 2008 Errors in file /usr/oracle/admin/ORAPTCMK/bdump/oraptcmk1_arc0_623454.trc: ORA-19809: limit exceeded for recovery files ORA-19804: cannot reclaim 308281344 bytes disk space from 99614720000 limit Sat Mar 8 00:57:07 2008 ARC0: Error 19809 Creating archive log file to ‘+DATA’ Sat Mar 8 00:57:07 2008 Errors in file /usr/oracle/admin/ORAPTCMK/udump/oraptcmk1_ora_680508.trc: ORA-16038: log 17 sequence# 34003 cannot be archived ORA-19809: limit exceeded for recovery files ORA-00312: online log 17 thread 1: ‘+DATA/oraptcmk/onlinelog/redolog171.log’ ORA-00312: online log 17 thread 1: ‘+FLRC/oraptcmk/onlinelog/redolog172.log’ Sat Mar 8 00:57:07 2008 USER: terminating instance due to error 16038CAUSEDefault archive log destination was set to Flash Recovery Area and FRA is 100% used. There is no space to create additional archive log.Similar situation also occur if the database is up and running and archive log’s destination for FRA is full then the database will hang.Other similar issue because of archiving is stuck because of FRA space pressure are1. Database Hangs2. Users not able to connect to database3. Not able to open the database 4. FRA space related error in the alert.log file ( ORA-19809 )SOLUTIONMake more space in Flash Recovery Area or change the archivelog destination to outside Flash Recovery Area.By default Archive log are created in FRA if no specific log_archive_dest_n parameter was set and Flash Recovery Area is enabled.SQL> show parameter db_recovery_file_dest NAME VALUE ———————- ————————– db_recovery_file_dest E:oracleproduct10.2.0flash_recovery_area db_recovery_file_dest_size 2GSQL> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 174 Next log sequence to archive 176 Current log sequence 176If you are using RMAN for the database backup then check the space distribution in FRAfor exampleSQL>select file_type, percent_space_used as used,percent_space_reclaimable as reclaimable, number_of_files as “number” from v$flash_recovery_area_usage; FILE_TYPE USED RECLAIMABLE number ———— ———- ———– ———- CONTROLFILE 0 0 0 ONLINELOG 0 0 0 ARCHIVELOG 89.94 0 53 BACKUPPIECE 9.51 0 11 IMAGECOPY 0 0 0 FLASHBACKLOG 0 0 0In the Above example almost all the space are used by Archivelogs and backup pieces and there is no space to reclaim. In this type of case you cana) Increase the FRA size b) Take backup backup of the archivelogs to different location c) If tape backup is a option then take backup of FRA to tape d) Change archivelogs destination out of FRA d) Delete archivelogs to make more space. ( should be the last option) and in case of standby database make sure those logs are already applied to standby Usually archiving is configured to FRA for automatic management of archivelog files. This works well if you are using a standby configuration or using RMAN for backups so that there is a basis for archives to get obsolete and be cleaned up automatically from FRA. If you do not want to take advantage of automatic space management in FRA, you can set any non FRA location for the archivelogs.for exampleSet an archivelog destination SQL> alter system set log_archive_dest_1=’LOCATION=E:oracleproduct’ scope=both ; Unset the default setting for FRA SQL> alter system set log_archive_dest_10=” scope=both; + If this is an database version less than 11.2, then due to an unpublished Bug# 6964464 (fixed in 11.2), stuck archiver causes the instance to crash which is not the normal behaviour. Normally, the instance would hang until the stuck archiver is freed from errors. REFERENCESNOTE:829755.1 – Space issue in Fast / Flash Recovery Area – FRA Full

「认真就输」的评论

数据库爱好者 对《 Oracle DBA必备脚本：傻子都可以一眼就定位SQL慢在什么地方 》的评论

hi 对《 案例分享:医院行业数据泵迁移案例 》的评论

csdw 对《 ORA-01031通过truss分析 》的评论

csdw 对《 一次RMAN还原慢的分析 》的评论

huangtingzhong 对《 如何在nbu中配置清洗带 》的评论

huangtingzhong 对《 SPM中加载提示执行计划 》的评论

huangtingzhong 对《 ORACLE 分布式事务处理（一般情况） 》的评论

huangtingzhong 对《 ORA-01210: data file header is media corrupt 》的评论

huangtingzhong 对《 ORA-19809: limit exceeded for recovery files 》的评论

huangtingzhong 对《 ORA-19809: limit exceeded for recovery files 》的评论

数据库爱好者对《 Oracle DBA必备脚本：傻子都可以一眼就定位SQL慢在什么地方》的评论

hi 对《案例分享:医院行业数据泵迁移案例》的评论

csdw 对《 ORA-01031通过truss分析》的评论

csdw 对《一次RMAN还原慢的分析》的评论

huangtingzhong 对《如何在nbu中配置清洗带》的评论

huangtingzhong 对《 SPM中加载提示执行计划》的评论

huangtingzhong 对《 ORACLE 分布式事务处理（一般情况）》的评论