Archive | May 2011

Send Email using Oracle Database


The UTL_MAIL package provides a simple API to allow email to be sent from PL/SQL. The package is loaded by running the following scripts.

CONN sys/password AS SYSDBA

In addition the SMTP_OUT_SERVER parameter must be set to identify the SMTP server.


With the configuration complete we can now send a mail.

UTL_MAIL.send(sender     => '',
recipients => ',',
cc         => '',
bcc        => '',
subject    => 'UTL_MAIL Test',
message    => 'If you get this message it worked!');

The package also supports sending mails with RAW and VARCHAR2 attachments.

Why Oracle Scheduler Jobs not running?

This is one of the most common Scheduler questions asked.
Here we list some of the common problems and their solutions.
1) job_queue_processes may be too low (this is the most common problem)
The value of job_queue_processes limits the total number of dbms_scheduler
and dbms_job jobs that can be running at a given time.
To check whether this is the case check the current value of
job_queue_processes with
SQL> select value from v$parameter where name='job_queue_processes';
Then check the number of running jobs
SQL> select count(*) from dba_scheduler_running_jobs;
SQL> select count(*) from dba_jobs_running;
If this is the problem you can increase the parameter using
SQL> alter system set job_queue_processes=1000;

2) max_job_slave_processes may be too low
If this parameter is not NULL then it limits how many dbms_scheduler jobs can
be running at a time. To check whether this is the problem, check the current
value using
SQL> select value from dba_scheduler_global_attribute
where attribute_name='MAX_JOB_SLAVE_PROCESSES';

Then check the number of running jobs
SQL> select count(*) from dba_scheduler_running_jobs;

If this is the problem you can increase the number or just NULL it out using
SQL> exec dbms_scheduler.set_scheduler_attribute('max_job_slave_processes',null)

3) sessions may be too low
This parameter limits the number of sessions at any time. Every Scheduler job
requires 2 sessions. To check whether this is the problem, check the current
valule using
SQL> select value from v$parameter where name='sessions';
Then check the current number of sessions using
SQL> select count(*) from v$session ;

If the numbers are too close you can increase the maximum using
SQL> alter system set job_queue_processes=200;

4) Have you recently applied a timezone update patch or upgraded the database
to a version with newer timezone information ? If you skipped any steps when
updating the timezone information, jobs may not run. To check whether this
is the case try doing
SQL> select * from sys.scheduler$_job;
SQL> select * from sys.scheduler$_window;
and make sure they finish without errors.

If it throws a timezone warning, reapply the upgrade or
timezone patch making sure to follow all the steps.

5) Is the database running in restricted mode ?
If the database is running in restricted mode then no jobs will run (unless
you are using 11g and use the ALLOW_RUNS_IN_RESTRICTED_MODE attribute).
To check this use
SQL> select logins from v$instance ;

If logins is restricted you can disable the restricted mode using

6) Is the job scheduled to run on an instance which is down ?

You can check this by seeing whether instance_id is set for the job (check the dba_scheduler_jobs view), and if so you should check whether that instance is up.

7) Is the job scheduled to run on a service which has not been started on any instances ?

You can check this by checking what job_class a job points to and then checking whether that class points to a service. If it does, make sure the service has been started on at least one running instance. You can start a service on an instance using dbms_service.start_service.

8 ) Is the Resource Manager in effect with a restrictive resource plan ?

If a restrictive resource plan is in effect, scheduler jobs may not have sufficient resources allocated so they may not run. You can check what resource plan is in effect by doing

SQL> select name from V$RSRC_PLAN ;

If no plan is in effect or the plan in effect is INTERNAL_PLAN then the resource manager is not in effect. If the resource manager is in effect you can disable it by doing

SQL>alter system set resource_manager_plan = '';
9) Has the Scheduler been disabled ? This is not a supported action
but it is possible that someone has done it anyway. To check this do
SQL> select value from dba_scheduler_global_attribute where attribute_name='SCHEDULER_DISABLED'

If this query returns TRUE then you can fix this using
SQL> exec dbms_scheduler.set_scheduler_attribute('scheduler_disabled','false');

Reasons why jobs may run late

1) The first thing to check is the timezone that the job is scheduled with
SQL> select owner, job_name, next_run_date from dba_scheduler_jobs ;

