Comments on: Log Buffer #2: a Carnival of the Vanities for DBAs http://www.pythian.com/news/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas/ News and views from Pythian DBAs Fri, 10 Feb 2012 13:01:25 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: will dieterich http://www.pythian.com/news/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas/#comment-1144 will dieterich Sat, 29 Jul 2006 14:06:34 +0000 http://www.pythian.com/blogs/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas#comment-1144 The only rule that needs to be followed to advoide SQL injection is 'Use parameterized SQL!!!!!!!!' every modern language provides it in some form. Stored procedures don't stop sql inection, it is that most people when using stored procedures do it using parameteried variables, besides for CRUD stuff stored procudures are slower. Named SQL place holder are parammeterized SQL. Most persistence engines use parameterized SQL because of its speed. So using one of thoses does make use of the technology The only rule that needs to be followed to advoide SQL injection is
‘Use parameterized SQL!!!!!!!!’ every modern language provides it in some form.

Stored procedures don’t stop sql inection, it is that most people when using stored procedures do it using parameteried variables, besides for CRUD stuff stored procudures are slower.

Named SQL place holder are parammeterized SQL.

Most persistence engines use parameterized SQL because of its speed. So using one of thoses does make use of the technology

]]> By: John Scoles http://www.pythian.com/news/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas/#comment-1100 John Scoles Thu, 27 Jul 2006 12:54:07 +0000 http://www.pythian.com/blogs/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas#comment-1100 SQL injection attacks are a nasty annoyance but can be easily avoided it developers simply followed a few hard and set rules. 1) Use Stored Procedures instead of inline SQL is one sure way of preventing these attacks --This of course brings up the problem of getting the SP written. You either need a DBA with allot of time on her hands (ha!) or a developer who can also write a good SP (double Ha!!) neither of witch are that common. 2) Use named SQL place holders in your inline SQL. This makes it much harder for the hacker to get in but it is not 100%. 3) Use some sort of Persistence engine such as Enterprise Java Beans, Perl Beans or alike. This of course brings up the problems of speed especially on the web. 4) Limit the rights of the web server to just the data views and cursors needed. This can also works very well with SP in that you know that the web server can only access a know set of objects. SQL injection attacks are a nasty annoyance but can be easily avoided it developers simply followed a few hard and set rules.

1) Use Stored Procedures instead of inline SQL is one sure way of preventing these attacks –This of course brings up the problem of getting the SP written.
You either need a DBA with allot of time on her hands (ha!) or a developer who can also write a good SP (double Ha!!) neither of witch are that common.

2) Use named SQL place holders in your inline SQL. This makes it much harder for the hacker to get in but it is not 100%.

3) Use some sort of Persistence engine such as Enterprise Java Beans, Perl Beans or alike. This of course brings up the problems of speed especially on the web.

4) Limit the rights of the web server to just the data views and cursors needed. This can also works very well with SP in that you know that the web server can only access a know set of objects.

]]> By: Alex Gorbachev http://www.pythian.com/news/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas/#comment-1085 Alex Gorbachev Wed, 26 Jul 2006 19:47:19 +0000 http://www.pythian.com/blogs/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas#comment-1085 Paul, Well, looking at the ADDM and Automatic SQL Tuning features in 10g, auto indexing functionality has been already partially implemented or at least basis of self-indexing has been created. DBMS_SQLTUNE can recommend creating of certain indexes and/or drop/change existing ones. Not that I would trust it too much now but the trend is here and Oracle 11 may well already have a hidden parameter to run automatic SQL tuning tasks and hidden parameter(s) to control the types of automatically accepted recommendations. Moreover, it doesn’t have to be limited to self-indexing but can include "self-materialized-viewing", self-profiling (this is the one I like much more), self-sql-rewriting and etc. Indeed, looking at the automation that Oracle is introducing in such areas as UNDO, PGA, SGA, statistics, parallelism, and etc. I won't be much off-track asserting that automation and self-tuning is the most probable direction for future Oracle innovations. Being a bit sarcastic (as usual) about GATHER_STATS_JOB, I should add that it's just a first implementation and requires particular attention from DBA’s as any new feature enabled by default. Further improvements and, more important, increased awareness and understanding how to control and tune it, should make this job much more useful than it is now. Do you want to bet which Oracle version will include default self indexing feature? Cheers, Alex Paul,
Well, looking at the ADDM and Automatic SQL Tuning features in 10g, auto indexing functionality has been already partially implemented or at least basis of self-indexing has been created.
DBMS_SQLTUNE can recommend creating of certain indexes and/or drop/change existing ones. Not that I would trust it too much now but the trend is here and Oracle 11 may well already have a hidden parameter to run automatic SQL tuning tasks and hidden parameter(s) to control the types of automatically accepted recommendations.
Moreover, it doesn’t have to be limited to self-indexing but can include “self-materialized-viewing”, self-profiling (this is the one I like much more), self-sql-rewriting and etc.
Indeed, looking at the automation that Oracle is introducing in such areas as UNDO, PGA, SGA, statistics, parallelism, and etc. I won’t be much off-track asserting that automation and self-tuning is the most probable direction for future Oracle innovations.
Being a bit sarcastic (as usual) about GATHER_STATS_JOB, I should add that it’s just a first implementation and requires particular attention from DBA’s as any new feature enabled by default. Further improvements and, more important, increased awareness and understanding how to control and tune it, should make this job much more useful than it is now.
Do you want to bet which Oracle version will include default self indexing feature?
Cheers,
Alex

]]> By: Paul Vallee http://www.pythian.com/news/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas/#comment-1083 Paul Vallee Wed, 26 Jul 2006 18:37:39 +0000 http://www.pythian.com/blogs/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas#comment-1083 Alex - re self-indexing tables. I think it could work too. It could be done using a mix of sql replay and genetic algorithms. What I would have in mind is a process for a server to identify "idle resources" and off-peak time. Then, identify expensive sql, preferably further characterized by its routine execution. Then, during off-peak time and scheduled with idle resources (dba could set a cap on resources assigned to this task), simply have the system go ahead and create "random" indexes on these objects and re-play the captured sql (and even other concurrent captured sql). The key is to then engage the genetic algorithm component, and either kill (i.e. drop the index) or mutate (i.e. play around with columns, column orders, etc.) and iterate. This would be challenging but would conceivably propose good indexing improvements, either for automated implementation or review. Your thoughts? Paul Alex – re self-indexing tables. I think it could work too. It could be done using a mix of sql replay and genetic algorithms.

