However, although the copy vm booted nicely, it somehow lost its network settings such that eth0 failed to come up. At a first glance, i supposed that having two vm’s of the same environment (excluding the disk location) might puzzle vmware player such that i shutdown the copy vm, renamed the original vm disk location and removed the original vm from the vmware player library entry by offer. On retry, i found the same result, eth0 not coming up.

There are other approaches, in fact, but without boring anyone out there to immediate sleep the following steps did work for me eventually:

1. Shutdown this running vm (environment) cleanly
2. Close vmware player (iff not self-closed)
3. Copy, don’t move for backup reasons, this vm top directory (usually the vm name) to the new location
4. Start vmware player again
5. Open the settings of this vm, go to the options tab and change the general setting called working directory to point to the new location
6. Close the settings of this vm by save
7. Launch this vm as usual

have fun!

channel ORA_DISK_2: backup set complete, elapsed time: 02:57:02
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup plus archivelog command at 01/01/2012 05:17:04

RMAN-03009: failure of backup command on ORA_DISK_2 channel at 01/01/2012 02:20:02
ORA-19566: exceeded limit of 0 corrupt blocks for file H:\ORACLE\SAN_3\ORADATA\WAZ\TEXT\TEXT_DATIDX_05.DBF

Executing dbv against it proved the assumption of rman.

DBVERIFY: Release 10.2.0.4.0 - Production on Tue Jan 3 11:43:56 2012
Copyright (c) 1982, 2007, Oracle.  All rights reserved.

DBVERIFY - Verification starting : FILE = H:\ORACLE\SAN_3\ORADATA\WAZ\TEXT\TEXT_DATIDX_05.DBF
Page 261345 is marked corrupt
Corrupt block relative dba: 0x1a83fce1 (file 106, block 261345)
Bad header found during dbv:
Data in bad block:
 type: 40 format: 2 rdba: 0x16c3fce1
 last change scn: 0x000a.2b57e527 seq: 0x2 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0xe5272802
 check value in block header: 0x16f2
 computed block checksum: 0x0

Page 261408 is marked corrupt
Corrupt block relative dba: 0x1a83fd20 (file 106, block 261408)
Bad header found during dbv:
Data in bad block:
 type: 40 format: 2 rdba: 0x16c3fd20
 last change scn: 0x000a.2b58ef29 seq: 0x2 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0xef292802
 check value in block header: 0xa93d
 computed block checksum: 0x0

Page 261420 is marked corrupt
Corrupt block relative dba: 0x1a83fd2c (file 106, block 261420)
Bad header found during dbv:
Data in bad block:
 type: 40 format: 2 rdba: 0x16c3fd2c
 last change scn: 0x000a.2b58ef29 seq: 0x2 flg: 0x04
 spare1: 0x0 spare2: 0x0 spare3: 0x0
 consistency value in tail: 0xef292802
 check value in block header: 0xb930
 computed block checksum: 0x0

DBVERIFY - Verification complete

Total Pages Examined         : 262144
Total Pages Processed (Data) : 0
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 257948
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 2254
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 1939
Total Pages Marked Corrupt   : 3
Total Pages Influx           : 0
Highest block SCN            : 1084849528 (10.1084849528)

However, trying a block recovery by rman eventually delivered no results (after running for hours unpacking any available backup set) because the blocks in question were empty!
Knowing that oracle always reformats empty (here previously deleted) blocks before writing to it, a dummy table was created to (re)write any available block of the tablespace until a tablespace extension error occurs (do review the dedicated tablespace settings in advance):

create table reformat_me tablespace TEXT_DATIDX as select * from all_objects;

Repeat until the tablespace extension error:

insert into reformat_me select * from reformat_me;
commit;

...

ORA-1653: unable to extend table reformat_me by 128 in tablespace TEXT_DATIDX 

Execute another dbv based check:

DBVERIFY: Release 10.2.0.4.0 - Production on Tue Jan 3 14:40:39 2012
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
DBVERIFY - Verification starting : FILE = H:\ORACLE\SAN_3\ORADATA\WAZ\TEXT\TEXT_DATIDX_05.DBF

DBVERIFY - Verification complete

Total Pages Examined         : 262144
Total Pages Processed (Data) : 116700
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 143913
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 1531
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 0
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 1088144588 (10.1088144588)

Execute another rman baseline (level 0) backup immediately!!!

Have fun!

Jep, due to a disk failure, as i noticed during the analysis, some statements and things complained about datafiles being offline. An attempt to re-online some datafile resulted in an ORA-00376 error as follows:

SQL> ALTER DATABASE DATAFILE 'H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_06.DBF' ONLINE;
ALTER DATABASE DATAFILE 'H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_06.DBF' ONLINE
*
FEHLER in Zeile 1:
ORA-00376: Datei 6 kann zur Zeit nicht gelesen werden
ORA-01110: Datendatei 6: 'H:\app_ORACLE\SAN_3\ORADATA\appxyz\UNDOTBS03.DBF'

Looking up dba_data_files produced this output:

SQL> column file_name format a50
SQL> select file_id, status, online_status, file_name from dba_data_files
  where online_status != 'ONLINE' order by file_name;

FILE_ID  STATUS     ONLINE_  FILE_NAME
-------  ---------  -------  ---------------------------------------------------------
      1  AVAILABLE  SYSTEM   H:\app_ORACLE\SAN_3\ORADATA\appxyz\SYSTEM01.DBF
      5  AVAILABLE  RECOVER  H:\app_ORACLE\SAN_3\ORADATA\appxyz\UNDOTBS02.DBF
      6  AVAILABLE  RECOVER  H:\app_ORACLE\SAN_3\ORADATA\appxyz\UNDOTBS03.DBF
     58  AVAILABLE  RECOVER  H:\app_ORACLE\SAN_3\ORADATA\appxyz\UNDOTBS04.DBF
     65  AVAILABLE  RECOVER  H:\app_ORACLE\SAN_3\ORADATA\appxyz\UNDOTBS05.DBF
     10  AVAILABLE  RECOVER  H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_01.DBF
     47  AVAILABLE  RECOVER  H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_02.DBF
     50  AVAILABLE  RECOVER  H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_03.DBF
     60  AVAILABLE  RECOVER  H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_05.DBF
     55  AVAILABLE  RECOVER  H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_04.DBF
     86  AVAILABLE  RECOVER  H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_06.DBF

