I had this exact same situation recently during a data conversion process. I needed a way to insert all the good records into a table, and identify those that failed.

My initial approach was to place the inserts in a for loop, wrapping the insert statement in its own block. When an exception is raised, it will be recorded and control will pass to the encompassing block allowing the loop to continue:

For i in 1..pi_employee_data.last loop
  Begin
    Insert into new_employees values pi_employee_data(i);
  Exception
    When others then
      dbms_output.put_line('Insert data '||SQLERRM
                           ||' Employee#'||pi_employee_data(i).employee_id);
  End;

End loop;

commit;

Now, this is all well and good. But what if you want to stick to “best practice” and use bulk statements. I’d been making use of collections, so using a forall statement seemed a better approach. Problem being, you can’t wrap the insert statement into its own SQL block. This is where SQL%BULK_EXCEPTIONS comes in.

Note the addition of ‘save exceptions’ to the following forall statement. If any exceptions are encountered when inserting into the new_employees table, they will be saved to the SQL%BULK_EXCEPTIONS object. Only when the forall statement is finished will the exception handler be called. We’re then free to extract any data regarding the particular record that caused the exception.

function insert_data (pi_employee_data in employee_records)
  return varchar2 is

  l_no_errors number;
  dml_errors  exception;

  PRAGMA EXCEPTION_INIT(dml_errors, -24381);

begin

  forall i in 1..pi_employee_data.count save exceptions
      insert into new_employees values pi_employee_data(i);

  commit;

exception
    when dml_errors then
      l_no_errors := SQL%BULK_EXCEPTIONS.count;
      for i in 1 .. l_no_errors loop
        dbms_output.put_line('Bulk insert error: '||
           SQLERRM(-1 * SQL%BULK_EXCEPTIONS(i).ERROR_CODE)||
           ' Employee:'||
           pi_employee_data(SQL%BULK_EXCEPTIONS(i).ERROR_INDEX).employee_id);
      end loop;

    when others then
      dbms_output.put_line('Error:'||SQLERRM||
         ' '||dbms_utility.format_error_backtrace);

end;

As mentioned in a recent article by Tim Place, knowing the problem is one thing, knowing where to find the solution is the other. Using the Oracle documentation and having an idea which keywords to use when looking for a solution makes problems such as the above that much easier.

Conincidently, SQL%BULK_EXCEPTIONS also made an appearance in one of Steve Feuerstein’s talks at the recent InSync conference in Melbourne. As anyone who’s seen Steve before will know, collections and bulk operations should be two of the staples of any piece of PL/SQL code you write. Now with SQL%BULK_EXCEPTIONS, you’ll be able to use them much more effectively.

Have you ever had your system show the wrong time, scheduled jobs in Alesco or Oracle not run when they’re meant to, or seen conflicting reports of what the current time is in different applications on the one system?

Well, I did recently while administering one of our client’s Alesco environments. The trace outputs for their Alesco reports were showing conflicting runtimes. Surprise, surprise there was an hour difference, and daylight savings was to blame.

Off the top of my head, there were only two places the times could be incorrect:

• on the database, and
• on the application server

So, I logged in and checked the database time. All good on that front.
Next, I logged into the application server and checked the system time. That was correct as well.

It seemed that my assumption was incorrect, there was a third place the time could be incorrect, in the Oracle Application Server software. A quick visit to the Oracle Application Server Control Console confirmed this. It turns out the Oracle Application Server software doesn’t use the underlying system’s timezone settings.

Metalink, the Oracle forums and Google were the next ports of call. After a lot of digging (the majority of timezone information I came across dealt with Oracle Databases, not Oracle Application Servers), I discovered that the problem was not specifically with Oracle. Both the Oracle Application Server Control Console and the Oracle Reports Server are Java apps, and it was the Java Runtimes they were using that were causing the timezone issue.

Java (along with Unix/Linux) measures time in milliseconds from January 1st 1970. Once this number has been converted into a human readable time, the timezone adjustments are applied. In Unix/Linux, these timezone settings can be found under /usr/share/zoneinfo (or /usr/share/lib/zoneinfo on some systems). However Java won’t use this system timezone database, it uses it’s own.

Inside your Oracle home, there are a number of java executables. Executing java -version told me I was on 1.4.2_12. A quick comparison with the Java Timezone Data Versions showed this release did not include the Australian 2008 timezone changes. Luckily Sun provides the Timezone Updater Tool to bring us up to speed.

Once you’ve downloaded and unzipped the tool, you can update a single JRE/JDK with the following command:

> java -jar tupdater.jar -U -v

This assumes the java executable is in the home you want to update (type which java to check)

