The Dutch Prutser's Blog

By: Harald van Breederode

  • Disclaimer

    The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
  • Subscribe

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 242 other followers

Archive for February, 2009

A new sounding look and feel

Posted by Harald van Breederode on February 25, 2009

As you probably have noticed I switched to a new look and feel for this blog, and I like to take the opportunity to say something about the reasons behind this change. Soon after I posted A misleading ORA-16047 people notified me that the alert.log contents and the code examples were overlapping with the sidebar at the right side of the screen. Because everything felt alright on my Braille display I didn’t noticed this myself at post time. Before this incident I noticed myself though, that the sidebar didn’t show up when entering my blog via the RSS feed.

So it was about time for a new look and feel for my blog, which is called a theme. But how does one judge the layout of a new theme being blind? With the patient assistance of a few friends I selected something that still looks nice, whatever that means, without the same problems of the original theme.

However soon after activating the new theme I discovered that it was much harder for me to find my most recent post. In order to understand this you need to know a little about how a blind person is able to surf over the Internet. Blind computer users are using a piece of Assistive technology called a screen reader. As its name implies, a screen reader reads the information from the computer screen out aloud or place it on a Braille display. In my case I am using the JAWS for Windows screen reader. JAWS has a feature called Quick Navigation Keys which allows me to quickly jump to a specific location on the screen, such as a button, an edit field or a heading. On Surfing the Internet with JAWS you can find more information about how JAWS helps me using the web.

The quick navigation key I use most is the one which moves me from one heading to another, which is a very convenient way of moving around on a well structured web page. On the old theme the most recent posting was three headings down from the top of the page and I could go there by three keystrokes. On the new theme however the most recent posting is twelve headings down and performing twelve keystrokes is no longer convenient. This behavior is caused by the fact that on the old theme the postings are located before the static section of the page, whilst on the new theme the postings are located behind the static section of the page. Immediately after activating this new theme my blind visitors started complaining about this.

This brought me into a moral dilemma: Do I choose for my blind visitors or do I choose for my poor sighted visitors? ;-) I have decided to go for the sighted visitors by offering them a nice look and feel, but I tried to help the blind as well by adding a tip on how to quickly jump to the most recent posting. Hopefully the sighted visitors understand that this has to be a two sided road and I expect that they build accessible web pages for the blind in return!

I like to thank Nienke, Eric, Lyon and Richard for their patience and feedback during my journey in finding an acceptable compromise between something that looks nice and is still accessible. Hopefully you like this new theme, but suggestions for further improvements are always welcome.
-Harald

Posted in Accessibility | 3 Comments »

Unmasking Your IP Addresses

Posted by Harald van Breederode on February 24, 2009

In the January edition of the Oracle University Newsletter Joel Goodman and I published an article about how we think the DBA role will evolve in the future. In this well received article we also discuss how one can upgrade from a DBA 1.0 to a DBA 2.0 skill set. For the March edition I wrote a follow-up article named “Unmasking your IP Addresses” which discuss the network skills required to maintain IP based Oracle Clusterware interconnects.

Here is the Unmasking your IP Addresses article.

Enjoy reading it.
-Harald

Posted in Linux, Oracle | 2 Comments »

A misleading ORA-16047

Posted by Harald van Breederode on February 19, 2009

The problem

Last week I was teaching a Data Guard course and ran a demo how to setup a physical standby database on a Real Application Clusters (RAC) database. Normally all my demos run smoothly but not this time. First I received an ORA-16052 error:

SQL> alter system set log_archive_dest_2
  2  = 'SERVICE=tutor1d_nledu02 LGWR SYNC AFFIRM';
alter system set log_archive_dest_2
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-16052: DB_UNIQUE_NAME attribute is required 

The error message seemed pretty clear and was quickly corrected:

SQL> alter system set log_archive_dest_2
  2  = 'SERVICE=tutor1d_nledu02 LGWR SYNC AFFIRM db_unique_name=tutor1d_nledu02';

System altered.

Note: Nothing was changed on my demo environment except upgrading from 11.1.0.6.0 to 11.1.0.7.0 But that isn’t considered a change is it?

Secondly by the time the standby should receive redo from the primary nothing happened. No matter how often I switched redo logs on the primary, the standby did not receive a single redo log entry. Looking in the alert.log on the standby showed:

Sun Feb 15 16:22:57 2009
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 25545
RFS[1]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
RFS LogMiner: Client disabled from further notification

This seems to indicate that the primary database connects successfully to the standby and redo should come in. Looking in the alert.log on the primary however revealed:

