I have been recently asked to investigate very interesting issue. In short:
Using Fast Recovery Area to let Oracle automatically manage the backup/flashback/recovery related files is very useful, but avoiding problems related with FRA free space shortage requires careful planning. There are several factors that have to be taken into account, apart from the most obvious like
DB_RECOVERY_FILE_DEST_SIZE parameter, there are some additional ones depending on the type of files stored. For example
_MINIMUM_DB_FLASHBACK_RETENTION) affecting flashback logs or archived logs deletion policy which is also taken into account while reclaimable files purging is done.
Case-sensitive passwords were introduced in Oracle Database 11g, causing some misunderstanding and introducing quite a lot of annoying problems for DBAs, even though it was really required to bring level of Oracle’s security to 21st century standards ;). Since then, even more changes were introduced, including for example deprecation of
SEC_CASE_SENSITIVE_LOGON database parameter,
IGNORECASE argument of
ORAPWD tool or password file format change in 12c.
Recently I was working on migrating Oracle 188.8.131.52 database running on Windows, to new hardware infrastructure on Linux. This Oracle version is with us for quite a long time, plus migration from Windows to Linux is quite common (fortunately in that direction…;)), so when I got an error while trying to use Active Duplicate feature to create a standby database, I was quite sure I’ll be able to quickly find the solution either in MOS or elsewhere. Indeed, I found several blog posts with exactly the same error, but solution mentioned there was not working for me.
Today I want to share with you another interesting example of solving performance problem which happened in the database used for Business Intelligence purposes. Users were complaining that the performance in kind of staging database (STGDB) was much better than the production one (PRDDB), even though the dataset was exactly the same.
How often did you have the situation when performance problem disappeared just after refreshing object statistics? Of course it is nice to solve the problem quickly and simply, but is always better to understand what has exactly happened.
The last blog post of Jeff Smith (18.1 Features: SQL Injection Detection) about little, but nice feature of SQL Developer detecting if your PL/SQL code might be vulnerable for SQL Injection, reminded me about the presentation I’ve delivered during Oracle Tutorials at CERN in 2013.