BizTech Blog

I usually focus on Key Performance Indicators and leading indicators for healthy business growth, but recently I have been working with clients that have experienced outages with their supposed 24x7x365 cloud solutions.  I wanted to share lessons learned with you, and help you ensure you are truly a bullet proof infrastructure in the cloud.

BizTech is proud to report that despite prolonged power outages throughout the region due to severe storm damage and flooding from hurricane sandy, our Managed Services clients experienced zero downtime.

Oracle database’s ORACLE_SID can be renamed using a couple of methods. The first method, which is a tradition method, is to create a new control file using the reuse database flag and give it a new incarnation. Once this is done we can change the values in the external files (sqlnet.ora, tnsnames.ora, init.ora (spfile)) and open the database. From Oracle 9i and beyond Oracle database can be renamed using the dbnewid (or) nid utility. In this post, we will go through the steps to rename the database using the nid utility.

• Backup the database (Always a good practice before any changes are made).
• Start the database in mount state (do not open it).
• Invoke the dbnewid utility

nid TARGET=sys/password@<CURRENT_ORACLE_SID> DBNAME=<NEW_ORACLE_SID>

Oracle has de-supported Hyperion Business Rules (HBR) in the 11.1.2.2 release. Customers with HBR in the previous releases need to migrate them to Calc Manager in 11.1.2.2. Support Doc (MetaLink Doc) ID 1448421.1 - Hyperion Business Rules Statement of Direction - has an attachment that provides an overview of the changes in availability of Hyperion Business Rules. This document would help you assess any impact to your current implementation, and to plan future decisions related to integration with the Oracle's Hyperion suite of products. The steps for migrating from Business Rules to Calc Manager depends on your specific installation type and can be found in - http://docs.oracle.com/cd/E17236_01/epm.1112/epm_install_1112200.pdf ( Page 22,23)

When Fusion Middleware Applications are installed there is a default user (weblogic or a specific name that you provide) that is created during the domain creation which acts as a super user for all Middleware Applications. This post walks through the process of resetting the weblogic password in an event that it’s lost.

1. Shutdown Weblogic Server and all associated applications.
2. Set the Weblogic Server environment variables –
   $DOAMIN_HOME/bin/setDomainEnv.sh
3. Navigate to $DOMAIN_HOME/security and rename the DefaultAuthenticatorInit.ldift file.
4. Create an initialization file in the same directory using the below command –
   java weblogic.security.utils.AdminAccount <weblogic_user_name> <weblogic_password> .
5. This will create a new DefaultAuthenticatorInit.ldift file.
6. Navigate to $DOMAIN_HOME/servers/AdminServer and rename the data directory.
7. Repeat step 6 for all the managed servers which are part of the domain.
8. If boot.properties is used, recreate them with the username and password that was provided in Step 4.
9. Start Admin Server and make sure you can login using the new credentials.
10. Start the rest of the services

Note: This process will remove all the user accounts in the weblogic domain and only the new user that is created will be present and act as a super user.

Oracle finally released a reporting tool that reports on the differences in E-Business Suite database objects between one release and another. That's a very useful reference to Tech users to understand EBS dictionary at a module level, but EBS defaults are delivered as seed data within the database objects themselves. What about the differences in this seed data between one release and another?

Disaster Recovery (DR) is the process an organization uses to recover access to their data, software, hardware that are needed to resume business critical applications after the event of either a natural disaster or planned caused by humans. When a disaster occurs, the Disaster Recovery plan’s aim is to restore an acceptable level of operations with an acceptable recovery time objects. The overall goal of a Disaster Recovery plan is to minimize downtime in the event a disaster occurs.

Disaster Recovery Plans are generally part of a larger, more extensive practice known as Business Continuity Planning. DR plans should be well practiced so that the Business owners are familiar with the specific actions they will need to take should a disaster occur. DR plans must also be adaptable and routinely updated. Apart from the business critical applications availability, The most important component is human capital which is often overlooked by most corporations. Companies tend to assume that their staff will always be available. When a disaster occurs, sickness, disability of a key employee, or even a death, can have a devastating effect on a business. Business needs and the threats to business are constantly changing. New Customers, and software applications as well as changes to Infrastructure components affect Disaster Recovery plan. It is a good practice to update Disaster Recover Plans anytime a significant change is made to critical business process or the IT infrastructure that supports them. At a minimum, its recommended to test and update disaster Recovery plans on an annual basis.