Tuesday 27 October 2009

FRM-92101: There was a failure in the forms server during startup

Today my client raised a support request as Oracle Forms throws a FRM-92101 error.

FRM-92101: There was a failure in the forms server during startup. This could happen due to invalid configuration. Please look into the web-server log file for details.

I checked and restarted the OAS on command line and was confident that this would have fixed the issue but didn't.

I again restarted the Oracle Application Server(OAS) from the OAS console and Oracle forms were working fine.

So today's lesson i learned is don't rely only on Command line :-)

Wednesday 21 October 2009

Consistent export using datapump

In older export method we can specify consistent=y parameter in export commands or in parameter file for export.

In datapump we can achieve the consistent export using flashback_time parameter as below

expdp system/password@TEST directory=TEST_DIR DUMPFILE=TEST_expfull.dmp full=y LOGFILE=expfull.log FLASHBACK_TIME=\"TO_TIMESTAMP\(to_char\(sysdate,\'DD-MM-YYYY HH24:MI:SS\'\),\'DD-MM-YYYY HH24:MI:SS\'\)\"

Remember to create the directory before executing the expdp command.

Friday 16 October 2009

Oracle Application Server is up but agent shows down

I installed Oracle Enterprise Manager agent on Oracle Application Server. The OAS is listed on the Grid control immediately after installation of the agent. However on the OEM Grid Control the status is shown as down but the Oracle Application Server is up.

I checked the components, all seems to be up on the OAS and also on OEM Grid Control but the server status is shown as down on OEM.

Do you face similar issue? Then here is the solution

1. Go to Agent Home on the Oracle Application Server(OAS)
2. Under AGENT_HOME/sysman/admin/scripts/ and take backup of formsinit.pl file
3. Goto OAS_HOME/sysman/admin/scripts/ and copy the formsinit.pl file
4. Paste the formsinit.pl file to AGENT_HOME/sysman/admin/scripts/
5. Stop and start the agent as below
C:>emctl stop agent
C:>emctl start agent
C:>emctl status agent

Now check the OEM grid control, the OAS status will be up and running...

Thursday 8 October 2009

Oracle Failsafe

Today i got an opportunity to work on Oracle FailSafe... The concept wise i looked it as some what similar to RAC that is virtual IP, clusterware installation, primary and seconday configuration and switching to secondary node for failover etc..

I was initially scared and motivated myself to take it as a challenge and an opportunity to learn something new today on Oracle.

The Oracle FailSafe was so simple mostly uncheck or tick the checkbox, click option button etc.. It is very user friendly and simple but a good fun learning experience.

Thought of sharing one of the task of shutdown and database recovery task with you..

1. Before shutdown of the database, stop the monitoring of the oracle Failsafe.
a. On the failsafe server, Goto start, then programs and Oracle - OfsHome33
b. On the Oracle File Safe Manager, select the Clusters then Server which you need to manage and then expand Cluster Resources
c. Select the database, on the right side, click the policies tab
d. Under Restart Policy, select the option "Do not restart the resources on the current node"
e. And under Failover Policy, uncheck the box for "If the resource fails and is not restarted, failover the group.

Thats it...then all ususal oracle database steps, execute your shutdown command connected to the database using sqlplus.

And recover the database from your backup. Once finished with the database side, donot forget to undo the changes on the Oracle Failsafe.

To enable Oracle Failsafe for the database,

Under Restart Policy as specified above, now select the option, "Attempt to restart the resource on the current node" with your configuration of no of attempts with the seconds.

And also check the box for "If the resource fails and is not restarted, fail over the group".

Done...

Monday 5 October 2009

ORA-00600: [kmgss_activate_granule_1] Database Instance Crash

Today one of our database crashed due to ORA-00600: internal error code, arguments: [kmgss_activate_granule_1].

I have checked the logs and identified that the database was crashed due to dynamic change of the parameter DB_KEEP_CACHE_SIZE.

After execution of the statement

ALTER SYSTEM SET db_keep_cache_size='100M' SCOPE=BOTH;

Internal Errors started appearing on the alert log ORA-00600: internal error code, arguments: [kmgss_activate_granule_1], [], [], [], [], [], [], []

and followed by

MMAN: terminating instance due to error 822

ORA-00822: MMAN process terminated with error.

The above crash can also happen in the database due to bug on Oracle Server Enterprise Edition Version: 10.2.0.1 to 10.2.0.4.

The problem can occur due to dynamic changes of the parameters
DB_KEEP_CACHE_SIZE
DB_RECYCLE_CACHE_SIZE
DB_nK_CACHE_SIZE

The solution suggested by Oracle is to upgrade to 11g or higher releases or to apply 10.2.0.5 patchset.

Error: java.sql.SQLException: ORA-01722: invalid number

Today i received an error on the emoms.trc file on Oracle Enterprise Manager Grid control. The error is:

WARN eml.XMLLoader LoadFiles.680 - Marking the file for retry : 50000909090.xml after receiving exceptionjava.sql.SQLException: ORA-01722: invalid number

2009-10-05 05:00:35,878 [XMLLoader0 500000909090.xml] ERROR eml.XMLLoader markFileAsError.824 - Failed to load 50000909090.xml even after 2 attempts; moving to errors directory. Error: java.sql.SQLException: ORA-01722: invalid number

This is a problem with the OMS Loader. The OMS fails to load xml to repository with an error ORA-01722: invalid number.

This OMS error is a bug in Enterprise Manager Grid Control - Version: 10.2.0.1.0 to 10.2.0.3.0.

The solution is to upgrade the OEM to 10.2.0.4 or 10.2.0.5 by applying the patch. Or apply the verrsion 10.1.0.4.2 of patch 4488715 to fix this particular problem.

I decided to upgrade the OEM to 10.2.0.4.