Got the following error in the alert log:
ORA-27301: OS failure message: Resource temporarily unavailable ORA-27302: failure occurred at: skgpspawn5 ORA-27300: OS system dependent operation:fork failed with status: 11 ORA-27301: OS failure message: Resource temporarily unavailable ORA-27302: failure occurred at: skgpspawn5 ORA-19583: conversation terminated due to error ORA-04030: out of process memory when trying to allocate 1052696 bytes (KSFQ heap,KSFQ Buffers) ORA-27300: OS system dependent operation:fork failed with status: 12 ORA-27301: OS failure message: Not enough space ORA-27302: failure occurred at: skgpspawn3
Solution: The problem was fixed by increasing the PGA from 399M to 500M.
Wednesday, May 28, 2008
Tuesday, May 13, 2008
Block change tracking on standby doesn't work
Today I asked how to turn on block tracking changing on physical standby side for Oracle 10g release 2. The Oracle support said it doesn't work even you turn it on.
Here is what they said:"
Block Change Tracking can be enabled at a physical standby database. However, you should note that changed blocks are not recorded, and incremental backups will not be faster during the physical standby as they are receiving and applying redo transactions from the primary database.
When the physical standby becomes a primary database, changes are once again recorded. Following the subsequent Level 0 backup, incremental backups take advantage of change tracking.
Your primary database block change tracking file would not get updated when you perform backup from standby. In 10.2, the CTWR process will only appear when the database is open. So even though you can enable block change tracking at a standby database, which will create the change tracking file, the CTWR process which is responsible for writing to the BCT filewill not start and the standby database will not record changes while the database is in recovery mode. It will start recording changes after the database is opened after a switchover or failover.
Refer Note.262853.1 Ext/Pub 10G RMAN Fast Incremental Backups."
I guess we still have one choice. It is to do the incremental backup at primary side. Since the block tracking changing on primary side will work, incremental backups at primary side may take much less time than the standby side. We can still perform the full backup at standby side as it takes the same amount of time as at primary side.
Here is what they said:"
Block Change Tracking can be enabled at a physical standby database. However, you should note that changed blocks are not recorded, and incremental backups will not be faster during the physical standby as they are receiving and applying redo transactions from the primary database.
When the physical standby becomes a primary database, changes are once again recorded. Following the subsequent Level 0 backup, incremental backups take advantage of change tracking.
Your primary database block change tracking file would not get updated when you perform backup from standby. In 10.2, the CTWR process will only appear when the database is open. So even though you can enable block change tracking at a standby database, which will create the change tracking file, the CTWR process which is responsible for writing to the BCT filewill not start and the standby database will not record changes while the database is in recovery mode. It will start recording changes after the database is opened after a switchover or failover.
Refer Note.262853.1 Ext/Pub 10G RMAN Fast Incremental Backups."
I guess we still have one choice. It is to do the incremental backup at primary side. Since the block tracking changing on primary side will work, incremental backups at primary side may take much less time than the standby side. We can still perform the full backup at standby side as it takes the same amount of time as at primary side.
Subscribe to:
Posts (Atom)