Multi-node deployments of enterprise applications like E-Business Suite (aka Oracle Applications) have a dependency on hardware load balancers like Sun Secure Application Switch^*. Just like any piece of hardware, Sun Secure Application Switches are also vulnerable to hardware failures. Naturally we want to make a backup copy of the switch configuration once everything is configured and tested properly. So, here are the steps to save the existing configuration:

1. Connect to Application Switch on the CLI. On the CLI, type, for example:
   

   
    % telnet 192.168.109.70
    Trying 192.168.109.70...
    Connected to 192.168.109.70.
    Escape character is '^]'.
    username: admin
    password:
   
    MDE> 
   
   

   
   
2. Save the configuration to any file with show runningConfig saveToFile command as shown below:
   

   
    MDE> show runningConfig saveToFile sunfish_3appnodes_010707.cfg.txt password admin nameValuePairs true
   
    Please confirm the password:
   
    Note: Opening file "/ftl0/usr/home/sunfish_3appnodes_010707.cfg.txt" to write running-config.
   
    MDE> quit
    Goodbye
    Connection to 192.168.109.70 closed by foreign host.
   
   

   
   
3. Finally download the configuration file from the switch {to the local host} with the help of trivial file transfer program (tftp) on port 69.
   

   
    % tftp 192.168.109.70 69
   
    tftp> get /ftl0/usr/home/sunfish_3appnodes_010707.cfg.txt
    Received 19672 bytes in 0.2 seconds
   
    tftp> quit
   
   

The configuration file may look like:

################################################################################
#  System Name     : Sun Secure Application Switch
#  Date            : Sun Jan  7 18:49:33 2007
#  Serial No       : 00608000124
#  Sofware Version : V3_1R0
################################################################################
commandModeEntry on
enable
configure

#
# Create all vSwitches upfront
#
vSwitch vSwitchName EBS 
    vRouter name default description {Default vRouter} 
    vRouter name default 
    exit;
exit;
vSwitch vSwitchName system description {System vSwitch} 
vSwitch vSwitchName system 
    vRouter name management description {System Management vRouter} 
    vRouter name management 
    exit;
    vRouter name shared description {Shared vRouter} 
    vRouter name shared 
    exit;
exit;

#
# Event configuration and statistics
#
event fileLogSize 4194304 
...
...

Sample Sun Secure Application Switch configuration:

Click here for the complete copy of the configuration file from an E-Business Suite 11.5.10 deployment with three application server nodes in the middle-tier.

Related documentation:

• Clustering and Securing Web Applications: A Tutorial
  
• Sun Secure Application Switch - N1000 Series documentation

Note:
Sun Secure Application Switch is more than a hardware load balancer. Check the home page of Sun Secure Application Switch for key features. By the way, Sun Secure Application Switch may also be referred as 'Nauticus Switch' or 'Sunfish' by some Sun folks.
____________________
Sun | Sun Secure Application Switch | Oracle Applications | E-Business Suite

As you know, due to the Energy Policy Act of 2005, there will be some changes to the daylight saving time starting in 2007. As a hardware/software vendor, Sun Microsystems is ready with a solution (set of patches) to accommodate those changes; and the required information is well documented in the form of alerts.

Documentation

1. Required patches for Solaris, Java and Sun Fire firmware:
   
   BigAdmin tech note: 2007 Daylight Saving Time Changes in the U.S
   
   
   
2. The above tech note is referring to a Sun alert, 102178, which you can find on sunsolve web site at:
   
   Daylight Saving Time (DST) Changes for Australia (2006), United States (2007) and Others
   
   
   
3. Required firmware for timezone changes due to energy policy act of 2005 is at:
   
   Required Server Firmware for Timezone Changes Due to U.S. Energy Policy Act of 2005

In case if Sun didn't address some areas which may get impacted with the changes mentioned in energy policy act of 2005, feel free to file a bug at bugs.sun.com (Java bugs) or at bugs.opensolaris.org (Solaris bugs).
______________
Technorati tags:
Solaris | OpenSolaris | Java | Sun Fire | Sun Microsystems

Scenario:

The disk that is holding the most up-to-date redo log files experienced a fatal failure, and the database wouldn't come up any more. It complains about missing redo logs. So, you copy the redo log files from a recent backup; but still the database won't come up with error messages like ORA-00314: log 1 of thread 1, expected sequence# doesn't match.

SQL> startup
ORACLE instance started.

Total System Global Area 4294967296 bytes
Fixed Size                  1306568 bytes
Variable Size            2534150200 bytes
Database Buffers         1728053248 bytes
Redo Buffers               31457280 bytes
Database mounted.
ORA-00314: log 1 of thread 1, expected sequence#  doesn't match
ORA-00312: online log 1 thread 1: '/opt/oracle/oradata_4/RedoLogFiles/log1.dbf'

How to bring up the database with no redo logs?

In production environments, usually archive logging will be turned on. If that's the case, consult the Oracle system administration documentation to restore the lost transactions.

In all other cases it is very unlikely to recover the lost transactions. So the easiest way to bring up the database is to rebuild the control file. The steps to rebuild the control file with new redo log files are as follows:

1. Start the database up.
   
   SQL> startup <- let it complain about online redo log
   
   
   
2. Run the following command to dump the control file into a trace file.
   

   SQL> alter database backup controlfile to trace;
   Database altered.

   
   Go to udump location and locate the file which contains the necessary SQL text to build the control file. The easiest way is to grep for text like 'CREATE CONTROLFILE REUSE DATABASE'. Once you locate the trace file, change the extension from trc to sql and change NORESETLOGS to RESETLOGS. That is, a SQL like:
   
   CREATE CONTROLFILE REUSE DATABASE "XYZ" NORESETLOGS NOARCHIVELOG
   
   should be changed to
   
   CREATE CONTROLFILE REUSE DATABASE "XYZ" RESETLOGS NOARCHIVELOG
   
   Remove the lines starting from the line "RECOVER DATABASE USING BACKUP CONTROLFILE" to the end.
   
   
   
3. Shut down the database
   
   
   
4. Add the parameter _allow_resetlogs_corruption=TRUE to the init.ora file.
   
   
   
5. Run the script that you just modified -- it creates a new control file.
   
   
   
6. Shut down the database one more time
   
   
   
7. Start the database instance by running startup command as sysdba. It may fail with the error ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
   
   
   
8. Open the database with by running alter database open resetlogs;. Redo log files will be automatically created in this step.
   
   
   
9. Shutdown the database, remove the parameter _allow_resetlogs_corruption=TRUE from the init.ora file and restart the database instance. If the instance comes up fine, shut it down and take a backup. Otherwise, check the alert messages carefully and act accordingly to fix the things up.
   
   
   

Acknowledgements:
Akiko Marti

________________
Technorati tags:
Oracle