Saturday, November 19, 2011

IIT entrance exam 2012 forms online application form --

HI ,
Using below link we can fill the Online IIT entrance form .

http://www.iitg.ac.in/jee/


Let me knew for more detail ..


Thanks
Vinod Joshi

Synchronize a Gap on the Standby database in missing archived redo case


Synchronize a Gap on the Standby DB when the Archived Logs are Lost

Summary
Case Description: The archived logs are not present on the Standby DB and they are not available on the PROD Server,
so now the standby had lagged far behind the primary, many required archived logs to close the gap were removed and no backup of them was available.
In order to close the gap, we will perform an incremental backup that will contain all transactions since the last SCN recorded on the standby database.
Using this technique is convenient if the total amount of transactions that make the gap is less than the database size.

Action Items
In order to avoid this problem to happen in the future, we recommend the following action items
- Setup script for daily backup and cleanup of the recovery area
- Setup job to check for archivelog destination free space and executing the backup and cleanup script if required before the scheduled run.

Implementation Steps

Cancel Recovery on Standby
SQL> alter database recover managed standby database cancel;

Trying to recover on Standby
SQL> recover standby database;
ORA-00279: change 11021986 generated at 01/09/2011 11:39:03 needed for thread 1
ORA-00289: suggestion : /arch/ORACLE/ORADATA/SATI/ARCHIVE/1_205_674755717.ARC
ORA-00280: change 11021986 for thread 1 is in sequence #205

Check current_scn on Standby
SQL> select current_scn from v$database;
CURRENT_SCN
-----------
11021980

Create an Incremental Backup from this SCN on the Primary DB
Z:\backup> rman target sys@PROD_PRIMARY
RMAN> backup incremental from scn 11021980 database tag 'FORSTANDBY' FORMAT '/BACKUP/FOR_STANDBY_%U';


Backup the Controlfile for ‘Standby’ on the Primary DB
RMAN> backup current controlfile for standby format '/BACKUP/FORSTDBYCTRL.bkp';

Transfer the Incremental Backup Sets from Primary DB to the Standby Server (Location = /Temp/Incr_Backup)
cd /BACKUP
copy FOR_STANDBY_*.*  \\STANDBY\ /TEMP/INCR_BACKUP
copy FORSTDBYCTRL.bkp  \\STANDBY\ /TEMP/INCR_BACKUP

Restore controlfile on the Standby
RMAN> RESTORE STANDBY CONTROLFILE FROM '/TEMP/INCR_BACKUP/FORSTDBYCTRL.BKP';

Catalog the Incremental Backups on the Standby Server
Note that for the catalog command to succeed you will need to move the backups to be within the Flash Recovery Area.
RMAN> catalog start with '/FRA/SATISTD/BACKUPSET';

Recover the Database and Cleanup Redologs on the Standby Server
RMAN> recover database noredo;


SQL> alter database flashback off;
SQL> alter database flashback on;
SQL> alter database recover managed standby database disconnect from session;

If more archived logs were created on the primary since the finish of the SCN based incremental backup then you can copy them over and recover the standby database using the command : “recover standby database;”

Enable the broker at both sites and check
When enabling the broker again it will take over the responsibility of managing the site and will resynchronize both sites
SQL> alter system set dg_broker_start=true scope=both;

Wednesday, October 12, 2011

07 Interesting Parameters in UNIX


07 Interesting Parameters in UNIX env..

$? –> Exit Status.

$# –> No: of arguments.

$* –> List of arguments.

$$ –> PID of current shell.

$! -–>PID of the last background process.

$- –> current shell settings.

$0 – $9 –-> Name of the command that is being executed.

Saturday, September 10, 2011

Difference between /bin, /sbin, /usr/bin and /usr/sbin

/bin contains all the essential binaries file that can be execute by local and other users
/sbin contains system files like useradd that can be exeute by root
local user has to use sudo to run these
/usr/bin , /usr/sbin contains non essential binaries e.g. office tools etc
these are parted to minimize size of root

Starting and Stopping Daemons with runlevel

The startup scripts I have been mentioning in the /etc/init.d directory govern the activation of daemons that were installed with some of your Linux packages. The commands to start and stop them are universal.
Starting a Daemon
If a startup script exists in the /etc/init.d directory, then its daemon can be started by specifying its filename followed by the keyword "start" as seen here:
root@u-joshi:~# /etc/init.d/apache start
 * Starting apache 1.3 web server...
   ...done.
root@u-joshi:~#

Stopping a Daemon

Daemons can be stopped by specifying its script filename followed by the keyword "stop":
root@u-joshi:~# /etc/init.d/apache stop
 * Stopping apache 1.3 web server...
   ...done.
root@u-joshi:~#

Restarting a Daemon

Daemons usually only read their configuration files when they are started, therefore if you edit the file, you have to restart the daemon for the new settings to become active. This can be done with the keyword "restart":
root@u-joshi:~# /etc/init.d/apache restart
 * Restarting apache 1.3 web server...
   ...done.