If the jobs are in the wrong timezone they may not run at the expected
time. If the next_run_date is using an absolute timezone offset (like
+08:00) instead of a named timezone (like US/PACIFIC) then the jobs may not
run as expected if daylight savings is in effect – they may run an hour
early or late.

2) It may be that at the time the job was scheduled to run, one of the several
limits above may have been temporarily reached causing the job to be delayed.
Check if the limits above are high enough and if possible check them during
the time that the job is being delayed.

3) One possible reason that one of the above limits may be hit is that a
maintenance window may have come into effect. Maintenance windows are Oracle
Scheduler windows that belong to the window group named
MAINTENANCE_WINDOW_GROUP. During a scheduled maintenance window, several
maintenance tasks are run using jobs. This may cause one of the limits listed
above to be hit and user jobs to be delayed. See the admin guide for more info
about this (chapter 24).

To get a list of maintenance windows use
SQL> select * from dba_scheduler_wingroup_members;

To see when the windows run use
SQL> select * from dba_scheduler_windows;

To fix this you can either increase the limits or reschedule the maintenance
windows to run at more convenient times.

Diagnosing other Problems

If none of this works, here are some further steps you can take to try to
figure out what is going on.

1) Check whether there are any errors in the alert log. If the database is
having trouble allocating memory or has run out of disk space or any other
catastrophic errors have occurred, you should resolve those first. You can
find the location of the alert log by using
SQL> select value from v$parameter where name = ‘background_dump_dest’;
The alert log will be in this directory with a name starting with “alert”.

2) Check whether if a job coordinator trace file and if it does, check if it
contains any errors. If this exists, it will be located in the
‘background_dump_dest’ directory which you can find as above and will look
something like SID-cjq0_nnnn.trc . If there are any errors here they may
hint at why jobs are not running.

3) If either of the above indicates that the SYSAUX tablespace (where the scheduler stores its logging tables) is full, you can use the dbms_scheduler.purge_log procedure to clear out old log entries.

4) See if there is a window currently open. If there is, you can try closing it to see if that helps .

5)try running a simple run-once job and see if it runs
dbms_scheduler.create_job (
job_name => 'test_job',
job_type => 'plsql_block',
job_action => 'null;',
enabled => true);
SQL> -- wait a while
SQL> select * from user_scheduler_job_run_details where job_name='TEST_JOB';

6) If a simple run-once job doesn’t run, you can try restarting the scheduler as follows.

SQL> exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'TRUE');
SQL> alter system set job_queue_processes=0;
SQL> exec dbms_ijob.set_enabled(FALSE);
SQL> alter system flush shared_pool;
SQL> alter system flush shared_pool;
SQL> exec dbms_ijob.set_enabled(TRUE);
SQL> alter system set job_queue_processes=99;
SQL> exec dbms_scheduler.set_scheduler_attribute('SCHEDULER_DISABLED', 'FALSE');


Oracle 11gR2: export utility doesn’t export empty tables

In Oracle 11g release 2, there are new feature to save disk spaces. There is a new database parameter in Oracle Database 11gR2, DEFERRED_SEGMENT_CREATION. Initially this parameter is set to TRUE. This parameter affect the export utility when exporting schema. The problem is that empty tables will not get exported by conventional export utility. For Export using Data Pump there is no problem with empty tables.

To disable this feature, you need to change the parameter to false:

SQL> alter system set DEFERRED_SEGMENT_CREATION=FALSE scope=both;

Then you need to move the tablespace of the empty tables or recreate the tables, so that Oracle will recognize the new created segment.

Monitoring Network Performance on Solaris using nicstat

To Monitor your Network performance on Linux or Solaris, you can use nicstat. It can provide data like packet per second, Kb per second, and utilization.

