Tuesday, January 18, 2011

Linux / Unix Command: top


top - display top CPU processes


top [-] [d delay] [p pid] [q] [c] [C] [S] [s] [i] [n iter] [b]


top provides an ongoing look at processor activity in real time. It displays a listing of the most CPU-intensive tasks on the system, and can provide an interactive interface for manipulating processes. It can sort the tasks by CPU usage, memory usage and runtime. can be better configured than the standard top from the procps suite. Most features can either be selected by an interactive command or by specifying the feature in the personal or system-wide configuration file. See below for more information.



Specifies the delay between screen updates. You can change this with the sinteractive command.


Monitor only processes with given process id. This flag can be given up to twenty times. This option is neither available interactively nor can it be put into the configuration file.

Monday, January 10, 2011

oraenv or coraenv, ORACLE_HOME, ORACLE_SID & oratab


Oraenv and coraenv are UnixLinux command line utilities that sets the required environment variables (ORACLE_SIDORACLE_HOME and PATH) to allow a user to connect to a given database instance. If these environment variables are not set, commands such as SQL*Plus, imp, exp, or any other utility for that matter, will not work (or not be found).
Use coraenv when using the C Shell and oraenv when using a Bourne, Korn or Bash shell.
Note the syntax: ". oraenv" or {period} {space} oraenv.


$ . oraenv
ORACLE_SID = [] ? orcl
Non-interactive (handy for scripting):
$ export ORACLE_SID=orcl
$ export ORAENV_ASK=NO
$ . oraenv


ORACLE_HOME refers to either:
  1. directory where the Oracle software is installed; or
  2. an environment variable pointing to the directory where the Oracle software is installed.

Check current value:
echo The current ORACLE_HOME is %ORACLE_HOME%
Set the ORACLE_HOME environment variable:
set ORACLE_HOME=C:\oracle\ora10.2

[edit]Unix & Linux

Check current value:
env | grep ORACLE_HOME
Change the ORACLE_HOME environment variable (valid for bash and ksh):
export ORACLE_HOME=/app/oracle/product/10.2.0/db_1


The Oracle System ID (SID) is used to uniquely identify a particular database on a system. For this reason, one cannot have more than one database with the same SID on a computer system.
When using RAC, all instances belonging to the same database must have unique SID's.

[edit]Switching between databases

Set the ORACLE_SID environment variable (or ORA_SID on VMS systems) to work on a particular database. Remember that the SID is case sensitive in Unix / Linux environments.
set ORACLE_SID=orcl
Unix/ Linux:

export ORACLE_SID=orcl


