Recently, I bought the Hypersecu HyperFIDO K5 Key to help me secure access to several websites and services with U2F (“Universal Two-Factor Authorization”).
This works fine and easy on Windows, but with Linux things get a little complicated: The key isn’t accessible to all users by default. This has to be activated using udev rules, which is widely documented on the web, but very often erroneous or outdated. Here’s what I found:
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.
tl;dr: The option “-ocmrf” is no longer mandatory nor implemented anymore.
Last week, the quarterly PSU came out, and just a few hours later I tried to apply it to a Oracle Restart + DB system under OL 6.7.
This would have run smoothly if it wasn’t for the fact that this was the first patch for this system and therefore I needed to create a OCM response file for silent patching with “opatchauto”.
Too bad that there was no executable “emocmrsp” unter “./ocm/bin” when I tried to use the latest OPatch-Tool (184.108.40.206.5). WTF?!
Up to Oracle 11.2 it was possible to display archived SQL plans from Statspack using DBMS_XPLAN. I make use of this in some of my scripts and SQL Developer Reports since I first saw this in Christian Antognini’s Book “Troubleshooting Oracle Performance“.
But in 12c (here: 220.127.116.11 on Linux), there’s a piece missing now:
select * from table(dbms_xplan.display(
table_name => 'perfstat.stats$sql_plan',
statement_id => null,
format => 'ALL -predicate -note',
filter_preds => 'plan_hash_value = '|| &&phv
ERROR: an uncaught error in function display has happened; please contact Oracle support
Please provide also a DMP file of the used plan table perfstat.stats$sql_plan
ORA-00904: "TIMESTAMP": invalid identifier
So it looks like STATS$SQL_PLAN wasn’t synchronized to the changes in 12c’s PLAN_TABLE. Maybe because the timestamp wouldn’t make much sense there, anyway, maybe simply because Oracle forgot.
==> Quick and most certainly unsupported workaround:
ALTER TABLE perfstat.stats$sql_plan ADD timestamp INVISIBLE AS (cast(NULL AS DATE));
Another workaround could be to create a separate view with an additional dummy timestamp column an reference the view. I chose to stick with the invisible column solution so I won’t have to create new objects in the DB and change scripts to use these objects.
Hopefully, this will be solved in 12.2 – at least, I had filed an SR / Enhancement Request with Oracle Support.