bash-3.00$ nicstat -i mac 1
Time       Int   rKb/s   wKb/s   rPk/s   wPk/s    rAvs    wAvs   %Util     Sat
09:29:51   mac   43.40   29.09  215.73  187.62  206.01  158.76    0.06    0.00
09:29:52   mac  912.04 1027.16 7157.00 7097.00  130.49  148.20    1.59    0.00
09:29:53   mac 1010.37 1133.48 7912.00 7829.00  130.77  148.25    1.76    0.00
09:29:54   mac  925.65 1044.82 7287.00 7197.00  130.08  148.66    1.61    0.00
09:29:55   mac 1018.24 1140.09 7978.00 7901.00  130.69  147.76    1.77    0.00
09:29:56   mac  962.31 1081.12 7542.00 7463.00  130.66  148.34    1.67    0.00
09:29:57   mac 1008.47 1130.27 7907.00 7835.00  130.60  147.72    1.75    0.00

To install nicstat:

  1. Download nicstat from here or here.
  2. Extract the zip file (if you download the zip file).
  3. Compile the nicstat.c using gcc
    /usr/sfw/bin/gcc nicstat.c -o nicstat -lkstat -lgen -lsocket -lrt
  4. it will create nicstat (executable) in the current directory.
  5. now you can start using nicstat. Just set your PATH environment variable to the nicstat directory.


Manusia seperti Sebuah BUKU

Manusia seperti Sebuah BUKU…. Cover depan adalah tanggal lahir. Cover belakang adalah tanggal kematian. Tiap lembarnya, adalah tiap hari dalam hidup kita dan apa yg kita lakukan. Ada buku yg tebal, ada buku yg tipis. Ada buku yg menarik dibaca, ada yg sama sekali tidak menarik. Sekali tertulis, tidak akan pernah bisa di’edit’ lagi. Tapi hebatnya, seburuk apapun halaman sebelumnya, selalu tersedia halaman selanjutnya yg putih bersih, baru dan tiada cacat. Sama dengan hidup kita, seburuk apapun kemarin, Allah selalu menyediakan hari yang baru untuk kita. Kita selalu diberi kesempatan baru untuk melakukan sesuatu yg benar dalam hidup kita setiap harinya. Kita selalu bisa memperbaiki kesalahan kita dan melanjutkan alur cerita kedepannya sampai saat usia berakhir, yang sudah ditetapkanNYA.

Terima kasih Allah utk hari yg baru ini.. Syukuri hari ini…. dan isilah halaman buku kehidupanmu dgn hal2 yg baik semata. Dan, jangan pernah lupa, untuk selalu bertanya kepada Allah, tentang apa yang harus ditulis tiap harinya. Supaya pada saat halaman terakhir buku kehidupan kita selesai, kita dapati diri ini sebagai pribadi yg berkenan kepadaNYA. Dan buku kehidupan itu layak untuk dijadikan teladan bagi anak2 kita dan siapapun setelah kita nanti. Selamat menulis di buku kehidupanmu, Menulislah dengan tinta cinta dan kasih sayang, serta pena kebijaksanaan. Aku berdoa dan berharap : “agar Allah selalu menyertai setiap langkahmu” ……….karena…….. ‎​​Allah tidak pernah menjanjikan bahwa langit itu selalu biru, Bunga selalu mekar, dan Mentari selalu bersinar.. Tapi ketahuilah bahwa Dia selalu memberi pelangi di setiap badai, Senyum di setiap air mata, Berkah di setiap cobaan, dan jawaban di setiap do’a. Jangan pernah menyerah, Terus berjuanglah.

– from a good friend, L.S. –

JVM Monitoring and Management Using JMX

This steps will allow you to monitor your JVM using JMX for JAVA 1.5

  1. Go to $JRE_HOME/lib/management
  2. copy jmxremote.password.template and rename to jmxremote.password
  3. change the file mode so it can be edited.
  4. edit the jmxremote.password file. uncomment the setting for password at the bottom of the file.
    monitorRole  QED
    controlRole   R&D
  5. these roles must exist in jmxremote.access file.
  6. add these option to your JVM JAVA_OPTIONS parameter<port-number> will allow you to monitor your JVM from remote machine. will allow you to not using SSL (they need more settings)<port-number> is the port number to connect to JMX
  7. Now you can monitor you JVM using jconsole. You should have jconsole if you have jdk installed on your machine. Just and the JAVA_HOME and add JAVA_HOME/bin to you PATH. Then run this command:
    jconsole ip-address:port
  8. Go to remote tab and insert your username and password (for example monitorRole  QED)

Now you can monitor your JVM from your local machine.

For complete documentation you can read here: