求教：归档进程的管理

shiri512003

Fri May 25 20:46:06 2007
Starting control autobackup
Control autobackup written to DISK device
        handle '/ora_rman_backup/crtl_backup/c-4205638757-20070525-00'
Fri May 25 20:46:11 2007
Thread 1 advanced to log sequence 535
  Current log# 1 seq# 535 mem# 0: /dev/udpay/lv_redo11_256m
  Current log# 1 seq# 535 mem# 1: /dev/udpay/lv_redo12_256m
Fri May 25 20:46:11 2007
ARCH: Evaluating archive   log 6 thread 1 sequence 534
ARCH: Beginning to archive log 6 thread 1 sequence 534
Creating archive destination LOG_ARCHIVE_DEST_1: '/archivelog/arch/1_534.dbf'
Fri May 25 20:46:12 2007
ARC0: Evaluating archive   log 6 thread 1 sequence 534
ARC0: Unable to archive log 6 thread 1 sequence 534
      Log actively being archived by another process
Fri May 25 20:46:15 2007
ARCH: Completed archiving  log 6 thread 1 sequence 534
Fri May 25 20:46:18 2007
Thread 1 advanced to log sequence 536
  Current log# 2 seq# 536 mem# 0: /dev/udpay/lv_redo21_256m
  Current log# 2 seq# 536 mem# 1: /dev/udpay/lv_redo22_256m
Fri May 25 20:46:18 2007
ARCH: Evaluating archive   log 1 thread 1 sequence 535
ARCH: Beginning to archive log 1 thread 1 sequence 535
Creating archive destination LOG_ARCHIVE_DEST_1: '/archivelog/arch/1_535.dbf'
Fri May 25 20:46:19 2007
ARC0: Evaluating archive   log 1 thread 1 sequence 535
ARC0: Unable to archive log 1 thread 1 sequence 535
      Log actively being archived by another process
Fri May 25 20:46:19 2007
ARCH: Completed archiving  log 1 thread 1 sequence 535
Fri May 25 20:46:40 2007
Starting control autobackup
Control autobackup written to DISK device
        handle '/ora_rman_backup/crtl_backup/c-4205638757-20070525-01'

为什么一秒后
oracle又启动了另外一个进程去归档
oracle关于归档进程的管理是怎么的呢？
实在不解，请大家指教一下

paulyibinyi

log_archive_max_processes这个参数的缺省值是2 ,估计跟日志切换的快慢有关系,不太确定,期待高手解决

rollingpig

这样子就OK了。
当然，如果没有smtools.utc2date，自己创建一个
SELECT   c.cwt_business_id, b.su_mdn, COUNT( a.su_id ) COUNT
    FROM track a, service_unit b, corporation c
   WHERE a.su_id(+) = b.su_id AND b.corp_id = c.corp_id AND  a.utc  >=  smtools.utc2date(1177689600)
         AND  a.utc <  smtools.utc2date(1177776000)
GROUP BY c.cwt_business_id, b.su_mdn
ORDER BY c.cwt_business_id, b.su_mdn;

shiri512003

可否请斑竹说清楚些
我执行语句报
ERROR at line 2:
ORA-00942: table or view does not exist

shiri512003

经过这段时间的思考，我觉得应该是oracle的归档进程的管理机制所产生的。
首先oracle初始化参数log_archive_max_processes决定初始启动的归档进程数。
可以查看v$archive_processes视图或系统进程，注意到其实oracle从一开始就启动了log_archive_max_processes所指定的数目，只是大家可以看看他们的状态。
从报出来的提示看，oracle对归档进程的管理应该是采用了竞争机制，类似于lgwr进程每3秒激活一次，arch也是定期的激活或者是由日志切换触发（我觉得后者更合理），所有归档进程都去归档需要归档的日志，肉少狼多，没肉吃的就只好‘抱怨’了！
所以这的确只是一个harmless提示！！！
但是！！！oracle如果在这样环境里给用户这么个信息，不是自找没趣吗？！
oracle还没这么傻吧！
既然不是oracle的话，那就要看自己了！
如果已经起用了自动归档，这时你在做手工归档看看！
问题出现了！！！
这才是问题的本源！
遇到类似问题的朋友，仔细想想，自己是不是这种情况？
当然千奇百怪的错误总是会有的，有不是这种情况的朋友帖出来看看吧！
至于在网上常看到有人说是归档过慢之类的原因，我觉得oracle不会这么傻吧！
既然已经交给一个归档进程去做了，那慢又怎么样？杀掉这个任务换个家伙去干？况且oracle怎么判断他慢呢？就算可以给个标准，那至少也该有个参数控制吧！可我并没有找到这样的参数！如果是内固的话，我只能说产品太没人情味了！
至于说与log_archive_max_processes有关，oracle觉得慢，又调用了一个进程去归档它，那更是自相矛盾了！！！从日志看，oracle是对正在归档的日志加锁了的，就算慢，也不可能去启动另一个进程去归档它！如果可以的话，也不用那个提示了！
以上只是自己在一个合理的假设内所做的推断，还请大家多多指教，有什么不足还请大家指正！！！

shiri512003

日志摘录
Thu Jun  7 10:42:51 2007
ARCH: Evaluating archive   log 2 thread 1 sequence 488
ARCH: Beginning to archive log 2 thread 1 sequence 488
Creating archive destination LOG_ARCHIVE_DEST_1: '/home/oracle/product/9204/dbs/arch/1_488.dbf'
Thu Jun  7 10:42:51 2007
ARC0: Evaluating archive   log 2 thread 1 sequence 488
ARC0: Unable to archive log 2 thread 1 sequence 488
      Log actively being archived by another process
Thu Jun  7 10:42:52 2007
ARCH: Completed archiving  log 2 thread 1 sequence 488
Thu Jun  7 10:45:10 2007
ALTER SYSTEM SET log_archive_start=FALSE SCOPE=SPFILE;
Thu Jun  7 10:45:43 2007
Thu Jun  7 10:46:20 2007
ALTER DATABASE OPEN
Thu Jun  7 10:46:46 2007
ARCH: Evaluating archive   log 3 thread 1 sequence 489
ARCH: Beginning to archive log 3 thread 1 sequence 489
Creating archive destination LOG_ARCHIVE_DEST_1: '/home/oracle/product/9204/dbs/arch/1_489.dbf'
Thu Jun  7 10:46:46 2007
Thread 1 advanced to log sequence 490
  Current log# 1 seq# 490 mem# 0: /home/oradata/gias/logfile/redo01.log
Thu Jun  7 10:46:46 2007
ARCH: Completed archiving  log 3 thread 1 sequence 489

shiri512003

补充两点：
1对于10G模拟不出来结果是因为oracle已经不在使用
log_archive_start
这个参数了
2实际上仔细观察日志会发现实际上oracle可能采用的是队列机制
，在日志中可以看到arch0 arch1是交叉运行的，这样可以保证进程分配不会冲突

javaever

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.



From Metalink: 260040.1

foxmile

学习

shiri512003

谢谢
具体原因eygle版主已经查明证实了
http://www.eygle.com/archives/20 ... e_process_more.html
我这里没有使用dg
database version 9204
另外可以
看看
v$archived_log.CREATOR