Starting with 11.2, you do not need to create the trigger, you can define a role based service with Grid Infrastructure.
srvctl add service -db foo -service virtual_foo -role primary
srvctl start service -db foo -service virtual_foo
srvctl add service -db bar -service virtual_foo -role primary
srvctl start service -db bar -service virtual_foo
I think what you want is real time apply, but for that, you'll have to create standby redo logs on your standby database first. As a side note, to make role transitions easier, it is considered best practice to create standby redo logs on your primary database as well:
The standby redo logs should be the same size as your redo logs and you need at least 1 ...
If the database is setup correct: no direct path load. If a standby database is depending on the changes captured on the primary database, the primary database should be setup with force logging.
If for some reason the force logging setting is not in place, after such an operation the affected datafiles should be transferred to the standby site[s]. Failing ...
Yes, you can manually script it.
This is covered in the documentation here.
In essence, you copy the archive log files to the correct filesystem location on the logical standby host, then register them using the ALTER DATABASE REGISTER LOGFILE command.
When using Oracle Data Guard with TDPO, what is the best strategy to
ensure backups continue after failover/switchover?
Use RMAN catalog, because without a catalog, backups taken on one site do not appear in the controlfile of the database on the other site. You need a centralized catalog for backups in a Data Guard configuration.
Use role-based services,...
Fault-tolerant storage, a stand-by database (Data Guard in your case), and the database backup are three different solutions to different types of problems. Depending on how much downtime you can afford, you may need to implement all three.
I simply do not believe. It's impossible. There is process called FAL (Fetch Archive Log), it can happen that redo-logs are not TRANSFERRED in chronological order, but anyway they must be APPLIED in chronological order.
Also logical standby has can have some gotchas but those are not related to network link.
(For example for some reason LOCK TABLE statement ...
There aren't any special considerations that need to be taken into account when setting up a RAC->No RAC Primary->Standby configuration.
In fact, there's a White Paper written by Oracle which explains the setup.
The Oracle documentation is here.
The unique names of the databases in a Data Guard configuration are listed in the log_archive_config parameter in the following form:
You can remove the old one and add the new one as:
alter system set log_archive_config='DG_CONFIG=(PDB10,PDB10SBY)';
After this, you can set log_archive_dest_N to the new ...
The notes about this in Oracle 220.127.116.11 state that it is not required to move/copy the files from the primary during the plugin. The note also states that in this release the copy of the standby files of the source can be postponed using the standbys=none clause. This makes it possible to plugin a large primary database in a primary container database and ...
Ok, so I had some time to waste, and this is just for the "fun" or "interesting" factor. It's nowhere near that I would use in a real scenario, I have played with it in my lab environment on x86-64 Linux platform, with a few 10g, 11g and 12c databases. At least you can do this even if the database is shut down.
When you do a controlfile dump with:
In this Oracle page entitled Database High Availability Best Practices it discusses Data Guard Deployment Options:
Requirement of Zero data loss protection and availability for Oracle Database:
Data Guard Maximum Protection or Maximum Availability (SYNC transport) and Redo Apply (physical standby)
Requirement for Near-zero data loss (single-digit seconds) ...
You can not do this with a physical standby, you will need some kind of logical replication.
With a logical standby, you can skip DMLs, but that would skip all DMLs.
With Oracle Goldengate, you can easily skip deletes, as you can specify the IGNOREDELETES option: IGNOREDELETES
Ok, now let's assume you have configured your system to ignore deletes. Imagine ...
If the standby site becomes unreachable, the primary site will not delete archivelogs as they will be still needed by the standby site. If you try to backup and delete these archivelogs, you will receive an ORA-08137 error, and eventually your archive area will become full and your database will stall.
Setting log_archive_dest_state_n to DEFER lifts this "...
I would change the whole process of deploying.
Stop SQL Apply.
Create restore point on standby.
Deploy to standby
When testing is complete, flashback standby.
Start SQL Apply.
Safe to deploy on primary.
Just disable sending redo to the standby on the primary (replace with actual dest number):
SQL> alter system set log_archive_dest_state_2=defer scope=memory;
To re-enable (replace with actual database name):
DGMGRL> enable database orcl_sb
If you want to do replication from one database to another, but skip certain schemas, then a Data Guard logical standby database may be a good fit for you.
However, if you want to perform replication from within the same database at the schema level, then Oracle GoldenGate "may" be able to do that... however, I've never used GoldenGate, so I can't confirm ...
Final situation that works is:
Stop SQL Apply on logical standby
Create restore point on standby
Create restore point on primary
Do stuff on primary, error occurs
Flashback primary database to restore point
Flashback logical to restore point
Open primary database
Start SQL Apply on logical standby
Thanks all for your input.
The initialization parameters are not supposed to change while bouncing the database except in one case, that is if the modification was only for currently running instance(SCOPE=MEMORY).
The following are the steps to modify initialization parameters using Enterprise Manager.
To modify initialization parameters for the currently running instance, and ...
If you can see the backup file in the directory, try cataloging it:
RMAN> catalog starts with '/path/to/archive/directory';
It will list the backup and ask you if you want to catalog it.
Following which you should be able to continue with your gap recovery:
alter database recover managed standby database cancel;
recover standby database;
#after all ...
Can standby database of a non-container database be pluggable or vice versa?
In order to plugin a non-CDB standby database into a CDB, the non-CDB standby database needs to be of version 12c as well. So existing non-CDB databases will need to be upgraded to 12c before they can be part of a 12c CDB.
Suppose there are 2 CDBs on 2 different server. And one ...
First you need to make sure that the copied database is a standby database. That is not the case in your case. Use duplicate to do that is the easiest way.
Is it possble at all using a not connected database .... yes, but why? To me it looks like a waste of money if there is no decent connectivity.
Restore/open failed because your copy database feels it ...
My procedures seem valid... I was able to test the logical DB, then bring it back into an exact copy Logical Standby and re-enable SQL Apply without issues.
However, there was a minor change to my procedures: flashback database requires that the DB is in mount state and that alter database open requires resetlogs or noresetlogs.
Therefore, the amended ...
Why is it that for non-real time apply from cascading to cascaded standby that we have to mention as SYNC as the redo transport mode?
Whether the Real-Time cascade feature is used or not, actually it depends on the attributes in the parameter LOG_ARCHIVE_DEST_n of the cascading standby that control how the redo stream is forwarded to the cascaded database. ...
NOAFFIRM means the redo transport will be acknowledged before writing the received redo to disk (standby redo logs).
ASYNC noaffirm means the log transfer method is ARCH right?
No, it does not. Without specifying LGWR or ARCH, LGWR is the default. You can check it on the primary database by:
select archiver from v$archive_dest where dest_id = 5;
You can check some options like checking FAL_SERVER parameter, LOG_ARCHIVE_DEST_n parameters, Dataguard Broker, Recovery Catalog, Cloud Control, etc.. if they are used, but none of them are mandatory for a DataGuard configuration.
In fact, the standby nodes doesn't need to send any kind of information to the Primary db at all. Since the heartbeat is ...
At first glance, in MOS there's a related known bug with that message in 18.104.22.168 on Solaris (Bug 10331312) and 22.214.171.124 on Linux x86-64 (Bug 14016842 , this one refilled for review) both referenced by Doc Id 1308804.1.
However it doesn't provides any source of cause. As workaround they recommend to disable the log_archive_trace parameter to = 0 (default), ...
The message indicates that no archivelog exists with this sequence in the current incarnation.
Failover starts a new incarnation, and log sequences start from 1 again. Let's say your database is at sequence 10 now, and the log sequence was 159 before the failover. V$ARCHIVED_LOG at this point still contains entries about previous incarnation, so the above ...
Without opening the standby for read-only, you won't be able to identify specific changes to specific physical objects, instead you'll have to verify that a specific set of changes have been applied to the remote standby. Views including v$standby_apply_snapshot, v$archived_log, v$archive_gap, v$dataguard_stats, v$managed_standby are all ones that I use on a ...