Further on, there is another file status according to v$datafile:

SQL> column name format a50
SQL> select FILE#, status, name from v$datafile
  where status in ('OFFLINE','RECOVER') order by name;

    FILE#  STATUS   NAME
---------  -------  ---------------------------------------------------------
        5  OFFLINE  H:\app_ORACLE\SAN_3\ORADATA\appxyz\UNDOTBS02.DBF
        6  OFFLINE  H:\app_ORACLE\SAN_3\ORADATA\appxyz\UNDOTBS03.DBF
       58  OFFLINE  H:\app_ORACLE\SAN_3\ORADATA\appxyz\UNDOTBS04.DBF
       65  OFFLINE  H:\app_ORACLE\SAN_3\ORADATA\appxyz\UNDOTBS05.DBF
       10  OFFLINE  H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_01.DBF
       47  OFFLINE  H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_02.DBF
       50  OFFLINE  H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_03.DBF
       55  OFFLINE  H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_04.DBF
       60  OFFLINE  H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_05.DBF
       86  OFFLINE  H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_06.DBF

Finally then, on the segments layer, one may inspect what segments do actually need recovery bei selecting from dba_rollback_segs:

SQL> select tablespace_name, segment_name, status from dba_rollback_segs
  where status = 'NEEDS RECOVERY';

TABLESPACE_NAME     SEGMENT_NAME      STATUS
------------------- ----------------- ----------------
UNDOTBS1            _SYSSMU13$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU16$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU17$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU22$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU23$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU24$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU25$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU26$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU27$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU28$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU29$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU30$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU31$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU32$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU33$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU36$        NEEDS RECOVERY
UNDOTBS1            _SYSSMU37$        NEEDS RECOVERY

So far, one notices that just the undo suffered from a disk failre but oracle also offlined other regular datafiles that reference the undo segments in question (see the four stati selected with several statements above).

Ok, this is a situation, that needs a closed database for recovery but using the standard way of closing the database will not work:

SQL> alter database close;
alter database close
*
FEHLER in Zeile 1:
ORA-00376: Datei 58 kann zur Zeit nicht gelesen werden
ORA-01110: Datendatei 58: 'H:\app_ORACLE\SAN_3\ORADATA\appxyz\UNDOTBS04.DBF'

However, for the curious of us, doing static selects is still possible:

SQL> select sysdate from dual;
--------
01.05.10

So i at least attempted to execute a shutdown that stopped the job queue and the dispatchers and stuff (as monitored in the alert log):

SQL> shutdown immediate;
ORA-00376: Datei 5 kann zur Zeit nicht gelesen werden
ORA-01110: Datendatei 5: 'H:\app_ORACLE\SAN_3\ORADATA\appxyz\UNDOTBS02.DBF'

What follows is a step-by-step protocol of the actions to resove the problem. These steps preassume an oracle on windows, to understand the services and registry steps, and a ready-to-go rman backup, to just do an automatic database recovery.

1. Stop the windows services for the database and the listener.
2. Set the autostart entry for the database to false (see HKLM/SOFTWARE/ORACLE/KEY_OraDb10g_home1/ORA_appxyz_AUTOSTART).
3. Start the windows service for the database.
4. Connect to the database as sysdba (sqlplus "/ as sysdba").
5. Just mount the database (SQL> startup mount;).
6. Execute a database wide recovery (SQL> recover database;), devine rman will care for any action by itself.
7. Open the database (SQL> alter database open;).
8. Online the undo files in question:
   

   	SQL> ALTER DATABASE DATAFILE 'H:\app_ORACLE\SAN_3\ORADATA\appxyz\UNDOTBS03.DBF' ONLINE;
   	

9. Online the data files in question:
   

   	SQL> ALTER DATABASE DATAFILE 'H:\app_ORACLE\SAN_4\ORADATA\appxyz\stuff\app_UTL_06.DBF' ONLINE;
   	

10. Reset the autostart entry for the database to the original value.
11. Start the windows service for the listener.

That’s it. Have fun.

So far, this is a huge step forward in providing professional means for semi-structured searching and sorting. However, what fairly seldom gets attention is the question how to realize equality or in-list searches (or filtering) on numeric values because launching a classic TermQuery or Filter on a numeric field will simply not work. Something quite commonly seen is to just employ a range query/filter with the same inclusive upper and lower bound to achive an equality logic like so:

Filter filter = NumericRangefilter.newIntRange("someField", 2, 2, true, true);

I do not know whether this will perform well under all circumstances but at least know that Lucene comprises some clever rewrite code to care for something chubby like this.

Jep uhh, replacing equality logic with the line above does not imply a comparable approach for in-list searches (or filtering), probably known from TermsFilter. The only way to reproduce in-list logic is to encode the numeric search tokens to the internal format by yourself. This is when the class NumericUtils comes in. It provides for several member methods that produce encoded strings from the family of common numeric datatypes like so:

long[] mdtIds = {168, 167, 151};
Filter orListFilter = new TermsFilter();
for (long mdtId : mdtIds)
((TermsFilter) orListFilter).addTerm(
  new Term(IndexField.IMP_MANDANT.name(), NumericUtils.longToPrefixCoded(mdtId)));

Someone may argue that using NumericUtils ist not a recommended employment of the Lucene library. He/she may be right … or not . Let’s see.

ps. I’m using query and filter more or less as synonyms throughout the article. In fact, a Lucene filter may just be seen as a query without scoring. This also becomes obvious iff one takes a look at classes like ConstantScoreQuery or QueryWrapperFilter.

have fun

Test failed: oracle.jdbc.driver.T2CConnection.getLibraryVersionNumber()I

The resolution trick seems to comprise of a copy of the ojdbc6.jar of the oracle client installation, here in d:\Programme\Oracle\product\11.1.0\client_1\jdbc\lib\, to the jdeveloper app server lib path, here in d:\Programme\Oracle\Middleware\wlserver_10.3\server\lib\.

My reference to the problem solution was: this thread entry on the oracle forums.

have fun

Providing on page help for form pages is usually a game like this: some input field may be called “Creation date” and the help text goes as “This is the creation date”. Wow, this is what the world needs to know! I more or less get angry or better ignorant seeing this information garbage but that’s another story. I prefer on page help content that provides page context information, just pointing out dedicated input fields only when necessary.