root@u-joshi:~#
chkconfig command can be used to adjust which applications start at each runlevel.
[root@joshi joshi ]# chkconfig --list
keytable 0:off 1:on  2:on  3:on 4:on  5:on 6:off
atd      0:off 1:off 2:off 3:on 4:on  5:on 6:off
syslog   0:off 1:off 2:on  3:on 4:on  5:on 6:off
gpm      0:off 1:off 2:on  3:on 4:on  5:on 6:off
kudzu    0:off 1:off 2:off 3:on 4:on  5:on 6:off
wlan     0:off 1:off 2:on  3:on 4:on  5:on 6:off
sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off
...
...
[root@joshi  joshi ]# chkconfig --list | grep mail
sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off
[root@joshi joshi ]#
The chkconfig command can be used with grep to determine the run levels in which sendmail will run. Here we see it will run at levels 3 and 5. 

[root@joshi  joshi ]# chkconfig --list | grep mail
sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off
[root@bigboy joshi ]#

Linux System Boot Runlevels Detail


Mode Directory Run Level Description
0/etc/rc.d/rc0.dHalt
1/etc/rc.d/rc1.dSingle-user mode
2/etc/rc.d/rc2.dNot used (user-definable)
3/etc/rc.d/rc3.dFull multi-user mode (no GUI interface)
4/etc/rc.d/rc4.dNot used (user-definable)
5/etc/rc.d/rc5.dFull multiuser mode (with GUI interface)
6/etc/rc.d/rc6.dReboot


Based on the selected runlevel, the init process then executes startup scripts located in subdirectories of the /etc/rc.d directory. Scripts used for runlevels 0 to 6 are located in subdirectories /etc/rc.d/rc0.d through /etc/rc.d/rc6.d, respectively.

Determining the Default Boot runlevel

The default boot runlevel is set in the file /etc/inittab with the initdefault variable. When set to 3, the system boots up with the text interface on the VGA console; when set to 5, you get the GUI. Here is a snippet of the file (delete the initdefault line you don't need):
# Default runlevel. The runlevels used by RHS are:
# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
# 
id:3:initdefault:                         # Console Text Mode
id:5:initdefault:                         # Console GUI Mode

Note the following:
  • Most home users boot up with a Windows like GUI (runlevel 5)
  • Most techies will tend to boot up with a plain text-based command-line-type interface (runlevel 3)
  • Changing initdefault from 3 to 5, or vice-versa, has an effect upon your next reboot. See the following section on how to get a GUI login all the time until the next reboot.
  • Of course, don't set the initdefault value to 6 or your system will constantly reboot. Setting it to 0 will never allow it to start!

Troubleshooting : Known RMAN Performance Problems

The note has workaround for the following bugs:


Bug 5219484 - CATALOG RESYNCS ARE VERY SLOW - ROUT TABLE HAS 6 MILLION ROWS +
Bug 5047758 - RMAN SLOW PERFORMANCE ON EXIT (UPDATING STATUS STATISTICS)
Bug 5247609 RMAN SLOW PERFORMANCE DURING REGISTER DATABASE/OPEN RESETLOGS
Bug 1551773 RMAN RESTORE RUNS VERY SLOWLY WHEN THERE ARE MANY ROWS IN THE CKP TABLE
Bug 2803823 RESYNC CATALOG AND MAINTENANCE COMMANDS ARE SLOW
Bug 4013855 - RMAN CROSSCHECK IS TAKING A LONG TIME TO COMPLETE
Note 339964.1 RMAN 8.1.7 Crosscheck Command Is Very Slow
Bug 4548861 RMAN RESTORE ARCHIVELOG UNTIL SEQUENCE TAKES A LONG TIME TO COMPLETE
Note 342999.1 First Resync on Production Host After Running RMAN on
Bug 2876717 RMAN backup starts SLOW if READ-ONLY device is used
Bug 1887868 RMAN RESYNC takes a long time with many tablespaces
Internal Bug 1712720 RMAN MAINTENANCE COMMANDS ARE VERY SLOW
Bug 2174697 RMAN incremental backup performance degrades over time in NOCATALOG mode
Bug 2385857 RMAN backup performance degrades over time for large DB_FILES
Bug 2484250 RMAN CUMULATIVE BACKUP / MAINTENENCE may appear to hang (spin)
Bug 2610596 Huge CPU usage from RMAN server when TAPE not mounted with BACKUP_TAPE_IO_SLAVE=TRUE
Bug 2968394 RESYNC TAKES A LONG TIME TO COMPLETE : LARGE BP TABLE
Bug 1407413 NO INDEX TO ON RI CONSTRAINT BETWEEN BS AND BDF
Bug 4110489 RMAN SKIP READ ONLY TABLESPACE CLAUSE TAKING TOO MUCH TIME TO SKIP
Bug 3966722 CONCURRENT RMAN BACKUPS WAIT ON TM ENQUEUE ON CKP TABLE
Bug 2710321 X$KCCFN / V$DATAFILE much slower in 9i than 8i with many datafiles