Reg Creating Physical Standby Control File - Data Guard

Hi,
I am trying to create a physical standby in the same server in a different partition.
I have copied the home and changed the init.ora file.
I have created listeners.
I did creating standby Control file Using
alter database create standby controlfile as '/some/path/to/a/file'
Then i copied the datafiles from primary to standby and when i tried to mount the database it gives error
RACLE instance started.
Total System Global Area 285212672 bytes
Fixed Size 1267044 bytes
Variable Size 88083100 bytes
Database Buffers 188743680 bytes
Redo Buffers 7118848 bytes
ORA-01103: database name 'WMSTDBY' in control file is not 'WMTEST'
My Primary Sid is WMSTDBY
My Standby SId is WMTEST.
Please help in this regard.
Krishna.V.V 

You cannot change the DB_NAME of the standby. It has to be the same as the Primary. You can change (and should) the INSTANCE_NAME (SID) and the DB_UNIQUE_NAME parameters to WMTEST.
Larry

Related

managing dbs with same names on different hosts in GC 10.2.0.3

I saw this post: Ideas needed - monitoring same DBName in manual standby
But my issue is we have an environment that keeps the same db names for production, development, uat etc... Dbs are 10.2.0.3 on Solaris 10. GC is 10.2.0.3 on windows.
e.g. i have a cluster database HRMS, running on two nodes. On another server, i have a standalone instance HRMS and Grid Control was able to detect it. Weird, it looked like it didn't care about the same name here (may be there is a difference between a database instance and a cluster instance). However, if i were to discover another target on another node, it will complain saying there is another instance. I have used the workaround to manually add it as say HRMS_hostname. All is good.
I'm curious though as to how when you create a standby database using GC, it creates a different unique name. (DB_UNIQUE_NAME). The latter seems to be the solution in having dbs with the same name in GC with different db_unique_name parameter. However, this parameter is not modifiable.
Comments anyone?
Thanks. 
I think this is OK between the Cluster and Standalone because the nodes have different instance names from the standalone one which is what GC is interested in.
I think you can change the db_unique_name, but the impact is what you need to find out.
Meanwhile, Oracle 11g allows you to use RMAN to change the db_unique_name of a Standby database using the CHANGE after changing in init parameter.Oracle® 11g Database Hints 
Try this and rediscover the database in GC and see what you get.
C:\>sqlplus /nolog
SQL*Plus: Release 10.2.0.2.0 - Production on Thu Oct 25 10:34:56 2007
Copyright (c) 1982, 2005, Oracle.  All Rights Reserved.
SQL> connect /as sysdba
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area  130023424 bytes
Fixed Size                  1288148 bytes
Variable Size              88082476 bytes
Database Buffers           37748736 bytes
Redo Buffers                2904064 bytes
Database mounted.
SQL> show parameters unique
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_unique_name                       string      testdb
SQL> alter system set db_unique_name=testdbq scope=spfile;
System altered.
SQL> startup force
ORACLE instance started.
Total System Global Area  130023424 bytes
Fixed Size                  1288148 bytes
Variable Size              88082476 bytes
Database Buffers           37748736 bytes
Redo Buffers                2904064 bytes
Database mounted.
Database opened.
SQL> show parameters unique
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_unique_name                       string      TESTDBQ
SQL>Note: I used startup force to restart my test database quickly. Do not do it on your database. Do a shutdown immediate followed by startup 
interesting...it looks like you were able to change your DB_UNIQUE_NAME...the doco for 10g says it's not modifiable.
Thanks, i'll do some testing. 
I think it may be referring to not dynamically modifiable 9i.e you cannot modify it without SPFILE scope.
When you go into Initialisation Parameter in EM, you will notice that the field for DB_UNIQUE_NAME is presented for update in the SPFILE tab. Which means it can be changed. 
Just to confirm that i was able to modify DB_UNIQUE_NAME. It looks like everything is working ok.
Thanks!

activating standby database

We have an old 7.3.4 database with a standby database on a different machine, both running under sco 5.7
while activating standby database after processing all the available logs I get the following message:
***************************************************
SVRMGR> connect internal
Connected to an idle instance.
SVRMGR> startup nomount
ORACLE instance started.
Total System Global Area 587389820 bytes
Fixed Size 41880 bytes
Variable Size 62896100 bytes
Database Buffers 524288000 bytes
Redo Buffers 163840 bytes
SVRMGR> alter database mount standby database;
Statement processed.
SVRMGR> alter database activate standby database;
alter database activate standby database
*
ORA-01194: file 2 needs more recovery to be consistent
ORA-01110: data file 2: '/usr/oracle7/dbs/rbs01.dbf'
SVRMGR> exit
Server Manager complete.
**************************************************************
Does anyone remember what this refers to.
Thanks
ZG 
It is embarrassing to be so old. More so to not really remember the answer to the question. So here's to faking it.
rbs01.dbf is a tablespace containing rollback segments.
It seems Oracle is convinced that you shut it down rather shabbily and it is looking for, I am going to guess, some resource from which it can perform a recovery.
What to do with something this archaic? I'd take a hammer to it. My guess would be that I'd drop the tablespace and create a new one with new rollback segments. But this is just a guess so my recommendation would be to not do what I am suggesting unless you can independently confirm that it is the solution.
Perhaps someone else can give you a more useful answer.
While you are waiting you might want to contemplate the value in using a version of the product supported during the current millennium.

