adrci
ADR uses what it refers to as a flood-controlled incident system, whereby it
allows only a certain number of incidents under a problem to log diagnostic data.
By default, ADR allows 5 diagnostic data dumps per hour for a single problem. If an
incident occurs 20 times but all the incidents are connected to the same problem,
you have to report to Oracle Support only one incident. Flood-controlled incident
reporting ensures that numerous incidents pertaining to the same problem don’t
overwhelm the ADR by taking up an inordinate amount of space.
[@more@]
Bug 10133035 : CTRL+C TO END ADRCI SHOW ALERT -TAIL -F EXITS TO COMMAND PROMPT
SHOW ALERT -TAIL
This displays the last portion of the alert log (the last 10 entries) in your
terminal session.
SHOW ALERT -TAIL 50
This displays the last 50 entries in the alert log in your terminal session.
SHOW ALERT -TAIL -F
This displays the last 10 entries in the alert log, and then waits for more
messages to arrive in the alert log. As each message arrives, it is appended
to the display. This command enables you to perform "live monitoring" of the
alert log. Press CTRL-C to stop waiting and return to the ADRCI prompt.
Problem description:
When using SHOW ALERT -TAIL -F and pressing Ctrl+C , on some platforms, the
ADRCI prompt returns, however on other platforms, the command prompt returns,
and we are thrown out of the ADRCI.
The ctrl+c works as expected on Linux and Windows , but it doesn't work as
expected on AIX, SUN.
奇怪,我的 windows 平台下也遇到这个 bug :
C:UsersAdministrator>adrci
ADRCI: Release 11.2.0.1.0 - Production on Mon Sep 10 21:43:26 2012
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
ADR base = "c:appadministrator"
adrci> show home
ADR Homes:
diagclientsuser_administratorhost_2122682093_76
diagclientsuser_systemhost_2122682093_76
diagrdbmsorcl11gorcl11g
adrci> set home diagrdbmsorcl11gorcl11g
adrci> show home
ADR Homes:
diagrdbmsorcl11gorcl11g
adrci> show alert -tail
2012-09-10 21:42:27.417000 +08:00
ARC2 started with pid=22, OS id=3448
ARC3 started with pid=23, OS id=5168
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
No Resource Manager plan active
Starting background process QMNC
QMNC started with pid=24, OS id=3632
2012-09-10 21:42:28.540000 +08:00
Completed: alter database open
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
db_recovery_file_dest_size of 3912 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
2012-09-10 21:42:30.642000 +08:00
Starting background process CJQ0
CJQ0 started with pid=25, OS id=3548
adrci> show alert -tail
2012-09-10 21:42:27.417000 +08:00
ARC2 started with pid=22, OS id=3448
ARC3 started with pid=23, OS id=5168
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
No Resource Manager plan active
Starting background process QMNC
QMNC started with pid=24, OS id=3632
2012-09-10 21:42:28.540000 +08:00
Completed: alter database open
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
db_recovery_file_dest_size of 3912 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
2012-09-10 21:42:30.642000 +08:00
Starting background process CJQ0
CJQ0 started with pid=25, OS id=3548
adrci>
adrci> show alert -tail -f
2012-09-10 21:42:28.639000 +08:00
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
db_recovery_file_dest_size of 3912 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
2012-09-10 21:42:30.642000 +08:00
Starting background process CJQ0
CJQ0 started with pid=25, OS id=3548
2012-09-10 21:47:28.600000 +08:00
Starting background process SMCO
SMCO started with pid=28, OS id=4152
2012-09-10 21:48:06.536000 +08:00
Thread 1 advanced to log sequence 13 (LGWR switch)
Current log# 1 seq# 13 mem# 0: C:APPADMINISTRATORORCL11GREDO01.LOG
2012-09-10 21:48:08.142000 +08:00
Archived Log entry 1 added for thread 1 sequence 12 ID 0x359b2662 dest 1:
^C
C:UsersAdministrator>
关于 ADR 的 retention policy
ADR follows a retention policy so it can limit the amount of diagnostic data it must
store. The retention policy actually includes two different settings, one for metadata
retention and the other for incident files and dumps retention, as explained here:
■ The incident metadata retention policy, which has a default setting of one
year, determines how long ADR retains the incident metadata.
■ The incident files and dumps retention policy, with a default setting of one
month, determines how long ADR retains the dump files generated for
critical errors.
You can change either of the different policies pertaining to the ADR incidents
by using the Incident Package configuration link on the Support Workbench page
in Enterprise Manager.
The background process MMON (memory monitor) is in charge of removing
expired ADR data.
You can’t disable automatic incident creation for critical errors.
An incident can be in any one of the following states at a given point in time:
■ Collecting A newly created incident is currently collecting diagnostic data.
■ Ready The incident’s data collection phase is complete, and you can
package the incident to send to Oracle Support.
■ Tracking The incident must be kept in the ADR indefinitely because the
DBA is currently working on it. You must manually set the incident status to
this value.
■ Closed The incident is resolved and the ADR will purge it once the
incident passes its retention period.
■ Data-Purged The incident metadata is still valid but the associated files
have been detached from the incident.
If an incident remains in the collecting or ready state for a period that’s twice
as long as its retention period, it automatically is moved to a closed state.
To check an incident’s current status, use either the Support Workbench or issue
the following ADRCI command:
adrci> show incident –mode detail
You can issue just the plain show incident command to get basic details
about all incidents currently considered open.
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/66634/viewspace-1059392/,如需转载,请注明出处,否则将追究法律责任。