Re: Interpreting some alrt.log output

From: Ed Stevens <nospam_at_noway.nohow>
Date: Thu, 15 Apr 2004 07:38:44 -0500
Message-ID: <uuvs709dpge6ubo60isaottkqs8fbjm8s3@4ax.com>

Joel,

Thanks for your comments. Replies embedded:

On 14 Apr 2004 16:14:44 -0700, joel-garry_at_home.com (Joel Garry) wrote:

>Ed Stevens <nospam_at_noway.nohow> wrote in message news:<f40r70582idcsc88bl6p61ngfa34d70so8_at_4ax.com>...
>> Platform: Oracle 8.1.7 EE on Solaris 8
>>
>> No particular problem, just poking around in the alert log to get a
>> better understanding of exactly what normal output is telling me.
>> Here is a chunk of one. My comments/observations/questions are
>> enclosed in parenthesis. Apologies for any line wrap. Would anyone
>> care to set me straight if my obervations are wrong? Thanks.
>>
>> Tue Apr 13 20:11:57 2004
>> Beginning log switch checkpoint up to RBA [0x200.2.10], SCN:
>> 0x0000.01957b81
>> Thread 1 advanced to log sequence 512
>> Current log# 2 seq# 512 mem# 0: /u06/oradata/CMQM1240/redo201.log
>> Current log# 2 seq# 512 mem# 1: /u07/oradata/CMQM1240/redo202.log
>>
>> (we just switched to log group #2. This is the 512th log switch since
>> the db was put in archive log mode. ??)
>
>Well, look at the sequence number just after the CREATE DATABASE
>statement (assuming you created it in archive log mode). My first
>switch said 2, presumably 1 was creating the system ts. So the number
>of switches would be one less than the sequence number?

Ok. I might be a few off from the beginning, but sounds like I've got the concept right.
>
>>
>> Tue Apr 13 20:11:57 2004
>> ARCH: Evaluating archive log 1 thread 1 sequence 511
>> ARCH: Beginning to archive log 1 thread 1 sequence 511
>>
>> (Since we are now using rdo log group #2 for seq. 512, we can start
>> archiving sequence 511, presumably from rdo log group #1
>>
>> Tue Apr 13 20:11:57 2004
>> ARC0: Evaluating archive log 1 thread 1 sequence 511
>> ARC0: Unable to archive log 1 thread 1 sequence 511
>> Log actively being archived by another process
>>
>> (A second archive of seq. 511? Why?)
>
>Archiver starts up other processes for various reasons, such as one is
>taking too long for the load.
>
>>
>> Tue Apr 13 20:11:57 2004
>> Creating archive destination LOG_ARCHIVE_DEST_1:
>> '/u08/arch/CMQM1240/arch_1_511.arc'
>> ARCH: Completed archiving log 1 thread 1 sequence 511
>>
>> (Created and completed writing the archive log for seq. 511)
>>
>> Tue Apr 13 20:26:45 2004
>> ARCH: Possible network disconnect with primary database
>>
>> ( huh??)
>
>All sorts of things can go wrong, may or may not mean anything. Do
>you have standby, or multiple arc destinations? One must always
>assume a network will munge things up, and 8i standby architecture
>doesn't quite understand this. Worst case, it can hang your primary
>db, so definitely open a tar and get after your network admins if this
>happens repeatedly.
>

No standby, and no multiple arc destinations. Here's the relevant entries from init<sid>.ora

###########################################

# Archiving

###########################################
log_archive_dest_1 = "location=/u08/arch/CMQM1240 MANDATORY"
log_archive_format = 'arch_%t_%s.arc'
log_archive_start = true
log_archive_max_processes = 1
log_checkpoint_interval=99999999

log_checkpoint_timeout=900
log_checkpoints_to_alert=TRUE
>>
>> Tue Apr 13 20:27:15 2004
>> Completed checkpoint up to RBA [0x200.2.10], SCN: 0x0000.01957b81
>> Wed Apr 14 08:46:42 2004
>> Beginning log switch checkpoint up to RBA [0x201.2.10], SCN:
>> 0x0000.01969b1d
>>
>> (checkpoint and log switch, but notice the time elapsed between the
>> two)
>
>That's why I like to use cron to harden the times between log switches
>with an explicit alter system switch logfile.
>
>>
>> Thread 1 advanced to log sequence 513
>> Current log# 3 seq# 513 mem# 0: /u06/oradata/CMQM1240/redo301.log
>> Current log# 3 seq# 513 mem# 1: /u07/oradata/CMQM1240/redo302.log
>> Wed Apr 14 08:46:42 2004
>> ARC0: Evaluating archive log 2 thread 1 sequence 512
>> ARC0: Beginning to archive log 2 thread 1 sequence 512
>> Creating archive destination LOG_ARCHIVE_DEST_1:
>> '/u08/arch/CMQM1240/arch_1_512.arc'
>> ARC0: Completed archiving log 2 thread 1 sequence 512
>>
>> (this time there was no second attempt to archive)
>>
>> Wed Apr 14 09:02:10 2004
>> Completed checkpoint up to RBA [0x201.2.10], SCN: 0x0000.01969b1d
>
>How big is that SGA, anyways?

SQL> select * from v$sga;

NAME                      VALUE
-------------------- ----------
Fixed Size               730944
Variable Size         503316480
Database Buffers      335544320
Redo Buffers             811008

BTW, this db was setup via an app vendor supplied script.

>
>jg
Received on Thu Apr 15 2004 - 07:38:44 CDT