Troubleshooting

A colleague faced this while running FMW installer on a Linux machine. The display appeared like this This thread gave a clue that it could have something to do with fonts. So I checked what all fonts related stuff was installed. [bash][root@someserver ~]# rpm -aq |grep -i font stix-fonts-1.1.0-5.el7.noarch xorg-x11-font-utils-7.5-20.el7.x86_64 xorg-x11-fonts-cyrillic-7.5-9.el7.noarch xorg-x11-fonts-ISO8859-1-75dpi-7.5-9.el7.noarch xorg-x11-fonts-ISO8859-9-100dpi-7.5-9.el7.noarch xorg-x11-fonts-ISO8859-9-75dpi-7.5-9.el7.noarch libXfont-1.5.2-1.el7.x86_64 xorg-x11-fonts-ISO8859-14-100dpi-7.5-9.el7.noarch xorg-x11-fonts-ISO8859-1-100dpi-7.5-9.el7.noarch xorg-x11-fonts-75dpi-7.5-9.el7.noarch xorg-x11-fonts-ISO8859-2-100dpi-7.5-9.el7.noarch libfontenc-1.1.3-3.el7.x86_64 xorg-x11-fonts-ethiopic-7.5-9.el7.noarch xorg-x11-fonts-100dpi-7.5-9.el7.noarch xorg-x11-fonts-misc-7.5-9.el7.noarch fontpackages-filesystem-1.44-8.el7.noarch fontconfig-2.10.95-11.el7.x86_64 xorg-x11-fonts-ISO8859-2-75dpi-7.5-9.el7.noarch xorg-x11-fonts-ISO8859-14-75dpi-7.5-9.el7.noarch xorg-x11-fonts-Type1-7.5-9.el7.noarch xorg-x11-fonts-ISO8859-15-75dpi-7.5-9.el7.noarch [root@someserver ~]#[/bash] ...

Got this while trying to install 11.2.0.4 RAC on Redhat Linux 7.2. root.sh fails with a message like [sql]ohasd failed to start Failed to start the Clusterware. Last 20 lines of the alert log follow: 2017-11-09 15:43:37.883: [client(37246)]CRS-2101:The OLR was formatted using version 3.[/sql] This is bug 18370031. Need to apply the patch before running root.sh.

Scenario : Setting up a physical standby from Exadata to a non-Exadata single instance. tnsping from standby to primary works fine but tnsping from primary to standby fails with: [sql]TNS-12543: TNS:destination host unreachable[/sql] I am able to ssh standby from primary, can ping as well but tnsping doesn’t work. From the error description we can figure out that something is blocking the access. In this case it was iptables that was enabled on the standby server. ...

A rather not so great post about an ORA-00600 error i faced on a standby database. Environement was 11.2.0.3 on Sun Super Cluster machine. MRP process was hitting ORA-00600 while trying to apply a specific archive log. The error message was something like this MRP0: Background Media Recovery terminated with error 600 Errors in file /u01/app/oracle/product/11.2.0.3/diag/diag/rdbms/xxxprd/xxxprd1/trace/xxxprd1_pr00_6342.trc: ORA-00600: internal error code, arguments: [2619], [539], [], [], [], [], [], [], [], [], [], [] Recovery interrupted! Some googling and MOS searches revealed that the error was due to corrupted archive log file. Recopying the archive file from primary and restarting the recovery resolved the issue. The fist argument of the ORA-600 is actually the sequence no of the archive it is trying to apply. ...

There was an interesting issue at one of the customer sites. Few tables in the database were altered and the dependent objects became invalid. But the attempts to compile the objects using utlrp.sql or manually were failing. In all the cases it was giving the same error: SQL> alter function SCOTT.SOME_FUNCTION compile; alter function SCOTT.SOME_FUNCTION compile * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 1 ORA-01422: exact fetch returns more than requested number of rows ORA-06512: at line 27 SQL> At first look it sounded like some issue with the dictionary as the error in case of every object (be it a view, function or package) was the same. ...

Came across this small oddity that documentation of 10.2 and 11.2 states that expdp by default takes consistent image of the database. But actually it is not so. You need to use flashback_scn/flashback_time for that. Metalink doc 377218.1 explains the scenario. Comments Comment by Chris Fischer on 2011-11-04 19:47:12 +0530 I’ve been warning my customers about this for years. “Shut down all db access before taking a schema or full expdp!” ...

It was a 10g (10.2.0.5 on HP-UX 11.23 RISC) database which was recently upgraded from 9.2.0.8. The CPU and memory utilization was going really high. After tuning few of the queries coming in top, CPU usage was coming within accetable limits but the memory usage was still high. There was a total of 16 GB of RAM on the server and the usage was above 90%, constantly. One of the reasons behind high usage was increase in the SGA size. It was increased from 2.5 GB (in 9i) to around 5 GB (in 10g). Another major chunk was being eaten by OS buffer cache. While looking at the memory usage with kmeminfo:[bash]Buffer cache = 1048448 4.0g 25% details with -bufcache[/bash] ...

Very simple issue but took some amount of time in troubleshooting so thought about posting it here. May be it proves to be useful for someone. Scenario was: Oracle is installed from “oracle” user and all runs well. There is a new OS user “test1” that also needs to use sqlplus. So granted the necessary permissions on ORACLE_HOME to test1. Tried to connect sqlplus scott/tiger@DB and yes it works. But while trying sqlplus scott/tiger it throws: ...

Some time back, I was at a client where the customer complained that no one was able to log in to the database. It was Oracle 10.2.0.4 running on HP-Ux. I logged in to the database and checked the wait events: [sql]SQL> @wait EVENT COUNT(*) ---————————————————————- ———- wait for possible quiesce finish 1 Streams AQ: qmn coordinator idle wait 1 Streams AQ: qmn slave idle wait 1 Streams AQ: waiting for time management or cleanup tasks 1 SQL*Net message to client 1 smon timer 1 pmon timer 1 jobq slave wait 4 rdbms ipc message 11 SQL*Net message from client 27 resmgr:become active 322 ...

Last week I had a chance to upgrade a 9.2.0.7 database to 10.2.0.5. The size of the database was around 800 GB. The major applications connecting to the database were developed in Pro*C and Oracle Forms. The upgrade itself pretty smooth but there were few glitches around that needed to be handled. Just thought about documenting all the issues: Few users in the database were assigned the CREATE SESSION privilege through a password protected role (That role was the default role for that user). 10.2.0.5 onwards, password protected roles can’t be set as default roles. The alternate is to either disable the password for the role or assign CREATE SESSION directly to the user, not through a role. ...