Oratab is a colon-delimited text file on Unix and Linux systems that associates ORACLE_SID and ORACLE_HOME values.
The last field contains a "Y" or "N" for database startup when the machine boots up. One can also use hashes (#) to start comment lines.
This file is either found in the /var/opt/oracle or the /etc directories.
Scripts like oraenvdbhomedbstart and dbshut use the oratab file.

[edit]Sample oratab file

# This file is used by ORACLE utilities.  It is created by root.sh
# and updated by the Database Configuration Assistant when creating
# a database.
# A colon, ':', is used as the field terminator.  A new line terminates
# the entry.  Lines beginning with a pound sign, '#', are comments.
# Entries are of the form:
# The first and second fields are the system identifier and home
# directory of the database respectively.  The third filed indicates
# to the dbstart utility that the database should , "Y", or should not,
# "N", be brought up at system boot time.
# Multiple entries with the same $ORACLE_SID are not allowed.
The above oratab file describes an Oracle instance called orcl (don't confuse this with the database name!) that uses directory /opt/oracle/product/10.2.0/db_1 as its Oracle home. The Yindicates that this database should be started when the system boots up.


           Linux / Unix Command: sudo

sudo - execute a command as another user
sudo -V | -h | -l | -L | -v | -k | -K | -s | [ -H ] [-P ] [-S ] [ -b ] | [ -p prompt ] [ -c class|- ] [ -a auth_type ] [ -u username|#uid ] command

sudo allows a permitted user to execute a command as the superuser or another user, as specified in the sudoers file. The real and effective uid and gid are set to match those of the target user as specified in the passwd file (the group vector is also initialized when the target user is not root). By default, sudo requires that users authenticate themselves with a password (NOTE: by default this is the user's password, not the root password). Once a user has been authenticated, a timestamp is updated and the user may then use sudo without a password for a short period of time (5
minutes unless overridden in sudoers).


Linux has a great program for this called cron. It allows tasks to be automatically run in the background at regular intervals. You could also use it to automatically create backups, synchronize files, schedule updates, and much more. Welcome to the wonderful world of crontab.
The crontab (cron derives from chronos, Greek for time; tab stands for table) command, found in Unix and Unix-like operating systems, is used to schedule commands to be executed periodically. To see what crontabs are currently running on your system, you can open a terminal and run:
sudo crontab -l
To edit the list of cronjobs you can run:
sudo crontab -e
This wil open a the default editor (could be vi or pico, if you want you can change the default editor) to let us manipulate the crontab. If you save and exit the editor, all your cronjobs are saved into crontab. Cronjobs are written in the following format:
* * * * * /bin/execute/this/script.sh

Scheduling explained

As you can see there are 5 stars. The stars represent different date parts in the following order:
  1. minute (from 0 to 59)
  2. hour (from 0 to 23)
  3. day of month (from 1 to 31)
  4. month (from 1 to 12)
  5. day of week (from 0 to 6) (0=Sunday)

Execute every minute

If you leave the star, or asterisk, it means every. Maybe that's a bit unclear. Let's use the the previous example again:
* * * * * /bin/execute/this/script.sh
They are all still asterisks! So this means execute /bin/execute/this/script.sh:
  1. every minute
  2. of every hour
  3. of every day of the month
  4. of every month
  5. and every day in the week.
In short: This script is being executed every minute. Without exception.

Execute every Friday 1AM

So if we want to schedule the script to run at 1AM every Friday, we would need the following cronjob:
0 1 * * 5 /bin/execute/this/script.sh
Get it? The script is now being executed when the system clock hits:
  1. minute: 0
  2. of hour: 1
  3. of day of month: * (every day of month)
  4. of month: * (every month)
  5. and weekday: 5 (=Friday)

Execute on workdays 1AM

So if we want to schedule the script to Monday till Friday at 1 AM, we would need the following cronjob:
0 1 * * 1-5 /bin/execute/this/script.sh
Get it? The script is now being executed when the system clock hits:
  1. minute: 0
  2. of hour: 1
  3. of day of month: * (every day of month)
  4. of month: * (every month)
  5. and weekday: 1-5 (=Monday til Friday)

Execute 10 past after every hour on the 1st of every month

Here's another one, just for practicing
10 * 1 * * /bin/execute/this/script.sh
Fair enough, it takes some getting used to, but it offers great flexibility.

Neat scheduling tricks

What if you'd want to run something every 10 minutes? Well you could do this:
0,10,20,30,40,50 * * * * /bin/execute/this/script.sh
But crontab allows you to do this as well:
*/10 * * * * /bin/execute/this/script.sh
Which will do exactly the same. Can you do the the math? ;)

Special words

If you use the first (minute) field, you can also put in a keyword instead of a number:
@reboot     Run once, at startup
@yearly     Run once  a year     "0 0 1 1 *"
@annually   (same as  @yearly)
@monthly    Run once  a month    "0 0 1 * *"
@weekly     Run once  a week     "0 0 * * 0"
@daily      Run once  a day      "0 0 * * *"
@midnight   (same as  @daily)
@hourly     Run once  an hour    "0 * * * *
Leave the rest of the fields empty so this would be valid:
@daily /bin/execute/this/script.sh

Storing the crontab output

By default cron saves the output of /bin/execute/this/script.sh in the user's mailbox (root in this case). But it's prettier if the output is saved in a separate logfile. Here's how:
*/10 * * * * /bin/execute/this/script.sh 2>&1 >> /var/log/script_output.log


Linux can report on different levels. There's standard output (STDOUT) and standard errors (STDERR). STDOUT is marked 1, STDERR is marked 2. So the following statement tells Linux to store STDERR in STDOUT as well, creating one datastream for messages & errors:
Now that we have 1 output stream, we can pour it into a file. Where > will overwrite the file, >> will append to the file. In this case we'd like to to append:
>> /var/log/script_output.log

Mailing the crontab output

By default cron saves the output in the user's mailbox (root in this case) on the local system. But you can also configure crontab to forward all output to a real email address by starting your crontab with the following line:

Mailing the crontab output of just one cronjob

If you'd rather receive only one cronjob's output in your mail, make sure this package is installed:
aptitude install mailx
And change the cronjob like this:
*/10 * * * * /bin/execute/this/script.sh 2>&1 | mail -s "Cronjob ouput" yourname@yourdomain.com

Trashing the crontab output

Now that's easy:
*/10 * * * * /bin/execute/this/script.sh 2>&1 > /dev/null
Just pipe all the output to the null device, also known as the black hole. On Unix-like operating systems, /dev/null is a special file that discards all data written to it.