Sun Feb 15 16:22:50 2009
ALTER SYSTEM SET log_archive_dest_2='SERVICE=tutor1d_nledu02 LGWR SYNC AFFIRM db_unique_name=tutor1d_nledu02' SCOPE=BOTH;
Sun Feb 15 16:22:53 2009
******************************************************************
LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
******************************************************************
Sun Feb 15 16:22:54 2009
LNSb started with pid=41, OS id=5228 
Errors in file /home/tutor1d/diag/rdbms/tutor1d/tutor1d1/trace/tutor1d1_lgwr_30073.trc:
ORA-16047: DGID mismatch between destination setting and standby
LGWR: Error 16047 creating archivelog file 'tutor1d_nledu02'
LGWR: Failed to archive log 2 thread 1 sequence 35 (16047)
Thread 1 advanced to log sequence 35 (LGWR switch)
  Current log# 2 seq# 35 mem# 0: /sd01/oradata/TUTOR1D/onlinelog/o1_mf_2__bbb38e65.log
Thread 1 cannot allocate new log, sequence 36
Checkpoint not complete
  Current log# 2 seq# 35 mem# 0: /sd01/oradata/TUTOR1D/onlinelog/o1_mf_2__bbb38e65.log
Sun Feb 15 16:23:02 2009
ARC0: Archivelog destination LOG_ARCHIVE_DEST_2 disabled: Data Guard configuration identifier mismatch

Thus the standby tells me that the primary connected successfully whilst the primary tells me it can not connect to the standby due to an ORA-16047 error. Here is the description of an ORA-16047:

$ oerr ora 16047
16047, 00000, "DGID mismatch between destination setting and standby"
// *Cause:  The DB_UNIQUE_NAME specified for the destination does not match
//          the DB_UNIQUE_NAME at the destination.
// *Action: Make sure the DB_UNIQUE_NAME specified in the LOG_ARCHIVE_DEST_n
//          parameter defined for the destination matches the DB_UNIQUE_NAME
//          parameter defined at the destination.

You already saw that I specified tutor1d_nledu02 as the DB_UNIQUE_NAME for LOG_ARCHIVE_DEST_2 and here is the prove that my standby database has indeed the correct DB_UNIQUE_NAME.

SQL> select db_unique_name from v$database;

DB_UNIQUE_NAME                                                                  
------------------------------                                                  
tutor1d_nledu02                                                                 

The solution

As you can imagine I was completely puzzled by this conflicting information and having students awaiting your actions doesn’t give you much time for troubleshooting. So I decided to continue my demo and see what would happen if the Data Guard Broker was given controll over my setup. Much to my surprise redo started to flow once the broker was in charge! My first reaction was “What can the broker do what I can’t?” I did not have time to figure this out during class but I did during the weekend following.

The good news is that I was able to reproduce it but I still could not get redo flowing myself. I re-created my RAC database and suddenly my demo worked fine. The joy was only short because the second time I ran the demo the same problem showed up again. This led to the conclusion that it was probably database parameter related and peeking in the RAC spfile revealed that log_archive_config was configured. I did not set it when I re-created my RAC database nor did I set it in my demo. .It turned out that it was set by the broker and that I did not clean things up after running the demo. Thus all I had to do was setup log_archive_config in my demo to fix it permanently.

SQL> alter system set log_archive_config
  2  = 'dg_config=(tutor1d,tutor1d_nledu02)';

System altered.

Had I paid more attention to the first ORA-16052 error it would have safe me a lot of time, because the error description is pretty clear:

$ oerr ora 16052
16052, 00000, "DB_UNIQUE_NAME attribute is required"
// *Cause:  The DB_UNIQUE_NAME attribute is required when DG_CONFIG is enabled.
// *Action: Use the DB_UNIQUE_NAME attribute to specify a valid Data Guard
//          Name for the destination.  The list of valid DB_UNIQUE_NAMEs can
//          be seen with the V$DATAGUARD_CONFIG view.

Conclusion

Sometimes things are not what they seems! In this case the primary database tried to connect to the standby database to verify its DB_UNIQUE_NAME. But the missing log_archive_config parameter on the standby database prevented the primary from logging in. Resulting in a misleading ORA-16047.

In order to prevent lengthy troubleshooting sessions one should either look error messages up or use the Data Guard Broker ;-)
-Harald

Posted in Oracle | 9 Comments »

 
Follow

Get every new post delivered to your Inbox.

Join 242 other followers