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

Win Up to $5,000 in prizes From Matalink


you have the  opportunity to showcase your expertise and knowledge of Oracle products and technologies with your peers in the industry। Contribute to Oracle's Customer Knowledge Exchange, the online customer channel that enables you to showcase your expertise, build your own customer network, and share news and information with your peers starting April 1 through May 15, 2007 and become eligible to win a $5,000.00 Oracle University Scholarship and much more.

First to Contribute, First to Win - Gift certificates of $100 to the first 20 contributors to have their article published in Oracle MetaLink – Customer Knowledge Exchange।

Best of Luck,

Vinod Joshi

Tuesday, September 6, 2011

Database Health Check

OS Level:-
1. Check physical memory: free -m
2. Virtual memory: vmstat 5
3. top 10 process : top
4. ps -aux
5. Free volume available df-h, du -csh
6. Filesystem space: Under normal threshold.
7. Check the filesystem OS side
whether the sufficient space is available at all mount points.

Database level: 


1) Check extents / Proactive Space addition:
Check each of the Data, Index and temporary tablespaces for extend and blocks
allocation details.
SET LINES 500
SELECT SEGMENT_NAME,TABLESPACE_NAME, EXTENTS,BLOCKS
FROM DBA_SEGMENTS;

SELECT SEGMENT_NAME,TABLESPACE_NAME,EXTENTS,BLOCKS
FROM DBA_SEGMENTS
WHERE TABLESPACE_NAME=’STAR01D’;

2) Check alert log for ORA- and warning messages:
Checking the alert log file on regulary basis, we have to do. Look for any of the oracle related errors.This will give you the error details and time of occurrence.

Look for the Database level or Tablespace level changes
Monitor the alert log file and search the file for each Day activities happening In the Database either it is bouncing of Database or Increase in the size of the tablespaces ,Increase in the size of the Database parameters. In the 11g database we can look for TNS errors in the alert log file.
1. Wait events
2. Long runing jobs from v$session_longops
3. Invalid objects( if found than compile them)
4. Temp usage / Rollback segment/PGA usage:
5. Redo generation/Archive logs generation details:

Make sure there should not be frequent log switch happening in a Database.

Sunday, July 10, 2011

Common Wait Event Names and What They Mean

Wait EventDescription
buffer busy waitsThe session wants to access a data block that is either 1) currently not in memory, but another process has already issued an I/O request to read the block into memory, or 2) in memory but in an incompatible mode (current versus consistent, for example). For example another session is using that block via an insert, update or delete.
control file parallel writeThe session has issued multiple I/O requests in parallel to write blocks to all control files, and is waiting for all of the writes to complete.
control file sequential readThe session is waiting for blocks to be read from a control file.
db file parallel readThe session has issued multiple I/O requests in parallel to read blocks from data files into memory and is waiting for all requests to complete. This may occur during recovery or during regular activity when a session batches many single block I/O requests together and issues them in parallel.
db file parallel writeThe process, typically DBWR, has issued multiple I/O requests in parallel to write dirty blocks from the buffer cache to disk and is waiting for all requests to complete.
db file scattered readThe session has issued an I/O request to read a series of contiguous blocks from a data file into the buffer cache and is waiting for the operation to complete. This typically happens during a full table scan or fast full index scan. Oracle reads up to DB_FILE_MULTIBLOCK_READ_COUNT consecutive blocks at a time and scatters them into buffers in the buffer cache
db file sequential readThe session has issued an I/O request to read one block from a data file into the buffer cache and is waiting for the operation to complete. This typically happens during an index lookup or a fetch from a table by ROWID when the required data block is not already in memory. This call differs from "db file scattered read" in that a sequential read reads data into contiguous memory (whilst a scattered read reads multiple blocks and scatters them into different buffers in the SGA). 
direct path read,
direct path write
The session has issued asynchronous I/O requests that bypass the buffer cache and is waiting for them to complete. These wait events often involve temporary segments, sorting activity, parallel query or hash joins.
enqueueThe session is waiting on an enqueue (a lock you can see in v$lock). This commonly occurs when one user is trying to update a row in a table that is currently being updated by another user.
free buffer waitsThe session needs a free buffer so it can bring a data block into the buffer cache and is waiting for a buffer that is not dirty to become available. This can occur if DBWR is not writing dirty buffers to disk fast enough.
latch freeThe session is waiting for a latch held by another session. (This event does not apply to processes that are spinning while waiting for a latch; when a process is spinning, it is not waiting.)
library cache load lockThe session is waiting for the opportunity to load an object or a piece of an object into the library cache. (Only one process can load an object or a piece of an object at a time.)
library cache pinThe session wants to pin an object in memory in the library cache for examination, ensuring no other processes can update the object at the same time. This happens when you are compiling or parsing a PL/SQL object or a view.
log buffer spaceThe session is waiting for space in the log buffer. (Space becomes available only after LGWR has written the current contents of the log buffer to disk.) This typically happens when applications generate redo faster than LGWR can write it to disk.
log file parallel writeThe session is waiting for blocks to be written to all online redo log members in one group. LGWR is typically the only process to see this wait event. It will wait until all blocks have been written to all members.
log file sequential readThe session is waiting for blocks to be read from the online redo log into memory. This primarily occurs at instance startup and when the ARCH process archives filled online redo logs.
log file switch completionThe session is waiting for a log file switch to complete, typically so more redo can be generated.
log file syncThe session is waiting for LGWR to finish flushing the log buffer to disk. This occurs when a user commits a transaction. (A transaction is not considered committed until all of the redo to recover the transaction has been successfully written to disk). Probably you are commiting too often
undo segment extensionThe session is waiting for an undo segment to be extended or shrunk.
write complete waitsThe session is waiting for a requested buffer to be written to disk; the buffer cannot be used while it is being written.