This is more a note to myself in case I’ll encounter a similar environment. But maybe it helps others – at least my search results weren’t suitable to Windows in the first place.
C:\> set ORACLE_HOME=C:\path\to\grid\home
C:\> set ORACLE_SID=+ASM1
connected to an idle instance.
Some troubles — especially those happening only sporadically — are not so easy to shoot and call for a deeper understanding of the matter. In the following real-world example this means: SQL*Net Tracing and some knowledge about the inner workings of the server’s operating system, particularly random number generation.
This case was suited well to demonstrate an approach to trouble-shoot connections to Oracle databases.
Sometimes it’s hard to find what you’re looking for in the Oracle documentation or on MOS if you don’t already know what exactly to search for. This happened to me while trying to find out how the method of changing the DB connection for the EM repository changed in 13c. So I thought my findings are worth sharing.
In earlier releases of Enterprise Manager (Grid Control or Cloud Control), connection settings were stored in a file named “emoms.properties”. While this file still existed on the EM 13.2 environment I was working on, there wasn’t any connection string in it.
After searching for quite a while (sifting a wealth of outdated documents), I found out there’s a specific emctl command to set the DB connection. This command already exists since 11g where it had to be used when the repository DB was put in a RAC. Now it seems to be the only way to change the connect string, be it RAC or single instance.
Note to self:
You can export highlighted text (e.g.: SQL code) easily from Notepad++ to RTF and/or HTML using “Plugins” – “NppExport” – “…”. Voilá – there’s highlighted code in your Document, Presentation, Website, a.s.f.!
Also, this: https://sqlandplsql.com/2012/08/11/notepad-tips-and-tricks/
When you have to troubleshoot blocking locks in your Oracle DB, you might be lucky enough to have a GUI tool handy that helps you with that (e.g. Enterprise Manager or TOAD). Otherwise you’ll likely have to resort to Oracle’s pre-installed script “utllockt.sql”. Unfortunately, this script only shows locks in the DB instance it’s running on. However, locks chains may span multiple instances in a clustered environment.
In this brief post I’d like to propose a RAC-aware alternative to “utllockt.sql” using only SQL so it can be run in any Oracle client.
Picture: Mike Gabelmann / flickr / CC-BY-NC-SA
Tim Hall inspired me with his #ThanksOTN (or “OTN Appreciation Day“) campaign to continue my mini-series on leveraging SQL Developer Reports for DBA tasks. Today with visualizing historical System Statistics from Statspack for performance analyses.
#ThanksOTN I have three favourite Oracle features to rave about today:
- Analytic SQL
- SQL Developer (particularly the reports)!
Today I stumbled across a strange error when I tried to run orachk on a customer’s system:
Enter ORACLE_HOME for PRODDB : /opt/oracle/product/rdbms/12.1.0
Could not login to PRODDB using /opt/oracle/product/rdbms/12.1.0. Try again (3 attempts remaining)
Enter ORACLE_HOME for PRODDB :
A quick internet search revealed nothing useful, so I checked MOS. Document 1989401.1 had the right hint: It was due to a customized “login.sql” that had an “ALTER SESSION …” in it. This leads to incorrect results for orachk’s scripts. Disabling login.sql (or glogin.sql, if you use this one) solved the problem.
login.sql can be so evil!
Side note: The Oracle Docs say that “login.sql” is executed from your current directory or from the directory list in $SQLPATH. Neither of that applied to my environment, but ORACLE_PATH was set and pointed to a directory containing login.sql. Looks like this important detail is missing in the docs.