Tag Archives: database

Scary Oracle security issues – patch now!

Larry Ellison announced the self-patching database at OpenWorld this year. Until we get to that point, professional DBAs and system administrators need to keep their Oracle environments secure.

Right now, that means at least installing the patches Oracle provides quarterly in the Critical Patch Updates (CPUs). The latest from October 2017 is one of the scariest I have seen for a while. Out of a total of 251 issues, 156 can be remotely exploited without authentication. Everyone who is or can get behind your firewall can use them against you.

If you are running any of the following, you urgently need to install the October CPU:

  • Oracle Database
  • WebLogic Server
  • SOA Suite
  • WebCenter Content
  • Oracle Access Manager
  • GlassFish
  • BI Publisher
  • Oracle BPM
  • MySQL
  • VirtualBox

To nobody’s surprise, there are also newly discovered bugs in Java SE – 22 this time, of which 20 can be remotely exploited without authentication.

Most of the Oracle applications also have serious issues, including Oracle E-Business Suite, Hyperion, JD Edwards, PeopleSoft, and Siebel.

Stay safe. Patch your systems.

 

Don’t miss out on important information you need as an IT professional working with Oracle products. Sign up for the Oracle Tool Watch newsletter and get the free whitepaper “What Oracle is Doing Wrong (and Right) in the Cloud”

Matching Your Database to Your Application

I’ve just been troubleshooting an ADF application that ran fine on one environment and not on another. After some searching, I discovered that a script had not been run on one of the environments so the database was different.

That reminded me of a simple database check that I often include in my applications: I simply calculate a hash value of all tables and views with an SQL statement like this:

select sum(
ora_hash(table_name)
+ ora_hash(column_name)
+ ora_hash(data_type)
+ ora_hash(data_length)
+ ora_hash(data_precision)
+ ora_hash(data_scale)
)
from   user_tab_columns
where table_name != 'PS_TXN';

I’m explicitly exclusing the PS_TXN table, because ADF might create this table to store application module passivations.

Every time the database changes, I calculate this simple checksum and store it in a constant in my application. At a central place in my application, I can then run the SQL and compare to the constant. If they don’t match, I’ll write a warning to the log. I don’t want the application to fail if my database does not match, but I do want to get a hint to check the database structure.

I place this check in the prepareSession() method in the Impl class for my root application module(s).

 

If you are working with ADF Development, I encourage you to sign up for my free ADF Mastery newsletter.