Home » Server Options » Data Guard » Can Oracle Agent still control my DataGuard log_archive_dest setting after I uninstalled it?
Can Oracle Agent still control my DataGuard log_archive_dest setting after I uninstalled it? [message #191529] |
Wed, 06 September 2006 23:20 ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
deecaywonder
Messages: 2 Registered: September 2006
|
Junior Member |
|
|
The log_archive_dest setting kept revert back the one which was set by Grid Control, no matter how many times we tried to get rid of it. What is going on?
It's actually a long story, but let me try to make it as brief as possible:
We manually setup DataGuard on our Oracle 10.2g production databases. It's a physical standby setting, with one primary database on a DELL Xeon server running Microsoft windows Server 2003, and the standby database on another DELL Xeon server with exact the same setting.
All went well until one day we decided to give Oracle Grid Contrl 10.2g for Microsoft Windows a try. We simply want to use Grid Control as a monitoring and health checking tool, so that our support staff can check the status of the DataGuard using the web based EM. However, after we installed Oracle Agent on both Primary and Standby machines, and then used the EM web site to access the DataGuard page, it insisted in creating a StandBy database for us in order to proceed. (Notice that our production server was using spfile. We test EM with a testing Oracle 10.2g database server which use pfile. During that test trial, EM simply provided DataGuard monitoring feature without forcing us to create a standby). We were so brave that we went ahead and ALLOW Grid Control to create a Standby database just to see what would happen (BAD IDEA). Fortunately, later the system seemed hanging on creating the Standby database (we later suspected that it was because the StandBY database was already done by us manually, and thus when Grid Control tried to do it, it couldn't access that standby database under mount mode), and we had no choice but aborted the process 3 hours later.
A week later, we found out that our manually created DataGuard stopped working ever since the Grid Control advneture. We then realized that after the day we tried Grid Control, the
log_archive_dest_2 value changed from:
SERVICE=deela2 LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=deela2
To:
service=" (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=deela2)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=deela2_XPT)(INSTANCE_NAME=dee la)(SERVER=dedicated))) "',' LGWR SYNC AFFIRM delay=0 OPTIONAL max_failure=0 max_connections=1 reopen=300 db_unique_name="deela2" register net_timeout=180 valid_for=(online_logfile,primary_role)
In order to make our previously mnaually created DataGuard working again, and still be able to use Grid Control to monitor DataGuard (by switch from spfile to use pfile), I did the following:
(1) Uninstall Oracle Agent
(2) REmove all spfiles from the system.
(3) In the pfile (initdeela.ora), make sure log_archive_dest_2 is set as "SERVICE=deela2 LGWR SYNC AFFIRM ...."
(4) SHUTDOWN IMMEDIATE, and then START OPEN to Primary databse
I use "show parameter" to check
log_archive_dest_2, and found that the value was indeed correct.
The strange thing happned a day after when I found out that the
log_archive_dest_2 value was reverted back to the "(DESCRIPTION=(ADDRESS_LIST=(ADDRESS ..." thing! We knew that a ArcServe Oracle cold backup was done. That means a reboot on Oracle service was invovled. But how come a cold reboot on Oracle server causing the parameters to rollback? And where did those "incorrect" log_archive_dest_2 parameter value came from?
Please correct if I am wrong: if a Oracle database doesn't see any spfile, but only see a pfile (C:\Oracle\product\10.2.0\db_1\database\initdeela.ora), it will use that pfile to start up the Oracle memory Instance, right? How come log_archive_dest_2 got rolled back to the old setting? I checked the database content and contains new record, so it's not some backup rollback thing.
Any insight? Is there anything that can modify the system parameters besides pfile and spfile? And I already uninstalled the Oracle agent, so the Gird Control shouldn't be able to modify the parameters again, right?
Any suggestions and comments are welcomed. I just need some second opinion after pulling some of my hairs off.
Thanks.
Deecay
|
|
|
Re: Can Oracle Agent still control my DataGuard log_archive_dest setting after I uninstalled it? [message #192017 is a reply to message #191529] |
Sat, 09 September 2006 14:51 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
oigor
Messages: 8 Registered: September 2006 Location: Athens, GREECE
|
Junior Member |
|
|
Hi,
Most likely your SPFILE survived.
Why do you say "remove all spfiles"? How many of them you have?
It should be that you have only one spfile.
Try this on the primary database:
1)
2) delete spfile on the file system
3) Check your PFILE and see if there is any SPFILE='/some/folder/spSID.ora'. If there is such parameter, then your PFILE is ignored. In that case comment out SPFILE parmeter. If there is no such parameter, proceed to the next step.
4) Set proper log_archive_dest_2 parameter in your PFILE
5) STARTUP PFILE='/some/folder/initSID.ora'
6)Execute this statement in SQL*Plus:
CREATE SPFILE FROM PFILE='STARTUP PFILE='/some/folder/initSID.ora';
7) ALTER SYSTEM SWITCH LOGFILE;
Then connect to the standby database, and see if the log transfer is progressing:
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME
FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
Check the files in the folders of both servers too.
----------
Igor Obradovic
|
|
|
|
Re: Can Oracle Agent still control my DataGuard log_archive_dest setting after I uninstalled it? [message #192851 is a reply to message #192018] |
Wed, 13 September 2006 22:26 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
deecaywonder
Messages: 2 Registered: September 2006
|
Junior Member |
|
|
It's been almost 2 weeks and I am still fighting with this strange DataGuard related Oracle pfile/spfile problem. And today I found something new, something strange.
To put a long story short, the parameter "log_archive_dest_2" was ALWAYS being modified after the Oracle got restarted (we have a .bat file that calls a .sql file scheduled to be run each night at 11:00 pm). No matter I use pfile or spfile. The result is the same: SOMETHING will alter the log_archive_dest_2 with the strange Grid Control related reference.
Last night I did something like this:
- I changed the nightly restart script so that it explicitly start using a pfile.
- In the pfile, I :
>> changed the log_archive_dest_2 entry to: *.log_archive_dest_2=''
>> Add an entry: *.log_archive_dest_4='SERVICE=deela2 LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=deela2 '
So to recap, here's the BEFORE pfile:
.....
*.log_archive_dest_1='LOCATION=E:\DEELA_DB\arch\deela VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=deela1'
*.log_archive_dest_2='SERVICE=deela2 LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=deela2
'*.log_archive_dest_3='LOCATION=D:\DEELA_DB\arch\deela'
....
Here's the AFTER pfile:
....
*.log_archive_dest_1='LOCATION=E:\DEELA_DB\arch\deela VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=deela1'
*.log_archive_dest_2=''
*.log_archive_dest_3='LOCATION=D:\DEELA_DB\arch\deela'
*.log_archive_dest_4='SERVICE=deela2 LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=deela2 '
.....
My attempt was trying to workaround the problem. If some mysterious process continues messing my log_archive_dest_2 after restart the database, at least I still have log_archive_dest_4 doing the job. I tested, Oracle will perform all archive file copying for all Log Archive Destination entries. So I though it should have the problem solved.
So this morning when I got back to work, I check the system using show parameter and was shocked to found out that:
- log_archive_dest_2 stays BLANK as in the pfile.
- But log_archive_dest_4 was turned into 'service=" (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=tcp)(HOST=DEELA2)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=deela_XPT)(INSTANCE_NAME=deel a)(SERVER=dedicated))) "',' LGWR SYNC AFFIRM delay=0 OPTIONAL max_failure=0 max_connections=1 reopen=300 db_unique_name="deela2" register net_timeout=180 valid_for=(online_logfile,primary_role)'
I was like ******** !!!!!!!!!!!!
So it seems like something explicitly CHASE the DataGuard standby machine entry (SERVICE=deela2 LGWR ....) and change it to the Grid Control crazy setting (service="(DESCRIPTION=(ADDRESS_L ....). like a missile with target locked!
I am like .... pretty clueless now.
Any comment?
Deecay
|
|
|
|
|
Goto Forum:
Current Time: Sat Sep 07 23:45:49 CDT 2024
|