What I would have in mind is a process for a server to identify “idle resources” and off-peak time.

Then, identify expensive sql, preferably further characterized by its routine execution.

Then, during off-peak time and scheduled with idle resources (dba could set a cap on resources assigned to this task), simply have the system go ahead and create “random” indexes on these objects and re-play the captured sql (and even other concurrent captured sql). The key is to then engage the genetic algorithm component, and either kill (i.e. drop the index) or mutate (i.e. play around with columns, column orders, etc.) and iterate.

This would be challenging but would conceivably propose good indexing improvements, either for automated implementation or review.

Your thoughts?
Paul

]]> By: Alex Gorbachev http://www.pythian.com/news/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas/#comment-1082 Alex Gorbachev Wed, 26 Jul 2006 18:10:41 +0000 http://www.pythian.com/blogs/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas#comment-1082 I've got a thought on the same note as "Why Can’t Database Tables Index Themselves". When CBO came to Oracle many people wondered - why can't Oracle collect stats on their own? Well, here we go in 10g with GATHER_STATS_JOB. Results? Well, if your database is something that can be managed in Microsoft Access - not a big deal - the job will work fine. For more or less serious implementations - good DBA leaves no place for a chance. But who knows if Oracle won't adapt this self indexing idea soon... At least, they should start an internal project on this feature - marketing will be very happy! :-) Or maybe someone is brave enough and has enoug time to start an indepedant project - like "Oracle Self-indexing Wizard"? I’ve got a thought on the same note as “Why Can’t Database Tables Index Themselves”.
When CBO came to Oracle many people wondered – why can’t Oracle collect stats on their own? Well, here we go in 10g with GATHER_STATS_JOB.
Results? Well, if your database is something that can be managed in Microsoft Access – not a big deal – the job will work fine. For more or less serious implementations – good DBA leaves no place for a chance.
But who knows if Oracle won’t adapt this self indexing idea soon… At least, they should start an internal project on this feature – marketing will be very happy! :-)
Or maybe someone is brave enough and has enoug time to start an indepedant project – like “Oracle Self-indexing Wizard”?

]]> By: David Edwards http://www.pythian.com/news/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas/#comment-1062 David Edwards Wed, 26 Jul 2006 01:55:02 +0000 http://www.pythian.com/blogs/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas#comment-1062 Here's the real story of Sakila -- <a href="http://www.mysql.com/news-and-events/news/article_116.html" rel="nofollow">it's SiSwati</a>. Here’s the real story of Sakila — it’s SiSwati.

]]> By: Alex Gorbachev http://www.pythian.com/news/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas/#comment-994 Alex Gorbachev Sun, 23 Jul 2006 21:01:47 +0000 http://www.pythian.com/blogs/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas#comment-994 Paul, David, Nice job! I like non-Oracle related part as well - it makes our vision broader. Thanks! Alex Paul, David,
Nice job! I like non-Oracle related part as well – it makes our vision broader.
Thanks! Alex

]]> By: Doug Burns http://www.pythian.com/news/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas/#comment-929 Doug Burns Fri, 21 Jul 2006 20:10:43 +0000 http://www.pythian.com/blogs/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas#comment-929 David, A couple of points of order :- 1) Surely steroids would result in a suspiciously *low*-pitched voice? 2) I feel a little uncomfortable with you using the word thoughtful in reference to me. Otherwise, nice job. Cheers, Doug David,

A couple of points of order :-

1) Surely steroids would result in a suspiciously *low*-pitched voice?

2) I feel a little uncomfortable with you using the word thoughtful in reference to me.

Otherwise, nice job.

Cheers,

Doug

]]> By: Paul Vallee http://www.pythian.com/news/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas/#comment-922 Paul Vallee Fri, 21 Jul 2006 17:37:29 +0000 http://www.pythian.com/blogs/225/log-buffer-2-a-carnival-of-the-vanities-for-dbas#comment-922 Great Job, David. I look forward to seeing Bill's next week! Paul Great Job, David. I look forward to seeing Bill’s next week!

Paul

]]>