Conferences 2013: Frankfurt Database Days and a couple of “Oracle-Moments”

I would like to write about this year’s (first) Frankfurt Database Days (next year’s date is already set: 26-28 March 2014) in retrospect because I really like the concept with simultaneous Tracks & Session on Oracle, DB2, MySQL, NoSQL and SQL Server.

It is, for example, always interesting – but also a shame – to realize how unknown Snapshot Isolation & RCSI is in SQL Server. It goes so far that in a session in which, in terms of the different database systems’ abilities to write datasets and still simultaneously read a consistent state, the statement was made that only Oracle can do this. That is a shame.

Because apart from the fact that this statement is not accurate – SQL Server offers 2 versions (the very Snapshot Isolation and Read Committed Snapshot Isolation) to which this applies just as well; the background knowledge that Microsoft gives the developers a choice between many different isolation levels, and why this concept is also better than having no choice (or at least to be fixated on only one in such a way that even Oracle Admins believe there was no choice), does not seem to be as widespread as one would hope.

Another session, which I only read, almost shocked me, a security specialist for SQL Server: It may not be a secret (even if interestingly enough it tends to be ignored especially in the banking field) how vast the number of security gaps is in ORACLE (you can inform yourself at the “NIST”: nvd.nist.gov), but to which extent one has to carry out a so-called security “toughening” even without special consideration of these gaps in order to be fairly safe from the grossest gateways has quite surprised me after all – being used to “secure by default” since SQL Server 2005. – As “softly” as possible, (session subtitle: “soft toughening”) so that afterwards everything will still be working – and we don’t want to completely put off attackers now, do we? 🙂 (P.S.: of course, it is understandable that one does not “close” everything “down,” and afterwards even the valid applications no longer work. The essence is: it is crucial to strike a balance that will at least reduce the vulnerability. And that is of course worth a lot in itself!) It might be good to know which of my data are thus “protected” in Oracle-DBs… without malice – because the individual customer is mostly not to blame. – Only if he or she is informed and doesn’t act accordingly (nor even take mitigating action).

But to put it out there clearly, too: it is also possible to attack an SQL Server when applications or other connections are running with too many rights, service accounts are being shared, etc. Therefore, here again the two most important security principles: “Separation of duties/roles” and “Principle of least privilege.” So always separate duties/roles (service accounts!) and always work with the lowest possible rights. And on top of this, an auditing so that you will know when you overlooked a path.

And not least of all because of the possibility to experience such misunderstandings or comparisons live, or simply to get to know very different possibilities that also exist in other DBMS, I consider the Frankfurt Database Days an enrichment to the conference landscape.

In fact, PASS Germany tries to include a small version of this mix also for the planned SQLSaturday #230 in Rheinland, at which I will likely be present. I am curious to see what will come out of it and how it will be received.

See you at the next conference maybe,

Andreas