In fact, apex puts both approaches at your disposal. The key element with apex is the help text region that you may add with the create region dialogue on a page.

Configuring the wizard for the region, I choosed to have a hide and show region for the template and the page template body #1 for the display point.

This will put an initially hidden content area just on top of the form.

You may go now and enter help text content both for the page and for the several input fields of the form as shown below.

This results in having both the page and the input fields help being unfolded.

However, I did’nt enter any text for the input fields as explained above such that the final (unfolded) view looks as follows.

have fun!

However, changing the settings with Settings / Reading / Front page displays I already wondered what to enter with the Front page displays / Posts page select list. I actually expected to find an entry such as posts or default-posts or whatever but to no avail. In fact, leaving out this selection removes the the posts page from the blog completely. Stuck! Just driven by some enlightment of intuition (ha ha) I tried the following: I created another (empty) page on the Pages view, not forgetting to set the order index accordingly. Thereafter, i proceeded to the Settings / Reading view again and configured Front page displays / Posts page to this new (empty) item. And, it worked! That is, wordpress obviously only needs another (empty) container page to put the posts page into.

Another functionality i employed with the new start page was page templates that you’ll find along with the order index on the Pages view. It removes all the sidebar widget stuff from the start page which i find is much more comfortable. Please note however, that the availability and the layout of page templates depend on the theme of the blog.

have fun!

The following is nothing more than some extension of the oracle metalink document:

[ID 740029.1] Step By Step Guide On How To Configure And Test Client-Failover For Dataguard Switchover And Failover

That is, the article does not only present the cookbook how-to of its anchestor but also examines what happens in the database and what the clients experience will be concerning a so called transparent application failover (TAF). The scenario has been tested on an oracle 10.2.0.3 on windows, please note that the metalink document points to a some more applicable technique available with oracle 11gR2 (Client Failover Best Practices for Highly Available Oracle Databases: Oracle Database 11g Release 2).

Client-failover for dataguard, away from other failover scenarios, essentially aims at using a general tnsnames entry against some server-side database endpoint, no matter what server-side database instance is currently running in a dataguard primary role. This is actually the transparency in a transparent application failover where the application, client here, does not have to care to switch its network configuration in any way (some simple implementation would be, not uncommonly, to provide some tnsnames.ora, tnsnames.ora.prm and tnsnames.ora.stb and rename the files) during a failover or switchover.

The key to the solution is to have an equally named service being prepared to run on any database instance within the dataguard network. However, the service is defined to actually run on only one of these  database instances. This is achieved by firing a database trigger after startup that checks for the database role being primary along in v$database and then starts the service (see below). Do note, that services may also serve other requirements, such as workload management and analysis as well as load balancing. Such a way there is no overhead in having a couple of services being active on a database (you already know or use the xdb service that comes with a standard installation).

Set-up and test

The set-up consists of two database instances plt and plts where the first one is the usual primary. As sys, you at first create a service on plt being the current primary as follows:

--exec dbms_service.stop_service('pltp');
--exec dbms_service.delete_service('pltp');
exec dbms_service.create_service('pltp', 'pltp');

This will just register the service but not yet launch any code or whatsoever. The next step creates the database startup trigger to actually start the service for a primary instance:

--drop trigger manage_dg_service;
create or replace trigger manage_dg_service after startup on database
declare
  v_role varchar(30);
begin
  select database_role into v_role from v$database;
  if (v_role = 'PRIMARY') then
    dbms_service.start_service('pltp');
  end if;
end;
/

With the next planned switchover (or an explicit dbms_service.start_service(...);, depending on whatever 24X7 requirements you have), the service will be started. I verified this at two locations. On one hand I inspected the alert.log for any logging entries and in fact, the regarded service will, in terms of the trigger, be started after database startup but not before alter database open with an ALTER SYSTEM SET in memory only:

...
Wed Apr 13 17:17:16 2011
ALTER SYSTEM SET service_names='pltp' SCOPE=MEMORY SID='plts';
Wed Apr 13 17:17:19 2011
Completed: alter database open
...

The other spot i inspected was v$services with a subselect to include information from v$active_services as well. Its interesting to see, that service on a standby do not even have the service_id column populated:

-- current primary
SQL> column service_name format a20
SQL> column network_name format a20
SQL> set colsep ' | '
SQL> select service_id, name as service_name, network_name,
  2    (select count(*) from v$active_services where name = A.name) as active
  3  from v$services A order by name;

SERVICE_ID | SERVICE_NAME     | NETWORK_NAME     |     ACTIVE
---------- | ---------------- | ---------------- | ----------
         4 | plt              | plt              |          1
         5 | pltp             | pltp             |          1
         3 | pltXDB           | pltXDB           |          1
         1 | SYS$BACKGROUND   |                  |          1
         2 | SYS$USERS        |                  |          1

-- current standby
SQL> column service_name format a20
SQL> column network_name format a20
SQL> set colsep ' | '
SQL> select service_id, name as service_name, network_name,
  2    (select count(*) from v$active_services where name = A.name) as active
  3  from v$services A order by name;

SERVICE_ID | SERVICE_NAME     | NETWORK_NAME     |     ACTIVE
---------- | ---------------- | ---------------- | ----------
         0 | plts             | plts             |          0
         0 | SYS$BACKGROUND   |                  |          1
         0 | SYS$USERS        |                  |          1
         0 |                  | pltsXDB          |          0

Ok, having the regarded service being up and running successfully, we go and configure an according tnsname entry with the tnsnames.ora on the clients. It may look as follows whereby the two database instance host ip’s serve as the failover network endpoints in the ADDRESS_LIST / ADDRESS blocks of the configuration:

dg_plt_prod =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.29.48)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.29.49)(PORT = 1521)))
    (CONNECT_DATA =
      (SERVICE_NAME = pltp)))

Let’s now test what happens on a switchover as seen from some client side. I prepared a database link and a simple procedure on a third database instance (client) to select from v$database of the current primary and print some relevant information, most importantly v$database.db_unique_name to sqlplus:

create database link dg_plt_prod connect to xxx identified by xxx using 'dg_plt_prod';