Standby issue

Hi guys!
I have done this test :
I have installed ORACLE on two servers and use disks from EVA storage.
I have installed db on TEST1 server and put redologs and database files on EVA disks. Then while database is working we have unmount disks and mount on second server.
Then i have recreated controlfiles and tried to startup database on it by doing this
SQL> conn / as sysdba
Connected to an idle instance.
SQL> #/db/create_orah.sql
ORACLE instance started.
Total System Global Area 236000320 bytes
Fixed Size 451648 bytes
Variable Size 201326592 bytes
Database Buffers 33554432 bytes
Redo Buffers 667648 bytes
Control file created.
SQL> select open_mode from v$database;
OPEN_MODE
----------
MOUNTED
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/a0765/db/orah/system01.dbf'
So this means that i need to have archive logs also or something else?
Please give me some detailed pointers how to manage this...
Thank you! 
I have found mistake it isnt in archiove log mode...

Is it possible to create Redo logs and UNDO from Mount state ?

Oracle RDBMS Version: 11.2.0.2
Platform : AIX 6.1
Is it possible to create Redo logs and UNDO tablespace from Mount state? We are planning to Single instance to RAC migration.
ML Note : +How to Convert 10g Single-Instance database to 10g RAC using Manual Conversion procedure [ID 747457.1]+
In the above ML Note, from Instance1 which is MOUNT state, they are creating Redo logs and UNDO tablespace for Instance2.
After this , they are starting Instance1 using ALTER DATABASE OPEN
So, I was just curious if it is possible create Redo logs and UNDO Tbs from Mount state. 
Look at a create database script as an example, which does or can do both of those steps while in nomount, plus you know it can be done while the database is open (create a new undo TS or redo group), so yes. 
Yes, the DB creation script execution. Just didn't think of that.
Here only Instance1 is created. There is nothing there in Node2 to bring up Instance2. Ability to create redo log files and UNDO tablespace for an instance which is yet to created from another instance(Instance1 in Node1) which is in Mount state is interesting . 
You may want to see if you can create a tablespace, undo or otherwise, while in mount mode. 
You may want to see if you can create a tablespace, undo or otherwise, while in mount modeYou shouldn't be able to.
SQL> startup mount
ORACLE instance started.
Total System Global Area  419430400 bytes
Fixed Size                  1261164 bytes
Variable Size             113246612 bytes
Database Buffers          297795584 bytes
Redo Buffers                7127040 bytes
Database mounted.
SQL> create tablespace xtra;
create tablespace xtra
*
ERROR at line 1:
ORA-01109: database not open
SQL> create undo tablespace undotbs2;
create undo tablespace undotbs2
*
ERROR at line 1:
ORA-01109: database not open
SQL>Hemant K Chitale

Primary RAC to Physical Standby

Hi All,        We are planning to configure Physical standby for our RAC database. Can anyone let us know how to config in case of RAC database? Also after configuring standby with max protection mode is it possible to change physical standby to Snapshot standby for our app team testing purpose? Rds,Varun
Hello Varun,I recently set up an environment of two RAC nodes to a Data Guard environment is only one node. Nothing very special when configuring Data Guard in a RAC environment. The most important thing is that each instance RAC must send to the BD archivers standby.This is configured the archiver destination to the standby database. Once the archivers reach the Data Guard environment are applied correctly and consistently to the Standby BD.You have this MOS note that help to the creation process.Creating a Standby using RMAN Duplicate (RAC or Non-RAC) (Doc ID 1617946.1)Yes, you can convert the Standby database to a snapshot BD, that support read/write operations.Use the command, alter database convert to snapshot standby;And when apps people finish the test, convert to standby with the command:Alter database convert to physical standby;And the standby back to the standby role, and if you turn on the automatic recovery apply all the redo pending to apply since you put the standby database in snapshot mode.Is very powerful and easy.I hope help.best regardsArturo
Thanks Arturo for a quick reply.. We are planning to configure DG with max protection mode. As per my understanding In this case converting physical standby to snapshot mode makes standby unavailable with primary and primary may go into hung state as it is in MAX Protection mode. Please clarify. Rds,Varun
Varun Rajesh wrote:
 
Thanks Arturo for a quick reply.. We are planning to configure DG with max protection mode. As per my understanding In this case converting physical standby to snapshot mode makes standby unavailable with primary and primary may go into hung state as it is in MAX Protection mode. Please clarify.
 
