CPU for July 2012 is available

From the blog  Critical Patch Update for July 2012 Now Available Posted: 17 Jul 2012 01:32 PM PDT The Critical Patch Update (CPU) for July 2012 was released on July 17, 2012. Oracle strongly recommends applying the patches as soon as possible. The Critical Patch Update Advisory is the starting point for relevant information. It includes a list of products affected, pointers to obtain the patches, a summary of the security vulnerabilities, and links to other important documents. Supported products that are not listed in the "Supported Products and Components Affected" Section of the advisory do not require new patches to be applied. Also, it is essential to review the Critical Patch Update supporting documentation referenced in the Advisory before applying patches, as this is where you can find important pertinent information. The Critical Patch Update Advisory is available at the following location: § Oracle Technology Network The next four Critical Patch Update release dates are: § October 16, 2012 § January 15, 2013 § April 16, 2013 § July 16, 2013 E-Business Suite Releases 11i and 12 Reference § Oracle E-Business Suite Releases 11i and 12 Critical Patch Update Knowledge Document (July 2012) (Note 1459818.1)

Five Errors Customers Make When Installing E-Business Suite 12 (Part 1)

Today morning, when I received the mail from blogs.oracle.com, i was really surprised to see the content.. it was really useful.. when considering the client needs, we can consult them with all the possible better ways.. but it is their take and upto them to decide.. this is now the industry stand. Now Oracle provided extra hand to substantiate our recommendations.

Please read the full content.. Full blog from steven chan is here

 

One customer recently asked if we could supply documentation and scripts to remove all the E-Business Suite objects from their database leaving them with an empty database. After a few questions, it became apparent they were concerned about performance and a third party consulting organisation had advised the best solution to performance problems was to export and then import the whole database.

Whilst it’s true an export/import might solve performance problems, there are many other things you can do before you conclude the best solution is an export/import; it’s certainly not the default solution. That’s a pretty extreme example but there are quite a few myths and misunderstandings which seem to crop up regularly in Service Requests.

This is the first in a series of short articles that lists a few of the myths or misunderstandings that seem to have gained a foothold in the wider E-Business Suite community. Each article will deal with a different subject. The first discusses installations; subsequent articles will discuss cloning, patching, migrating, upgrading, and general maintenance. Each article is absolutely not definitive and I’d be particularly interested in comments from readers who think there are other misconceptions about the day to day maintenance and upgrade of a typical E-Business Suite environment.

COMMON ERROR #1: In a global implementation, putting your database tier host in your global data centre and putting local application tier hosts in each country.

ORACLE’S RECOMMENDATION: You must put all host nodes of your E-Business Suite environment in one data centre with the fastest possible network connection between nodes. This applies regardless of the location of your users.

COMMON ERROR #2: Placing concurrent processing services and the database tier on the same node to improve performance.

ORACLE’S RECOMMENDATION: There is no significant performance benefit to placing concurrent processing and the database tier on the same node. Your system will be more scalable if your database tier hardware is dedicated solely to serving the needs of the database. Patching, cloning and E-Business Suite administration will also be much easier as you will have at least one less APPL_TOP and application tier technology stack to maintain. Placing concurrent processing on the database tier node to distribute load might suggest that your application tier hardware is already undersized. You should place concurrent processing on the same nodes as your web/forms services or create a dedicated concurrent processing tier in exceptionally busy environments.

COMMON ERROR #3: Installing only the default database character set although you know that you will need a different character set later.

ORACLE’S RECOMMENDATION: Failing to consider national language support (NLS) and database character set requirements when installing a new environment is a critical mistake. You should normally have a very good idea of language requirements before you start your installation. Implement the correct languages and database character set when you perform your installation. Characters sets can be changed later and languages can also be added but if you think you are going to need them then implement them early in your project. Realising that you have forgotten the purchasing team in Denmark the day before you go live will not make you a popular DBA.

You cannot specify a different character set when upgrading to R12. The R12 upgrade process cannot do a character set conversion.

COMMON ERROR #4: Separating Oracle database and application tier ownership by different operating system users/groups.

ORACLE’S RECOMMENDATION: In simple single node installations the whole E-Business Suite file system (including the database) can be owned by a single user/group. This can simplify installation and maintenance. Oracle documentation and Oracle Support engineers sometimes refer to the ‘applmgr’ user and the ‘oracle’ user. These are generic terms used loosely to describe the operating system owner of the application and database tier file systems respectively – they are not mandatory user names. It is also not mandatory to perform E-Business Suite installations as the root user.

COMMON ERROR #5: Before retrying a failed installation, forgetting to remove its entries from the central inventory.

ORACLE’S RECOMMENDATION: When deleting an E-Business Suite environment, in addition to shutting down and deleting files, you must also remove its entries from the central inventory. The central inventory is a file based repository of all Oracle homes installed on a node. This central inventory may exist outside the E-Business Suite file system and is not always removed when you remove the E-Business Suite file system. If the central inventory contains entries for previously deleted E-Business Suite environments then subsequent new installations may fail.