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

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.

adrci 命令

相關文章