As I said, there’s multiple JRE/JDK homes in the Oracle Application Server homes, so why not update them all at the one time:

> /usr/bin/find DIRPATH -fstype nfs -prune -o -fstype autofs -prune
-o -name java -print -exec {} -jar /ABSOLUTEPATH/tzupdater.jar -u \;

Then it was just a matter of bouncing the Oracle processes again.

Ta-da, the times are now correct.

Note
I did receive a number of warnings when updating the timezone. It turns out they were Solaris specific and could be ignored, eg:

Q.
I get the following message after running the TZ Updater Tool v1.1.0 on Solaris, what does it mean?

/jre/bin/java not directly found in contents file, no package resolution performed.
(May not be in PKG form, not an absolute path, or is a symlink.)

A.
This message indicates that the JDK/JRE software just updated was not part of a Solaris package. No step was necessary to update the OS with the fact that files under package management have changed, that is, jre/lib/zi directory contents. The update of the timezone data has been successful in this case.

Organisations face increasing demand to automate complex business processes that span multiple back office systems and can adapt to change. Historically deploying complex workflows was tough – developing interfaces, customising the application, and developing software to schedule and monitor the process. If the process changed, this required more effort…

Fortunately Oracle has solutions for integrating applications to manage complex processes.

Talent2′s Alesco HRIS provides an inbuilt workflow solution to cater for the common business transaction process flow. Customers often require tailored process solutions that suit their individual business requirements. The use of additional Workflow products allow customers to tailor the Workflow process without the need for customizations.

This white paper looks at the two major business process management tools from Oracle and how they can be used with Alesco’s Web Kiosk.

A major feature of Open World was the latest database release, 10g, with features including Grid computing (the g in 10g). Grid computing is basically clusters of cheap servers acting as one virtual server sharing disk space. This reduces the single point of failure and also allows the application to be easily scaled in terms of CPU and memory. Other nice features in 10g is the self managing and tuning of the database, aimed at making it easier to administer and troubleshoot – watchout DBA’s.

A strong message given at Open World was Oracle’s support and encouragement for running the Linux operating system on Intel hardware, a combination referred to as Lintel. Oracle develops on and runs the majority of their internal apps on Lintel and is talking up the combination for clients. Dell has also started selling servers bundled with Red Hat Linux and Oracle 10g at very low prices.

Within the Alesco community there is already a number of sites successfully running Linux, a supported platform on the e807 version of Alesco.

If you’re thinking of moving to Linux for your Alesco install, here’s a couple of reasons why you should:

Lower TCO for existing UNIX sites

Those sites with proprietary UNIX environments (HP, AIX, Solaris) should be able to lower their TCO with a move to Linux and Intel. Existing staff skilled in UNIX require minimal training to move to Linux. Custom programs and tools that have been written should migrate with no effort. It’s a fair bet that most UNIX techs have already experienced Linux and have installed it on a server somewhere in your organisation!

Replicating your production instance for testing and development environments can also be achieved using nothing more than desktop PC’s running Linux.

More bang for your buck

The experiences Navigo has had running Alesco on Linux and Intel all point to quicker report processing times. Previously Intel had been disadvantaged by the 32 bit architecture, meaning SGA’s for database could not grow beyond 4gb. Now with the release of 64 bit architecture, Intel can now compete with the proprietary UNIX servers.

At the recent benchmark for the PNG Government, we processed 66,000 employees in under 3 hours. This was on a cluster of two 4CPU Intel Itanium Servers with 64 bit Red Hat Linux with a 7GB SGA. The payrun was split into 8 streams using the standard Alesco functionality which balanced nicely across the CPU’s.

With a cluster of Intel servers being considerably cheaper, sometimes one-tenth that of proprietary UNIX vendors, the cost savings to organisations are substantial.

Simplify the support process

Different flavours of UNIX, multiple versions of the OS, multiple versions of Oracle. Most sites have probably experienced certification problems and Oracle/Alesco bugs that only appear in their version/flavour of UNIX. Sometimes even trying to get a copy of the Oracle software for that version is a nightmare.

Running Linux, sites benefit from strong Oracle support for Linux issues and the availability of Oracle software on the OTN website.

For the Alesco application, more sites running the one operating system allows for quicker identification and resolution of Alesco/Oracle issues and simplifies the compatibility problems.

Come upgrade time, Alesco sites also benefit from the testing that more pro-active sites have already performed on the latest Alesco/Oracle combination.

For most organisations the challenge is reduce IT costs and deliver “unbreakable” systems. Running Alesco on a Lintel platform is certainly a step in the right direction.

For more info about Oracle on Linux see Oracle’s Linux FAQ