[摘錄] Refining Remote Archival Over a Slow Network with the ARCH Process
Subject: Refining Remote Archival Over a Slow Network with the ARCH Process
Doc ID:
Note:260040.1 Type: BULLETIN
Last Revision Date: 19-JUN-2006 Status: PUBLISHED
Purpose
When archiving locally and remotely using the ARCH process where the remote destination is across a saturated or slow network you can receive the following errors in the alert log:
ARC0: Evaluating archive log 2 thread 1 sequence 100
ARC0: Unable to archive log 2 thread 1 sequence 100
Log actively being archived by another process
If the ARCH process is unable to archive at the rate at which online logs are switched then it is possible for the primary database to suspend while waiting for archiving to complete. The following discussion describes how this can occur.
Default Behavior. for 9iR2 and Below
The ARCH process sits in a very tight loop waiting for an update to the controlfile that states an online log needs to be archived. Once the update occurs the ARCH process builds a list of archive destinations that need to be serviced. Once this list is complete, the ARCH process will read a one megabyte chunk of data from the online log that is to be archived. This one megabyte chunk is then sent to the first destination in the list. When the write has completed, the same one megabyte chunk is written to the second destination. This continues until all of the data from the online log being archived has been written to all destinations. So it can be said that archiving is only as fast as the slowest destination.
A common misconception is that if the LOG_ARCHIVE_DEST_n parameter for a particular destination has the OPTIONAL attribute set, then that destination will not impede local archiving. This is true during error situations while archiving to that destination - e.g. a network disconnect error, but not during an archival over a slow network, which is not an error situation. In error situations, whether the destination is marked OPTIONAL or MANDATORY, Data Guard will close that destination and continue transmitting to all other valid destinations. Transmitting to the closed destination will be attempted again only after the time specified in the REOPEN attribute has expired and a log switch has occurred. This process will continue for the number of times specified by the MAX_FAILURE attribute. During this time, it is possible that the log writer process recycles through the available online redo log groups and tries to use the online redo log file which has not yet been transmitted successfully to the remote destination. If the destination is marked OPTIONAL, log writer will reuse the online redo log file for the next set of redo. If the destination is marked MANDATORY, log writer will not be able to reuse that online redo log file, and the primary database will delay processing until that online redo log file has been successfully transmitted to the remote destination.
However, the situation is very different if the transmission is being done over a slow network. In this case, no error is encountered and the destination is not closed. Transmission continues, but is very slow. Ultimately, with the unavailability of any more online redo log groups, Log writer may suspend because the archive process is taking a long time to complete its archival, including local archival.
Refining the Default Behavior
The following underscore parameter was introduced as of 9.2.0.5 to allow the DBA to change this default behavior.:
_LOG_ARCHIVE_CALLOUT='LOCAL_FIRST=TRUE'
If the above parameter is set then the ARCH process will begin archiving to the local destination first. Once the redo log has been completely and successfully archived to at least one local destination, it will then be transmitted to the remote destination. This is the default behavior. beginning with Oracle Database 10g Release 1.
Starting in 9.2.0.7 patchsets, one ARCH process will begin acting as a 'dedicated' archiver, handling only local archival duties. It will not perform. remote log shipping or service FAL requests. This is a backport of behavior. from 10gR1 to 9iR2.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/35489/viewspace-561358/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 修改Oracle process 和 session 的方法--摘OracleSession
- ARCH: Possible network disconnect with primary databaseDatabase
- 【摘錄】index(一)Index
- [network][easy case]troubleshoting the connection to a remote serverREMServer
- progit摘錄筆記Git筆記
- <摘錄>GCC 中文手GC
- 物件導向(摘錄)物件
- SAP BI工作摘錄
- 知:孫子兵法摘錄
- 番茄工作法摘錄
- 讀書筆記摘錄:筆記
- statspack報告分析摘錄
- 程式設計人生-摘錄程式設計
- The partner transaction manager has disabled its support for remote/network transactions.REM
- 如何禁用埠!(網路摘錄)
- <摘錄>linux檔案IOLinux
- <摘錄>linux signal 列表Linux
- 《圖解HTTP》知識點摘錄圖解HTTP
- <摘錄>linux 預設的includeLinux
- <摘錄>linux論壇網站Linux網站
- 記錄安裝好Arch WSL後的配置
- Oracle使用over()partition by刪除重複記錄Oracle
- 如何推廣自己的應用--摘錄
- <摘錄>演算法策略的總結演算法
- 《dive into python3》 筆記摘錄Python筆記
- <摘錄>開源軟體架構-ZeroMQ架構MQ
- AIX巡檢常用命令(摘錄)AI
- 【筆記】statspack(三) report分析 摘錄筆記
- 需求工程師的素質-摘錄工程師
- 摘錄_c# ftp操作程式碼集C#FTP
- SQL Story摘錄(四)————資訊挖掘初步 (轉)SQL
- 《SQL Story》摘錄五——關係真相 (轉)SQL
- SQL Story摘錄(八)————資料抽取 (轉)SQL
- coca SLOW QUERY
- javascript 中function(){},new function(),new Function(),Function 摘錄JavaScriptFunction
- 富爸爸財務自由之路--筆記摘錄筆記
- SQL4必知必會摘錄(一)SQL
- SQL必知必會4-摘錄二SQL