create or replace procedure sfo_test as
begin
  for cur in (
    select '[' || to_char(sysdate, 'hh24:mi:ss') ||
      '] name: ' || name || ', db_unique_name: ' || db_unique_name || ', database_role: ' || database_role
      as status
    from v$database@dg_plt_prod
  ) loop
    dbms_output.put_line(cur.status);
  end loop;
end;
/

The output of the third database instance (client) sqlplus session reads as follows (the exception messages are in german but you can examine the error codes for inspection):

SQL> set serveroutput on

-- dg environment is running smoothly
SQL> exec sfo_test
[10:50:43] name: PLT, db_unique_name: plt, database_role: PRIMARY
PL/SQL-Prozedur wurde erfolgreich abgeschlossen.

-- last primary is going down, the connection being cancelled
SQL> exec sfo_test
BEGIN sfo_test; END;
*
FEHLER in Zeile 1:
ORA-02068: aufgrund eines schwerwiegenden Fehlers von DG_PLT_PROD
ORA-03113: Unerwartetes _bertragungsende in Kommunikation
ORA-06512: in "XXX.SFO_TEST", Zeile 3
ORA-06512: in Zeile 1

-- last primary is down, last standby not yet up,
--   the regarded service name unknown with sql*net
SQL> exec sfo_test
BEGIN sfo_test; END;
*
FEHLER in Zeile 1:
ORA-12514: TNS: Listener kennt den Service aktuell nicht, der in dem
Connect-Deskriptor angefordert wird
ORA-06512: in "XXX.SFO_TEST", Zeile 3
ORA-06512: in Zeile 1

-- last primary is the new standby, last standby is the new primary,
--   the dg environment is running smoothly again
SQL> exec sfo_test
[10:53:15] name: PLT, db_unique_name: plts, database_role: PRIMARY
PL/SQL-Prozedur wurde erfolgreich abgeschlossen.

So far, anything works as expected. The big shot is that there is no need to reconnect with the third database instance (client) due to the fixed user database link. The client session on the third database instance will care for this automatically (like with a short network outage).

Although this was all the functionality I actually needed for my business case, I mused about the coming out of a directly connected session. Will it failover that transparently as well? Let’s see:

-- still everything ok
select '[' || to_char(sysdate, 'hh24:mi:ss') || '] name: ' || name || ', db_unique_name: ' ||
  db_unique_name || ', database_role: ' || database_role as status
from v$database;

STATUS
--------------------------------------------------------------------
[14:03:27] name: PLT, db_unique_name: plts, database_role: PRIMARY

-- switchover in progress
select '[' || to_char(sysdate, 'hh24:mi:ss') || '] name: ' || name || ', db_unique_name: ' ||
  db_unique_name || ', database_role: ' || database_role as status
from v$database;

*
FEHLER in Zeile 1:
ORA-03113: Unerwartetes _bertragungsende in Kommunikation
Prozess-ID: 0
Session-ID: 128 Seriennummer: 216
ERROR: ORA-03114: Nicht mit ORACLE verbunden

-- switchover being done
select '[' || to_char(sysdate, 'hh24:mi:ss') || '] name: ' || name || ', db_unique_name: ' ||
  db_unique_name || ', database_role: ' || database_role as status
from v$database;

ERROR: ORA-03114: Nicht mit ORACLE verbunden
ERROR: ORA-03114: Nicht mit ORACLE verbunden

-- another explicit reconnect on sqlplus
select '[' || to_char(sysdate, 'hh24:mi:ss') || '] name: ' || name || ', db_unique_name: ' ||
  db_unique_name || ', database_role: ' || database_role as status
from v$database;

STATUS
-----------------------------------------------------------------------------
[14:24:07] name: PLT, db_unique_name: plt, database_role: PRIMARY

Nope, obviously, it won’t. Only the explicit reconnect serves us with the required response again.

But, why not dig deeper into the TAF-functionality of services by setting the failover_*-parameters of dbms_service.create_service(...); or dbms_service.modify_service(...);, respectively. Likewise we may continously have a look into the TAF-columns of v$session, namely failover_type, failover_method and failed_over.

At a first spot the TAF-columns of our directly connected session read like this so far:

select sid, serial#, logon_time, status, failover_type, failover_method, failed_over
  from v$session where program = 'sqlplus.exe';

       SID|   SERIAL#|STATUS  |FAILOVER_TYPE|FAILOVER_M|FAI
----------|----------|--------|-------------|----------|---
       125|        96|ACTIVE  |NONE         |NONE      |NO

