Blue Core Research's "NO BULL" buyers guide to Database Auditing products - Part 14: Oracle and MS SQL Server

Most companies have more than one database vendor. Oracle, SQL Server, DB2, MySQL and Sybase are all common depending on the company, and some use less common databases such as TeraData. There are, however, some important questions to ask before you dive into your cross platform heterogeneous requirements:

* Which databases do you actually need to audit? Is all your SOX, PCI, HIPAA or other sensitive data scattered across all these databases, or is your SQL Server just used for small home-grown apps that do not have any auditing requirements?

* Do you have the same DBA or team managing all these databases, or are they different teams that will end up managing auditing solutions independently? In the later case you are better off choosing the best solution for each database rather than mandating a single solution no one is too happy with.

Another thing that is important to remember when dealing with different databases is that they tend to promote very different types of usage. Here are a few examples contrasting Oracle and SQL Server:

Sessions:

In the Oracle world almost all the applications create sessions that last for a long time. This is partially because of the tools used to write applications working against Oracle and partially because of the cost of creating a session.

In the SQL Server world many applications create a session for every transaction. The reason is that the default behavior of .NET (the primary tools used for developing SQL Server applications), is to make a connection for every SQL you run. The result is that SQL Server databases are better viewed through the user generating the activity rather than for by sessions.

This means that a good SQL Server auditing tool will work slightly differently than an Oracle auditing tool.

SQLs vs. Procedures:

In the Oracle world most application issue SQLs against the database. In the SQL Server world, most applications access the database via procedures. Also in the SQL Server database security will be implemented through these procedures. So while Oracle people will care about SQL activity, SQL Server people will usually care more about procedural activity. This means that the tools aims for SQL Server and Oracle should behave differently in order to satisfy their customers.

Databases and Schemas:

What is known as a Database in the SQL Server (and DB2) world, is known as a Schema in Oracle. But the name change is not the main difference here. The main difference is that SQL Server instances tend to contain many databases, often in the hundreds per instance. Oracle instances however tend to contain either a single or a hand full of schemas. The difference lies in the fact that SQL Server instances tend to serve many smaller applications while Oracle instances tend to serve massive large applications.

Context:

A small but very important difference between Oracle and SQL Server is the “use” command. When logging into an Oracle database, the context of the SQLs that will be executed is determined by the user who logged on. In order to access a schema other than the default one assigned at logon, the SQL must explicitly reference that schema. In SQL Server however, the default schema can be changed at any time using the “use” command. The result is that when auditing the activity in SQL Server, the current schema is critical to the understanding of what the SQL is referencing. While critical this piece of information is missing in all Database auditing solutions for SQL Server as they are built on the same paradigm as their Oracle counterparts.

There are many other differences between Oracle and SQL Server including the entire security paradigm and the way in which it is managed, but the bottom line conclusion that we are trying to get to is this – A good Oracle auditing tool and a good SQL Server auditing tool are two different tools.

To read the full buyer's guide, visit http://www.bluecoreresearch.com/documentation/features