Davis Apps DBA

I'm using 11i(11.5.10.2) EBS in our environment. This is maintained for historical data and not in regular use. So the routine health check or any other formalities are not followed for this instance as we would do for any other normal EBS Instance. Often I'll receive mails from users stating 'Cannot access 11i Instance'. On checking mostly the error will be There are two ways to solve this issue. Method 1: Stop the apache, clear the cache and start the apache server as follows. Once the apache is started, clear the browser cache and try to login. In most cases this workaround will solve the issue. If still you are facing issue even after this workaround, then follow the below given method 2. Method 2: Stop the application services, clear the cache, compile all the jsps, start the application services and try again. Once the jsp compilation is finished, check any application related services are running. If so kill them and start the application services.  Note: Here I ...

 After we cloned our TEST instance, some of the reports(seeded and custom) completed with error. On checking the log file found the below error After a short search found some metalink documents which shed light on this issue. The reason is UTL_FILE_DIR and the environment variable $APPLPTMP are pointing to the same directory but that mount is already used by the grid software in my environment. Insight on the Issue The EBS environment variable $APPLPTMP is set to temporary directory path on the 'Database' node. The $APPLPTMP path is needed only on the Database node and not required on the Application node The $APPLPTMP path needs to be the first path in the UTL_FILE_DIR database parameter. If multiple databases runs on the same host, then use a unique value for this temporary directory(i.e.  All DB should not use the same directory and also the directory should not be owned by a different user. Normally the owner for this directory will be root. ) If there are more than one d...

While tried to generate AWR report for a PDB database, faced an issue. On searching the net and gone through some oracle documents came to know some pre steps needs to done at PDB level to generate a successful AWR report from a PDB database. Issue Faced:   AWR_PDB_DATABASE_INSTANCE     ORA-06512: at line 27 After some search, found the issue was raised as there was no PDB database snapshot was available for AWR report to run. So decided to create the snapshot for PDB. Now the snapshot can be created manually or automatically. Creating PDB Snapshot Manually Creating PDB Snapshot Automatically Creating PDB Snapshot Manually Connect to the PDB database and execute the below procedure to create a snapshot manually. Once created, check the snapshot information. Note: In a normal database snapshot information will be available in the table DBA_HIST_SNAPSHOT but in a PDB database you need to check the table AWR_PDB_SNAPSHOT Now we've created one snapshot but it'll no...

Recently I shut down one of my test database. After 10 mins there is no progress so I decided to check the alert log for any info there. I was surprised to see that the recovery path is filled almost 100%. My TEST database runs in archive mode and the db_recovery_file_dest_size is 20 GB. So I manually deleted some files under the archive location to check if space is freed up so that my DB can go down.  It is not so, since I need to crosscheck the archive logs via RMAN after manual deletion of the same. Now I was trapped with no other option left except for SHUT ABORT . I cancelled my shut immediate and initiated shut abort for the database. DB went down, when I tried to bring up the DB, I was in trouble... facing the ORA-03113 error. Here the thing is my DB can go upto mount state, which means the control file is still intact. Now it is clear that that due to unavailability of space for db_recovery_file_dest the issue persists. So obvious solutions would be  Clearing the arch...