A modify against our regarded service (within another session on the server) sets all the above mentioned parameters according to the possibilities of 10gR2 (for a detailed documentation see http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_serv.htm and http://vnull.pcnet.com.pl/dl/oracle/MAA_WP_10gR2_ClientFailoverBestPractices.pdf). This includes not applying aq_ha_notifications because although fast application notification (FAN) for avoiding long tcp timeouts is available since 10gR2 it is not be integrated into data guard, specifically the broker, before 11gR2 (!):

FAILOVER_METHOD_BASIC: Server side TAF method is BASIC. BASIC is the only value currently supported. This means that a new connection is established at failure time. It is not possible to pre-establish a backup connection. (which is to say, PRECONNECT is not supported).

FAILOVER_TYPE_SESSION: Server side TAF failover type is SESSION. At failure time, if the failover type is SESSION, TAF will re-connect to a surviving node and re-establish a vanilla database session. Customizations (for example, ALTER SESSION) must be re-executed in a failover callback.

That results in a session-level TAF at a sum of 5 minutes by 60 attempts at 5 secs.

begin
  dbms_service.modify_service(
    service_name => 'pltp',
    failover_method => dbms_service.FAILOVER_METHOD_BASIC,
    failover_type => dbms_service.FAILOVER_TYPE_SESSION,
    failover_retries => 60,
    failover_delay => 5);
end;
/

Let’s reconnect the directly connected session and remark the changed failover_type and failover_method values being listed immediately.

select sid, serial#, status, failover_type, failover_method, failed_over
  from v$session where program = 'sqlplus.exe';

       SID|   SERIAL#|STATUS  |FAILOVER_TYPE|FAILOVER_M|FAI
----------|----------|--------|-------------|----------|---
       125|        98|ACTIVE  |SESSION      |BASIC     |NO

ok, now execute another manual switchover in the background and check again what happens:

-- launch the test set-up standard select for the direct session
select '[' || to_char(sysdate, 'hh24:mi:ss') || '] name: ' || name || ', db_unique_name: ' ||
  db_unique_name || ', database_role: ' || database_role as status
from v$database;

STATUS
-----------------------------------------------------------------------------
[15:07:03] name: PLT, db_unique_name: plt, database_role: PRIMARY

-- switchover being underway the following select ***waits*** for completion
--   and does not thow exceptions about network errors like before
--   (however, after the switchover it complains about an impossible
--   replay)
select sid, serial#, status, failover_type, failover_method, failed_over
  from v$session where program = 'sqlplus.exe';
*
FEHLER in Zeile 1:
ORA-25408: Aufruf kann nicht sicher wiederholt werden

-- just try again and see it works (!) and features a failed_over = 'YES'
select sid, serial#, status, failover_type, failover_method, failed_over
  from v$session where program = 'sqlplus.exe';

       SID|   SERIAL#|STATUS  |FAILOVER_TYPE|FAILOVER_M|FAI
----------|----------|--------|-------------|----------|---
       111|         1|ACTIVE  |SESSION      |BASIC     |YES

-- well, try the test select again, works also
select '[' || to_char(sysdate, 'hh24:mi:ss') || '] name: ' || name || ', db_unique_name: ' ||
  db_unique_name || ', database_role: ' || database_role as status
from v$database;

STATUS
------------------------------------------------------------------------------
[15:09:59] name: PLT, db_unique_name: plts, database_role: PRIMARY

Great stuff really. But what about that ORA-25408 error? This is expected behaviour as according to metalink note 473145.1: SQLPLUS does not failover service receiving FAN events. Sqlplus can’t just handle this scenario before 10.2.0.4 and unless being started with the -F option. Martin Bach writes in an article (RAC One Node and Database Protection) that it is more or less the responsibility of the calling environment to handle just this exception (when the database is unable to replay the transactional operations that occur past the last committed transaction). I would go with that, especially concerning the logic to perform a sufficient rollback; before proceeding with transactions in the failed over session. OCI-JDBC, beware of the recent change from TAF to fast connection failover (FCF), in fact provides a couple of methods to get along with (http://download.oracle.com/docs/cd/B19306_01/java.102/b14355/ocitaf.htm or metalink note 276225.1 JDBC Sample on How to Implement OCI TAF callbacks with DML and PL/SQL).

conclusion

So, what’s next? Thinking about having a much smarter solution for the actual business case with a database link client session now? I got to disappoint you, sorry. TAF being based on service and an accordingly set failover_method as well as failover_type will not work over database links as described in metalink note 399453.1: Database Link Usage with Connect Time Failover or Transparent Application Failover:

Database Link Usage with Connect Time Failover or Transparent Application Failover [ID 399453.1]
Modified 06-AUG-2010 Type HOWTO Status PUBLISHED
Applies to:
Oracle Net Services – Version: 9.2.0.1.0 and later [Release: 9.2 and later ]
Information in this document applies to any platform.
Goal
Database link usage with Connect Time Failover (CTF) or Transparent Application Failover (TAF)
Solution
Database links do not currently support either Connection Time Failover or Transparent Application Failover.
This is confirmed by Oracle Development in the Bug 2393357 ORA-25402 USING TAF WITH DB-LINKS. This is closed with code “Status 92,Closed, Not a Bug”
The following enhancement request is outstanding for this issue. Bug 3389688 ORA-25402 WHEN USING TAF WITH DATABASE LINKS

One has to catch all this disconnect and unknown service exceptions. There is no way out. It’s a shame.

There is another valuable collection of metalink notes for TAF on 10g from Julian Dyke at TAF References (where Julian Dyke = ‘Pro Oracle Database 10g RAC on Linux’ and Martin Bach = ‘Pro Oracle Database 11g RAC on Linux’, ok?).

update concerning cold fusion

The last few days I also tested the service-based TAF, as described above, against(adobe) cold fusion. In fact, cold fusion does support TAF but only in the enterprise (or developer) edition and by employing the macromedia driver. I tested cold fusion version 9.x with a 11g jdbc driver and used the following datasource settings (note that you’ll need to select the other type driver class when creating the datasource):

--> JDBC URL
jdbc:macromedia:oracle://192.168.29.48:1521;ServiceName=hugopltp;AlternateServers=(192.168.29.49:1521);ConnectionRetryCount=60;ConnectionRetryDelay=5
--> Driver Class
macromedia.jdbc.MacromediaDriver

To keep it short, it does work with just one poor flaw. Upon a planned switchover the web site in action notices the role change somehow and correctly waits for completion. However, when the following finishes for the former primary:

alter database commit to switchover to physical standby with session shutdown;

and the database was dismounted, the web site throws an exception with this text:

Error Executing Database Query.
[Macromedia][Oracle JDBC Driver][Oracle]ORA-00604: error occurred at recursive SQL level 1 ORA-01219: database not open: queries allowed on fixed tables/views only
 
The error occurred in D:/wwwroot/_test/plt/plt_db_test.cfm: line 25

23 : 	name="qry_selectTest" result="res">
24 : 	
25 : 	#preserveSingleQuotes(form.sqlStatement)#
26 : 	
27 : </cfquery>

VENDORERRORCODE 	  604
SQLSTATE 	  HY008
SQL 	   select '[' || to_char(sysdate, 'hh24:mi:ss') || '] name: ' || name || ', db_unique_name: ' || db_unique_name || ', database_role: ' || database_role as status from v$database
DATASOURCE 	  PLT_DG_TEST

Iff you do a reload on that, the web site waits again until the switchover has been done and redisplays the data in order. So what? Is this cold fusion’s way to tell us about ORA-25408 from above or is it in fact different. Me, i don’t know. An recommended article from from datadirect (http://www.datadirect.com/resources/jdbc/oracle-rac/failover.html), where datadirect seems to be the actual producer of macromedia.jdbc.MacromediaDriver, does not really encourage someone to examine this question further (whereupon the article itself is ok but not the bottom line). That’s it.

Employing materialized views (or snapshot or mview for short) for producing simple sum-up reports is really cool stuff. You just launch some statement like the following:

create materialized view some_mv
  build immediate
  refresh force next (sysdate + 1/24/12)
as
select X.ts, Y.name from (
  select to_char(max(A.ts), 'dd.mm.yyyy hh24:mi') as ts, B.blubb
    from tab1 A, tab1_1 B where A.id = B.id
    group by B.blubb
) X, tab2 Y
  where X.blubb = Y.id;

and will be served with a well performing collection of data that is more or less current (that is why i call that simple). Oracle will care for the refresh of the mview by self-registering a job on calling dbms_refresh.refresh('some_mv');, that starts immediately and takes the interval from the statement. Handing in the force keyword just chooses a fast refresh method iff possible and a complete refresh method otherwise. There are more defaults applied by leaving other keywords unset, the refresh mode for example, but this is not the point of the article. It is:

Why does that … mview always show a state of NEEDS_COMPILE although no ddl action has happend along the objects dependency chain lately?

Uuh, the answer is not easy to give and much less easy to explain (by means of the oracle dictionary). Generally spoken, a NEEDS_COMPILE in fact implies another compile to be executed on the mview but, however, not to re-evaluate code integrity of the mview but data integrity instead. in other words, a recompile will find out whether some mview is stale concerning the underlying data (you know that from statistics and stuff). But let’s find out about that. A good starting point is the following article from metalink:

(454552.1) How To: What Causes So Many Invalid Materialized Views

testbed and tests

However, it will only show you expected behaviour, in a sense that oracle assumes what is to be expected behaviour and what is not. As a dba you may turn the medal up and down, you’ll not manage to bypass detailed testing in order to know what you get. My eye into the system is the following statement that i have been setting up from dba_mviews, dba_mview_refresh_times and dba_objects. dba_snapshots is no longer regarded, since it has not been documented from oracle since 10gR1 onwards (iff i remember it correctly), but is still available though. Some typical columns of dba_snapshots, as master_owner, master and master_link can now be sourced from dba_mview_refresh_times.master_owner,
dba_mview_refresh_times.master and dba_mviews.master_link, respectively. Please note also, that dba_objects contains two entities for the mview, one of object_type = 'MATERIALIZED VIEW' and one of object_type = 'TABLE'. This is important later on, when checking the status of the mview as seen from dba_objects. Another point to puzzle around with was the timestamps given with the three different views. Along my tests any data of dba_mviews.last_refresh_date, dba_mview_refresh_times.last_refresh and dba_objects.last_ddl_time where object_type = 'MATERIALIZED VIEW' was identical. Ok, here we go for the eye into the system statement (the commented columns will not be shown below but you may probably need them for another exercise):

select
  A.owner as owner, A.mview_name as name,
  (select A.compile_state || '/' || invalid from dba_mview_analysis
    where owner = A.owner and mview_name = A.mview_name) as c_stat_inval,
  (select master_owner || '.' || master ||
      decode(A.master_link, null, null, '@' || master_link) from dba_mview_refresh_times
    where owner = A.owner and name = A.mview_name) as master,
  (select status from dba_objects
    where owner = A.owner and object_name = A.mview_name
      and object_type = 'MATERIALIZED VIEW') as mvw_status,
  (select status from dba_objects
    where owner = A.owner and object_name = A.mview_name
      and object_type = 'TABLE') as tab_status,
  (select A.staleness || '/' || known_stale from dba_mview_analysis
    where owner = A.owner and mview_name = A.mview_name) as stale_known,
  /*A.stale_since, A.refresh_mode as refresh_mode, A.refresh_method as refresh_method,*/
  /*A.last_refresh_type,*/ A.last_refresh_date as last_refr_ts
from dba_mviews A
where A.mview_name in ('SOME_MV')
order by 1, 2, 3;

and this is a couple of tables and constraints to define a mview upon:

create table tab1 ( id number not null, ts date not null, flag varchar2(1) default not null,
  constraint tab1_pk primary key(ts, id) using index );
alter table tab1 add ( constraint tab1_uq unique (id) not deferrable using index );
create table tab1_1 ( id number not null, blubb number not null,
  constraint tab1_1_pk primary key(id) using index );
alter table tab1_1 add ( constraint tab1_1_tab1_fk foreign key( id)
  references tab1( id) not deferrable enable );
create table tab2 ( id number not null, name varchar2(128) not null,
  constraint tab2_pk primary key(id) using index );
alter table tab1_1 add ( constraint tab1_1_tab2_fk foreign key( blubb)
  references tab2( id) not deferrable enable );

What follows now is essentially a do something and look what happens, mostly by executing the eye into the system statement (only the last two trials use pl/sql). The tests were executed on a 11.2.0.1 / windows 64.

Firstly, the mview gets created (actually the mview statement from above) and we look for the results:

create materialized view some_mv
  build immediate
  refresh force next (sysdate + 1/24/12)
as
select X.ts, Y.name from (
  select to_char(max(A.ts), 'dd.mm.yyyy hh24:mi') as ts, B.blubb
    from tab1 A, tab1_1 B where A.id = B.id
    group by B.blubb
) X, tab2 Y
  where X.blubb = Y.id;

NAME    | C_STAT_INVAL    | MASTER | MVW_STATUS | TAB_STATUS | STALE_KNOWN     | LAST_REFR_TS
----------------------------------------------------------------------------------------------------
SOME_MV | VALID/N         | TAB2   | VALID      | VALID      | FRESH/N         | 08.04.2011 18:37:44
.

Jep, for C_STAT_INVAL the source column dba_mviews.compile_status looks fine and dba_mview_refresh_times.invalid is not true. For MVW_STATUSand TAB_STATUS, which represent the above mentioned status of the mview as seen from dba_objects, we get what we expect. Also dba_mviews.staleness is in order and dba_mview_refresh_times.known_stale does not “know” about any staleness. The next step is to insert some data and look again:

insert into tab2 (id, name) values (1, 'name 1');
insert into tab2 (id, name) values (2, 'name 2');
insert into tab1 (id, ts, flag) values (1, sysdate, 'T');
insert into tab1 (id, ts, flag) values (2, sysdate-1/12, 'T');
insert into tab1_1 (id, blubb) values (1, 1);
insert into tab1_1 (id, blubb) values (2, 2);
commit;

NAME    | C_STAT_INVAL    | MASTER | MVW_STATUS | TAB_STATUS | STALE_KNOWN     | LAST_REFR_TS
----------------------------------------------------------------------------------------------------
SOME_MV | NEEDS_COMPILE/Y | TAB2   | INVALID    | VALID |    | NEEDS_COMPILE/N | 08.04.2011 18:42:44
.

Hhm, the stati change, except for “knowing” about staleness and the mview status from dba_objects has flipped too. Ok, why not. Since the given data convinced me to compile the mview, i go for that:

alter materialized view some_mv compile;

NAME    | C_STAT_INVAL    | MASTER | MVW_STATUS | TAB_STATUS | STALE_KNOWN     | LAST_REFR_TS
----------------------------------------------------------------------------------------------------
SOME_MV | VALID/N         | TAB2   | VALID      | VALID      | STALE/Y         | 08.04.2011 18:54:40
.

Aah, everything ok gain, but the mview has now been explicitely marked stale (the underlying data is inconsistent with the mview) and oracle does “know” about that. Fine. However, since the mview has now lost consistency with the underlying data, we should do an on-demand refresh (will actually be triggered from the job being created from oracle automatically iff you follow the straight path):

exec dbms_refresh.refresh('SOME_MV');

NAME    | C_STAT_INVAL    | MASTER | MVW_STATUS | TAB_STATUS | STALE_KNOWN     | LAST_REFR_TS
----------------------------------------------------------------------------------------------------
SOME_MV | VALID/N         | TAB2   | VALID      | VALID      | FRESH/N         | 08.04.2011 18:57:02
.

Yes, everything shiny again. Now, the following will execute an update on the given master table of the mview:

update tab2 set name = 'name 22222222' where id = 2;
commit;

NAME    | C_STAT_INVAL    | MASTER | MVW_STATUS | TAB_STATUS | STALE_KNOWN     | LAST_REFR_TS
----------------------------------------------------------------------------------------------------
SOME_MV | NEEDS_COMPILE/Y | TAB2   | INVALID    | VALID      | NEEDS_COMPILE/N | 08.04.2011 19:03:17
.

Obviously the same as with the initial inserts … expected behaviour. Just to be shure, we take a look at the real data:

select 'MV' as srcc, ts, name from some_mv
union all
select 'STMT' as srcc, X.ts, Y.name from (
  select to_char(max(A.ts), 'dd.mm.yyyy hh24:mi') as ts, B.blubb
    from tab1 A, tab1_1 B where A.id = B.id
    group by B.blubb
) X, tab2 Y
  where X.blubb = Y.id;

SRCC | TS               | NAME
---------------------------------------
MV   | 08.04.2011 18:42 | name 1
MV   | 08.04.2011 16:47 | name 2
STMT | 08.04.2011 18:42 | name 1
STMT | 08.04.2011 16:47 | name 22222222
.

Jep, as expected again. Not missing to reset up the testbed, i.e. the mview stati, for the next case using dbms_refresh.refresh();, see above, i ask what happens when i update a column of a non master table that even does not appear with the mview setup statement:

update tab1 set flag = 'F' where id = 2;
commit;

NAME    | C_STAT_INVAL    | MASTER | MVW_STATUS | TAB_STATUS | STALE_KNOWN     | LAST_REFR_TS
----------------------------------------------------------------------------------------------------
SOME_MV | NEEDS_COMPILE/Y | TAB2   | INVALID    | VALID      | NEEDS_COMPILE/N | 08.04.2011 19:07:12
.

Uuh, everything invalid again. This was not expected, at least by me (got to rtfm). I do another manual refresh to clean up the testbed and now switch from dml to ddl test mode. I wonder what will be the result of the following:

alter table tab1 add(blabla number null );

NAME    | C_STAT_INVAL    | MASTER | MVW_STATUS | TAB_STATUS | STALE_KNOWN     | LAST_REFR_TS
----------------------------------------------------------------------------------------------------
SOME_MV | NEEDS_COMPILE/Y | TAB2   | INVALID    | VALID      | NEEDS_COMPILE/N | 08.04.2011 19:34:40
.

Nothing essentially new it seems and, most important, nothing different from the dml cases? Clean up the testbed one more time and try harder now, be really nasty:

drop table tab1_1;

NAME    | C_STAT_INVAL    | MASTER | MVW_STATUS | TAB_STATUS | STALE_KNOWN     | LAST_REFR_TS
----------------------------------------------------------------------------------------------------
SOME_MV | NEEDS_COMPILE/Y | TAB2   | INVALID    | VALID      | NEEDS_COMPILE/N | 08.04.2011 19:37:23
.

Aha, needs some compile. We saw that before, did’nt we. I supposed to do something really out of style but oracle still seems to keep calm. Again, i might need a recompile. I’ll just have a try:

alter materialized view some_mv compile;

NAME    | C_STAT_INVAL    | MASTER | MVW_STATUS | TAB_STATUS | STALE_KNOWN     | LAST_REFR_TS
----------------------------------------------------------------------------------------------------
SOME_MV | COMPILATION_ERROR/N | TAB2 | INVALID  | VALID      | COMPILATION_ERROR/N | 08.04.2011 19:37:23
.

Bingo, only now the code inconsistency gets reflected with the dictionary. But, out of the habits of a dba, let’s try a show errors after the compile with a pl/sql shell:

show errors

Keine Fehler.

Puuuuh, no errors. This can’t be true! And what will dbms_refresh.refresh(...); tell us?

exec dbms_refresh.refresh('SOME_MV');

FEHLER in Zeile 1:
ORA-12018: Folgender Fehler bei Codegenerierung f³r SOME_MV aufgetreten
ORA-00942: Tabelle oder View nicht vorhanden
ORA-06512: in "SYS.DBMS_SNAPSHOT", Zeile 2558
ORA-06512: in "SYS.DBMS_SNAPSHOT", Zeile 2771
ORA-06512: in "SYS.DBMS_IREFRESH", Zeile 685
ORA-06512: in "SYS.DBMS_REFRESH", Zeile 195
ORA-06512: in Zeile 1

Finally, we get a thorough exception, although, however, the exception contains ora-00942 which is another running infamous error message, for not telling us what table or view is actually missing … I was also trying a view access based on the dropped table scenario and the information from the dictionary did not change compared to the data above. Last but not least I re-created the table along with the foreign key and found that one has to do an alter materialized view ... compile; before any other exec dbms_refresh.refresh(...); to fix the situation, looks logical.

conclusions

Throughout the article and in regard to a mview, I was talking a lot about consistency, namely concerning the underlying data and the code dependency. After testing the behaviour of a mview under different scenarions, I may tend to have learned that the implementation of the mview sql or pl/sql interface with oracle is not consistent with other interfaces, i.e. for regular views or for tables. The most astonishing point is however, that you can’t tell at any given point in time, whether some mview is invalid due to some dml or ddl changes of the underlying layers. In general, i believe that the seen mview interface comprises a design flaw in integrating the conceptually different aspects of code and data into a usually code-dedicated compile statement. I would, iff someone out there would ask me, ha ha, propose to include a pseudo-column with every mview that tells you about the staleness of the underlying data with just this executed select (using every day oracle read consistency).

Have fun, nevertheless.

RFS: No standby redo logfiles available

The reason for this message is most probably that you have cloned your standby database with rman and configured your dataguard environment to directly write into redo log at standby (using LGWR), instead of just transfering the archive log items from primary (using ARCH), but have missed to provide the necessary standby redo log files. RFS may also log RFS[1]: Unable to open standby log 9: 313 or something similar (the primary will also complain about connection problems to the standby destination target, which is the standby redo log, actually).

RFS: No standby redo logfiles available of size 104857600 bytes

This is another message you may hit for a comparable reason, however, this one implies that standby redo log files do exist, but of a wrong size. Standby redo log files indeed have to match the size of the online log files as well as the archive log files, respectively. As for this example, oracle expects standby redo log files of size 100 mb.

It is interesting though to see, that dataguard does an intelligent fallback in just leaving the transactional log shipping aside (or in error) and proceeding in the traditional log switch triggered shipping mode (using ARCH). That is, dataguard continues to work, although some misconfiguration is pending. Really cool!

Do regard, by the way, that the things have changed with the introduction of 10.2.0.4. From this release on, a standby database resulting from an rman clone is smart enough to create the necessary standby redo log on the run. In detail and supposed that you already created the standby redo log on the initial primary, the standby database finds from the standby control file that there should exist standby redo log files (which is true for the online log also). However, only with the first log switch from primary, the standby database will step into some standby redo log regeneration by means of log file clearing (see elsewhere what that means). I collected some alert log output to trace what actually happens and it reads as follows:

• Recovery of rman duplicate has finished, rfs starts and finds the srl’s missing.

  Incomplete Recovery applied until change 599746
  Completed: alter database recover logfile 'J:\ORADATA\DGP\ARCH\ARC00008_0733948503.001'
  Redo Shipping Client Connected as PUBLIC
  -- Connected User is Valid
  RFS[1]: Assigned to RFS process 3172
  RFS[1]: Identified database type as 'physical standby'
  Mon Nov 01 19:59:50 2010
  RFS LogMiner: Client disabled from further notification
  Mon Nov 01 20:00:53 2010
  Redo Shipping Client Connected as PUBLIC
  -- Connected User is Valid
  RFS[2]: Assigned to RFS process 6048
  RFS[2]: Identified database type as 'physical standby'
  Primary database is in MAXIMUM PERFORMANCE mode
  Primary database is in MAXIMUM PERFORMANCE mode
  Mon Nov 01 20:00:53 2010
  Errors in file e:\oracle\product\10.2.0\admin\dgs\udump\dgs_rfs_6048.trc:
  ORA-00313: open failed for members of log group 4 of thread 0
  ORA-00312: online log 4 thread 0: 'E:\ORADATA\DGS\STBREDO\STBREDO04B.LOG'
  ORA-27041: unable to open file
  OSD-04002: unable to open file
  O/S-Error: (OS 2) The system cannot find the file specified.
  ORA-00312: online log 4 thread 0: 'E:\ORADATA\DGS\STBREDO\STBREDO04A.LOG'
  ORA-27041: unable to open file
  OSD-04002: unable to open file
  O/S-Error: (OS 2) The system cannot find the file specified.
  

• However oracle seems to notice that the srl’s have already been registered with the controlfile (from the initial primary) but not yet created on standby.
  

  SRL log 4 needs clearing because log has not been created
  

• Well, after cycling through all the srl’s and repeating the above entries, rfs finally prints that no srl’s are seen (of a certain size, ha ha).
  

  RFS[2]: No standby redo logfiles of size 102400 blocks exist
  

• But, now oracle automatically creates (cleares) the srl’s.
  

  Clearing online log 7 of thread 0 sequence number 0
  ...
  Clearing online log 4 of thread 0 sequence number 0
  

• And … some way further down the alert, the first srl has been successfully opened.
  

  Mon Nov 01 20:00:54 2010
  Redo Shipping Client Connected as PUBLIC
  -- Connected User is Valid
  RFS[3]: Assigned to RFS process 4116
  RFS[3]: Identified database type as 'physical standby'
  RFS[3]: Successfully opened standby log 4: 'E:\ORADATA\DGS\STBREDO\STBREDO04A.LOG'
  

• By the way, the same procedure will be applied for the orl’s, but only after media recovery has been started.
  

  ALTER DATABASE recover managed standby DATABASE disconnect
  MRP0 started with pid=21, OS id=596
  Managed Standby Recovery not using Real Time Apply
   parallel recovery started with 15 processes
  Mon Nov 01 20:09:57 2010
  Waiting for all non-current ORLs to be archived...
  ...
  Mon Nov 01 20:10:00 2010
  Errors in file e:\oracle\product\10.2.0\admin\dgs\bdump\dgs_mrp0_596.trc:
  ORA-00313: open failed for members of log group 2 of thread 1
  ORA-00312: online log 2 thread 1: 'E:\ORADATA\DGS\REDO\REDO02B.LOG'
  ORA-27041: unable to open file
  OSD-04002: unable to open file
  O/S-Error: (OS 2) The system cannot find the file specified.
  ORA-00312: online log 2 thread 1: 'E:\ORADATA\DGS\REDO\REDO02.LOG'
  ORA-27041: unable to open file
  OSD-04002: unable to open file
  O/S-Error: (OS 2) The system cannot find the file specified.
  ...
  Clearing online redo logfile 2 E:\ORADATA\DGS\REDO\REDO02.LOG
  Clearing online log 2 of thread 1 sequence number 14
  ...
  Clearing online redo logfile 2 complete
  

Have fun!