Mandalika's scratchpad [ Work blog @Oracle | Stock Market Notes | My Music Compositions ]

Old Posts: 09.04  10.04  11.04  12.04  01.05  02.05  03.05  04.05  05.05  06.05  07.05  08.05  09.05  10.05  11.05  12.05  01.06  02.06  03.06  04.06  05.06  06.06  07.06  08.06  09.06  10.06  11.06  12.06  01.07  02.07  03.07  04.07  05.07  06.07  08.07  09.07  10.07  11.07  12.07  01.08  02.08  03.08  04.08  05.08  06.08  07.08  08.08  09.08  10.08  11.08  12.08  01.09  02.09  03.09  04.09  05.09  06.09  07.09  08.09  09.09  10.09  11.09  12.09  01.10  02.10  03.10  04.10  05.10  06.10  07.10  08.10  09.10  10.10  11.10  12.10  01.11  02.11  03.11  04.11  05.11  07.11  08.11  09.11  10.11  11.11  12.11  01.12  02.12  03.12  04.12  05.12  06.12  07.12  08.12  09.12  10.12  11.12  12.12  01.13  02.13  03.13  04.13  05.13  06.13  07.13  08.13  09.13  10.13  11.13  12.13  01.14  02.14  03.14 


Friday, January 12, 2007
 
Backing Up Sun Secure Application Switch Configuration

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:

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.
____________________
| | |


Sunday, January 07, 2007
 
Energy Policy Act of 2005 - Daylight Saving Time changes 2007

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:
| | | |


Thursday, January 04, 2007
 
Oracle: Lost Redo Log

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:




2004-2014 

This page is powered by Blogger. Isn't yours?