Oracle has released E-Business Suite Release 12.1.1, and this is available for download. You may wish to visit Steven Chan's blog at http://blogs.oracle.com/stevenChan/2009/05/ebusiness_suite_release_1211_now_available.html for more information on this.
Oracle has already published Release Content Documents (RCDs) for E-Business Suite Release 12.1.1
Please browse through Metalink document 561580.1 for more details and to browse the RCDs.
Sunday, May 03, 2009
Sunday, April 19, 2009
Sun xVM Virtualbox Tips and Gotchas
Using Sun xVM Virtualbox on a Windows XP SP3 host, I have been able to create a virtual machine with Oracle Enterprise Linux 5 as a guest OS.
Some tips around what I experienced:
(1) To share a folder between host and the guest, you need to have the Virtualbox functionality of "Shared Folders" configured. To configure this, please install the Guest Additions for the Guest OS. (The .iso for this is shipped with Virtualbox, and is available as an .iso file under the Virtualbox directory structure on the Host. It is required to mount this .iso directly under Linux). However, Guest Additions RPM would not get installed upfront.
You need to install gcc and kernel-devel RPMs to make this possible on RedHat / Fedora / OEL distributions.
After the pre-requisite packages have been installed, you need to install the Guest Additions RPM.
Using the Virtualbox GUI, then define a shared folder mapping. (eg. D:\Test to the Host and "Test" on the Guest).
Once shared folder is defined, you can mount the shared folder as follows:
# mount -t vboxsf
eg.
# mount -t vboxsf test /test
vboxsf is a filesystem "type" that is sensed by the guest OS after installation of the Guest Additions. Thereafter, verify by navigating to /test that you're able to browse the contents of the folder.
(2) Making files executable on the shared folder: I have seen that unless mounted explicitly, Virtualbox tends to turn off the "execute" bit for files that are not explicitly identified as "executable" on the host OS. chmod on these files does not fix the issue within Linux. To address this, mount the shared folder as follows:
# mount -t vboxsf -o fmode=777 test /test
More updates to follow.
Some tips around what I experienced:
(1) To share a folder between host and the guest, you need to have the Virtualbox functionality of "Shared Folders" configured. To configure this, please install the Guest Additions for the Guest OS. (The .iso for this is shipped with Virtualbox, and is available as an .iso file under the Virtualbox directory structure on the Host. It is required to mount this .iso directly under Linux). However, Guest Additions RPM would not get installed upfront.
You need to install gcc and kernel-devel RPMs to make this possible on RedHat / Fedora / OEL distributions.
After the pre-requisite packages have been installed, you need to install the Guest Additions RPM.
Using the Virtualbox GUI, then define a shared folder mapping. (eg. D:\Test to the Host and "Test" on the Guest).
Once shared folder is defined, you can mount the shared folder as follows:
# mount -t vboxsf
eg.
# mount -t vboxsf test /test
vboxsf is a filesystem "type" that is sensed by the guest OS after installation of the Guest Additions. Thereafter, verify by navigating to /test that you're able to browse the contents of the folder.
(2) Making files executable on the shared folder: I have seen that unless mounted explicitly, Virtualbox tends to turn off the "execute" bit for files that are not explicitly identified as "executable" on the host OS. chmod on these files does not fix the issue within Linux. To address this, mount the shared folder as follows:
# mount -t vboxsf -o fmode=777 test /test
More updates to follow.
Wednesday, April 15, 2009
Experiments with Sun xVM Virtualbox
I have been recently trying out using Sun xVM Virtualbox to create a paravirtualized machine on my Windows XP based laptop. The Host OS thus remains Windows XP, while the Guest OS that I've installed is Oracle Enterprise Linux 5 (on a portable USB hard-drive).
My objective of configuring this infrastructure is to try out creating a Linux based virtual machine without disturbing the existing Windows XP system, to be able to try out various other (Oracle) software that can be installed on Unix.
I shall post detailed information on configuring this out in my next post.
My objective of configuring this infrastructure is to try out creating a Linux based virtual machine without disturbing the existing Windows XP system, to be able to try out various other (Oracle) software that can be installed on Unix.
I shall post detailed information on configuring this out in my next post.
Sunday, March 29, 2009
Purging Workflow Adhoc Roles
Recently, on one of the Production environments, users started reporting of PO Approvals (through Workflow notifications or through Oracle Purchasing) slowing down. Transaction trace revealed that the bottleneck was one of the queries querying WF_LOCAL_USER_ROLES.
Investigation revealed that workflow purge was not being executed since some time, and as a part of one of the bespoke components (workflows), adhoc roles were being created frequently. Though these were in an "expired" state, the number of rows in WF_LOCAL_USER_ROLES amounted to a whopping 15 million plus !
The solution was obviously to execute "Purge Obsolete Workflow Runtime Data" concurrent program. However, with this amount of data, it was proving to be excessively taxing on undo segments, despite giving chopping off the purgeable data using the "Age" parameter.
With the concurrent program not helpful thus, we resorted to manually executing the following API calls on SQL*Plus prompt to get rid off all the expired roles in the database (replacing XX-YYY-ZZZZ with an oldest date beyond with to purge workflow roles, and then incrementing this date, a day at a time, programmatically, until current date)
SQL> EXEC WF_PURGE.DIRECTORY(to_date('XX-YYY-ZZZZ','DD-MON-RRRR'));
Note: Though the above was executed manually to address a particular scenario, it is strongly advisable to use the seeded concurrent program to purge workflow data, as it purges most of the workflow tables storing non-persistent data.
Investigation revealed that workflow purge was not being executed since some time, and as a part of one of the bespoke components (workflows), adhoc roles were being created frequently. Though these were in an "expired" state, the number of rows in WF_LOCAL_USER_ROLES amounted to a whopping 15 million plus !
The solution was obviously to execute "Purge Obsolete Workflow Runtime Data" concurrent program. However, with this amount of data, it was proving to be excessively taxing on undo segments, despite giving chopping off the purgeable data using the "Age" parameter.
With the concurrent program not helpful thus, we resorted to manually executing the following API calls on SQL*Plus prompt to get rid off all the expired roles in the database (replacing XX-YYY-ZZZZ with an oldest date beyond with to purge workflow roles, and then incrementing this date, a day at a time, programmatically, until current date)
SQL> EXEC WF_PURGE.DIRECTORY(to_date('XX-YYY-ZZZZ','DD-MON-RRRR'));
Note: Though the above was executed manually to address a particular scenario, it is strongly advisable to use the seeded concurrent program to purge workflow data, as it purges most of the workflow tables storing non-persistent data.
Subscribe to:
Posts (Atom)