Rds,
Varun
 I agree what you said, If you have maximum protection mode then you cannot change standby to snapshot standby. Because every commit transaction has to be written at least on standby database for confirmation (application). So you must have more than one standby database.. in that case it should work.  Thanks. 
Hello,Although what the user has answered CKPT, has much logic, I decided to try what you commented. I set this on my primary Database a standby destination. alter system setlog_archive_dest_3='SERVICE=london2 SYNC REOPEN=15 valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=london2' scope=both;London2 is a Physical Standby Database created with Duplicate command.I change the protecction model from default to máximum protecction.ALTER DATABASE SET STANDBY DATABASE TO maximize protection; ERROR at line 1:ORA-01126: database must be mounted in this instance and not open in any instance shutdown immediate;SQL>startup mountSQL> ALTER DATABASE SET STANDBY DATABASE TO maximize protection;   Database altered.SQL> select PROTECTION_MODE,PROTECTION_level from v$database ;PROTECTION_MODE      PROTECTION_LEVEL-------------------- --------------------MAXIMUM PROTECTION   MAXIMUM PROTECTION My standby database is in recovery mode using real time apply.If I try SQL> shutdown immediateORA-01154: database busy. Open, close, mount, and dismount not allowed now Then If i run a shutdown abort. And try a transacction at primary database: 1* insert into emp select * from emp54784 rows created.Commit; ----> here appear the hung, because the standby is closedAt the alter file appear:LGWR: Error 1034 attaching to RFS for reconnect Thu May 07 00:58:03 2015Error 1034 received logging on to the standbyThu May 07 00:58:04 2015LGWR: Error 1034 attaching to RFS for reconnecOK. Until here is the expected behavior. Now , I startup the standby database and the commit, run. Now I convert the physical standby database to snapshot database:1. cancel the recovery2. SQL> alter database convert to snapshot standby;Database altered.SQL> select database_role from v$database;DATABASE_ROLE----------------SNAPSHOT STANDBY And the primary database is working fine.The alert log show:LGWR: Attempting destination LOG_ARCHIVE_DEST_3 network reconnect (3113)LGWR: Error 1041 disconnecting from destination LOG_ARCHIVE_DEST_3 standby host 'london2'LGWR: RFS network connection re-established at host 'london2'LGWR: Standby redo logfile selected to archive thread 1 sequence 53LGWR: Standby redo logfile selected for thread 1 sequence 53 for destination LOG_ARCHIVE_DEST_3LGWR: RFS destination opened for reconnect at host 'london2' So the standby BD still receive the redo stream and creating archivers that will be applied when the snapshot standby again be standby. So the availability in primary BD unaffected.These tests are performed with Oracle  12.1.0.1.0 on Linux-12c. BACK TO STANDBY STATE.SQL>  select open_mode from v$database;OPEN_MODE--------------------READ WRITESQL> alter database close;Database altered.SQL> alter database convert to physical standby;Database altered.SQL>  select open_mode from v$database;OPEN_MODE--------------------MOUNTEDSQL> select database_role from v$database;DATABASE_ROLE----------------PHYSICAL STANDBYSQL> alter database open; ------> Here the Primary Hung is any run a COMMIT;alter database open*ERROR at line 1:ORA-01092: ORACLE instance terminated. Disconnection forcedORA-00704: bootstrap process failureORA-00705: inconsistent state during start up; shut down the instance, thenrestart itProcess ID: 7244Session ID: 1 Serial number: 41SQL> shutdown immediate ORA-24324: service handle not initializedORA-01041: internal error. hostdef extension doesn't existSQL> Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit ProductionWith the Partitioning, OLAP, Advanced Analytics and Real Application Testing options[oracle#host03 2015_05_07]$ serverSQL*Plus: Release 12.1.0.1.0 Production on Thu May 7 01:23:54 2015Copyright (c) 1982, 2013, Oracle.  All rights reserved.Connected to an idle instance.   SQL> startupORACLE instance started.Total System Global Area 1503199232 bytesFixed Size                  2288584 bytesVariable Size             973079608 bytesDatabase Buffers          520093696 bytesRedo Buffers                7737344 bytesDatabase mounted.     ----> The primary is opertive.Database opened.      Then, with these tests, we could say that the conversion of STANDBY to SNAPSHOT is online without loss of service in the Primary database, but around SNAPSHOT to Standby, requires a stop / start the standby instance and then we would have no availability commit in the primary.I think that if your BD have maintenance windows you could leverage for change.I hope help.Regards.Arturo
Thanks for your test.Can you tell me how many standby databases do you have when you perform this test? If you involved snapshot standby database and Maximum protection and it is not allowed. This is thumb rule.When i have time i will do test, but am sure.. because when the commit occurs if the transaction unable to write on standby then primary will be aborted.. in that case where is availability of production database?  So when having 2 or more standby databases then we can take chance. Thanks.

Categories

Resources