Comments on: The Article every DBA should forward to SQL developers

By: DB2 delivers better support for Ruby on Rails | FreeDB2.com

DB2 delivers better support for Ruby on Rails | FreeDB2.com — Fri, 22 Jan 2010 06:26:33 +0000

[...] on Rails is now faster and more secure with parametrized query support Not too long ago, I blogged about importance of getting developers to code parametrized queries instead of using literal [...]

By: Hans

Hans — Tue, 08 Dec 2009 22:11:31 +0000

> The main problem with parameters is when you output the sql statement to
> a debug log you can not see what parameters have been set for the sql.

Which is a problem of the driver though.

Some JDBC driver do implement PreparedStatement.toString() such that parameter values are shown.

By: Leon

Leon — Sat, 26 Sep 2009 23:15:43 +0000

There is no doubt that there are cases where switching from a literal value to a parameter can lead to a change in the access path and in some cases indeed, it can actually degrade performance. Can this be embarrassing, you bet. But nowhere near as embarrassing when your company is on hte news because some script kiddie or a disgruntle employee compromised security of your data.
I received a lot of questions/comments about SQL injection attacks and their applicability to intranet applications. Many people are under misguided assumption that SQL injection attacks happen only when you have customer facing applications. Don’t let yourself fall in to a false sense of security. Most data security breaches are perpetrated by the insiders. SQL injection attack can be mounted even more effectively by your company’s employee.

By: SAD

SAD — Fri, 25 Sep 2009 15:37:10 +0000

The discussion of switching to use a parameter marker instead of a literal is a little flawed, or perhaps just incomplete.

If the SAME access path will be used regardless of the LASTNAME value (to use the provided example), then switching to a parameter is a ‘duh’ move. Clearly, there’s a benefit because the access path, and cost of optimizing the different SQL text each time is eliminated.

On the other hand, if the SQL contains multiple predicates, or the data is sufficiently skewed that only some LASTNAME values should use an index, switching to a parameter marker could be dangerous. The first instance of the SQL coming sets up the access path, and it may not change again. If it’s not the right one for the predicate value, the performance degradation could be considerable and embarrassing.

Like all things DB2: it depends.

By: Leon

Leon — Thu, 17 Sep 2009 19:35:37 +0000

Regan Galbraith just pointed out on LinkedIN to this huge case of identity theft that was a result of SQL injection attack. Read and weep. Better yet, if you are using DB2 go to DB2 v9.7 and enable Statement Concentrator to help prevent SQL injection.
http://news.bbc.co.uk/2/hi/americas/8206305.stm

By: Eric

Eric — Thu, 17 Sep 2009 13:46:43 +0000

The main problem with parameters is when you output the sql statement to a debug log you can not see what parameters have been set for the sql. You have to write debug statements for all the parameters used by the statement so you can found out what went wrong. Now if there was a way to output the actual sql including parameters invoked this would encourage people to use the parameter option more.

By: SlightlyCrazy

SlightlyCrazy — Thu, 17 Sep 2009 11:47:42 +0000

The Oracle quivlent of the DB2 Statement Concentrator facility would be the Cursor_Sharing parameter
(http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/memory.htm#sthref497 etc)

By: thadbaCLK

thadbaCLK — Tue, 15 Sep 2009 14:56:56 +0000

This is an excellent article! If we would also share it with those, who care about the security of the Data you could also get a good backing of Making the Change! A lot of COTS application drive this effort of not using Host Variables (Speeds the operation of getting the COTS application out the door). Yet many of these COTS allow for rewriting of this process.

Therefore, for a business what is more important becomes the question. What is the cost to the bottom line? I as DBA say pay now (up front and fix the issue) or they will pay later with slow performance and/or unsecured data being transmitted!

By: Improve the speed and security of your SQL queries | Zen and the Art of Programming

Wed, 09 Sep 2009 05:15:42 +0000

[...] and end up irritating seasoned DBAs who have to deal with the consequences of their incompetence. Leon Katsnelson argues that this is such an important matter, that every DBA should forward this Computerworld article to [...]