If you’re like me, you tend to brush off concerns of compatibility between Oracle Client and Server versions.  After all, SQL*Plus hasn’t changed much in the last 15-20 years, and I’ve gotten used to being able to connect to pretty much any database server version with any version of it.  While that may be true, some of the newer client tools are version specific.  RMAN 11g won’t back up a 10g database (though oddly RMAN 10g will back up an 11g database).  The tool that really takes the cake is DGMGRL.  Performing normal operations like manipulating the DataGuard Broker Configuration is possible with a variety of versions, but starting an observer for Fast Start Failover is extremely version specific.  I recently tried to start an observer for an 11.2.0.4 database using 11.2.0.1 client, and failed due to version incompatibility.
DGMGRL for 64-bit Windows: Version 11.2.0.1.0 - 64bit Production
 
Copyright (c) 2000, 2009, Oracle. All rights reserved.
 
Welcom to DGMGRL, type "help" for information.
Connected.
Corrupted document
<FAST_START_FAILOVER enabled="yes" MIV="11" OBID="9383" threshold="180" obsv_recn="0" auto-reinstate="yes"><PRIMARY name="ATLANTA">ATLANTA</PRIMARY><STANDBY name="BOSTON">BOSTON</STANDBY></FAST_START_FAILOVER>
Error: LPX-00106: Warning: attribute "obsv_recn" of element "FAST_START_FAILOVER" is undefined
Error: ORA-16591: unknown field "obsv_recn" in document
Error: ORA-16593: XML conversion failed
 
Failed.
Upgrading the client to 11.2.0.4 eliminated the error, but I was surprized at how picky DGMGRL was about the version.  Certainly, Oracle should have anticipated that there might just be companies that upgrade their databases over time.  What are you supposed to do during the upgrade process?  Disable Fast Start Failover?  Install every possible version of the client on your observer box?
DGMGRL for 64-bit Windows: Version 11.2.0.4.0 - 64bit Production
 
Copyright (c) 2000, 2009, Oracle. All rights reserved.
 
Welcom to DGMGRL, type "help" for information.
Connected.
Observer Started.
There is almost no documentation on this error on the web or Oracle Support, but it’s obvious that the fsfo.dat and/or DG_BROKER_CONFIG_FILEn are storing their configuration data in XML, and it’s failing validation because the two versions have differing ideas on what attributes the XML should contain.  Now, clearly Oracle should have dealt with this more gracefully, but it is one more example of how the idea that XML is “self documenting” or appropriate for either data exchange or storage is just not true.  The same level of validating inputs and managing backwards compatibility along with intellegent error handling are required regardless of how you store or pass data.  The Oracle developer who coded this module clearly didn’t do their job well and XML didn’t automagically fix that.
Share This