<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet href="http://www.database-brothers.com/blog/rss/rss20.xsl" type="text/xsl"?>

<!-- generator="boastMachine v3.1" -->
<rss version="2.0">
 <channel>
	<title>Alexander Kopac</title>
	<link>http://www.database-brothers.com/blog/AlexanderKopac.php</link>
	<description>Alexander Kopac</description>
	<language>en</language>
	<docs>http://backend.userland.com/rss092</docs>
	<pubDate>Tue, 15 Jan 2008 12:06:00 +0000</pubDate>
	<managingEditor>webmaster@database-brothers.com</managingEditor>
	<webMaster>webmaster@database-brothers.com</webMaster>
    <item>
      <title><![CDATA[Views on 'VIEWS ON VIEWS' - Behind the Curtain of the Mighty OZ.]]></title>
      <description><![CDATA[Sometimes &quot;RDBMS VIEWS&quot; &amp; &quot;VIEW SQL&quot; seem to resemble the 'work behind the curtain' in the mighty land of OZ.

A fellow database practitioner asked recently &quot;Where are VIEWS stored in DB2 LUW&quot; as they had found a VIEW SQL statement or two that was killing both their CPU &amp; I/O rates.

Many of their VIEWS were returning 2000 rows or more every time bypassing without any &quot;FETCH limiting SQL&quot; in their &quot;C# &amp; JAVA WIENIE&quot; coded applications.

Their initial review showed an issue commonly faced by our fellow database practitioners.  

They had a small amount (633) executions that were using 10.7% of the overall CPU time while fetching/returning a whopping average 104,285,598 rows each time; (whereas about 10 rows fetched/returned on average are normally sufficient).

They surmised that they also had more VIEW statements with some &quot;LIKE&quot; SQL where the top 300 rows returned would have been sufficient; (you can limit in DB2 SQL by using &quot;fetch first 300 rows only&quot; in the SQL and not by needlessly fetching, then dropping/kicking out the extra 1700 rows in the application code) by simply appending &quot;FETCH FIRST 300 ROWS ONLY&quot; to the SELECT DML SQL statement.

The VIEW SQl statement in question also used 45.57% of all Sort time with 1266 sorts (double the number executions).  

(Off the cuff, &quot;Sort Counts&quot; that are &quot;equal or double SQL executions&quot; are usually a great candidates for a DB2 Clustering index - and possibly a &quot;allow reverse scans&quot; clause.  My experience helping fellow database practitioners solve issues frequently involve databases with 1,000+ tables.  I generally find zero (0) occurrences of these two things:  Both &quot;CLUSTER&quot; is missing from all/any indexes and &quot;ALLOW REVERSE SCANS&quot; is also missing from any/all of their indexes.)

(Ya'll should remember that in DB2 LUW V9.1: &quot;allow reverse scans&quot; clause is now enabled by default for indexes, primary keys and unique keys. Many recurrent problems that we frequently help fellow database practitioners solv ..]]></description>
      <link>http://www.database-brothers.com/blog/AlexanderKopac.php?id=75</link>
      <pubDate>Mon, 07 Jan 2008 13:24:51 +0000</pubDate>
      <category>General</category>
      <comments>http://www.database-brothers.com/blog/AlexanderKopac.php?id=75#cmt</comments>
    </item>
    <item>
      <title><![CDATA[Recursive SQL for Mining the DB2 Catalog Views and Tables  - 2 of 2]]></title>
      <description><![CDATA[Recursive SQL for Mining the DB2 Catalog Views and Tables  - 2 of 2

Hello Ya'll once again:  (All Ya'll is plural in Austin, Texas)

Having survived the many casino's and the 4 hour border crossing wait in the rain on the pretty drive between Seattle &amp; Vancouver, British Columbia, I had just enough gas money to get back to the Seattle airport after BMC Userworld Conference 2007 where I spoke about 'Database Auditing for Compliance, Security,&amp; Reputation Management’ on Nov 2.

This week we were invited to celebrate yet another proverbial free lunch (DBA food = pizza u pivo) and (again under the influence of the spirits or the tomato sauce), I promised that I would get my blog updated.

What follows is still perhaps weakly described as “DB2 LUW System Catalog - The Magical Table Views”!

As many of you know, DBA's are routinely handed a Legacy application without benefit of the Logical or Physical model and asked to migrate the system across platforms such as Windows to AIX or Sun Solaris etc.

In addition, there's many 'after thoughts where an existing table needs to broken up or massively changed to fix up either a poor design or to add some petty and 'minor' new business functionality like 24X7 web enablement!

The SQL coding technique that follows below can be used to help initially understand the big picture for application tables within the DB2 System Catalog.  Use my example below and simply change the 'EXPLAIN_INSTANCE' value to your table name, then look for the magic !
 
Here's two real life example from the DB2 LUW System Catalog:  (Cut/paste and run for yourself <img src="http://www.database-brothers.com/blog/smilies/icon_exclaim.gif" alt="!)" />

For example, I picked two EXPLAIN tables - SYSIBM.EXPLAIN_INSTANCE &amp; SYSIBM.EXPLAIN_DIAGNOSTIC tables.

BTW, here's some notes for the following SQL Catalog query:

ADK.CHILDREN table is a CTE (Common Table Expression) i.e. a Temporary Table that is generated/created on the fly just for the duration of this query.

======================================================= ..]]></description>
      <link>http://www.database-brothers.com/blog/AlexanderKopac.php?id=72</link>
      <pubDate>Thu, 15 Nov 2007 17:17:13 +0000</pubDate>
      <category>General</category>
      <comments>http://www.database-brothers.com/blog/AlexanderKopac.php?id=72#cmt</comments>
    </item>
    <item>
      <title><![CDATA[Recursive SQL for Mining the DB2 Catalog Views and Tables - 1 of 2]]></title>
      <description><![CDATA[Recursive SQL for Mining the DB2 Catalog Views and Tables 1 of 2

Hello Ya'll:          (All Ya'll is plural in Austin, Texas)

As some of you may know, my official title at DBI' for the past several years has been &quot;Database Magician&quot;.  

Recently I had some folks from Austin say that they love my business card  title:  “Database Magician” – How do you get a gig like that they asked ? Sometimes it feels like pulling rabbits out of hats…&quot;  Isn't that the perfect title for all DBA's ? &quot;It takes '5 years to create an issue' and the expectation is often 'get it fixed in 5 minutes.&quot;

I once had a boss that said &quot;... you DBA's are just obstacles, you're just a bunch of over-priced whiners'. . .  but that's a story for another day at an IDUG, IOD, AOUG, OOW event conference during a happy hour.

This week, my co-workers were all encouraged to wear our Halloween costumes.  Fortunately for me, my costume search was easy … my Magician’s hat sits on top of my desk; seldom far from sight. 

To go along with this week's theme, here's some more 'magic' recursive SQL for mining the relationships of the system catalog Tables &amp; Views; this time directed to the DB2 for LUW &amp; DB2 for z/OS database practitioners.

Earlier this week, invited for yet another proverbial free lunch I again promised that I was to get my blog updated before I ran off to Vancouver, British Columbia and BMC Userworld Conference 2007 to speak about 'Database Auditing for Compliance, Security,&amp; Reputation Management’ on Nov 2.

Well, what follows is perhaps weakly described as “DB2 LUW System Catalog - The Magical Views”!

As many of you know DBA's are handed a Legacy application without benefit of the Logical or Physical model and asked to migrate the system across platforms Windows to AIX or Sun Solaris etc.  

In addition, many times, an existing table needs to broken up or massively changed to fix up either a poor design or to add some 'minor' new business functionality like 24X7 web enab ..]]></description>
      <link>http://www.database-brothers.com/blog/AlexanderKopac.php?id=70</link>
      <pubDate>Tue, 30 Oct 2007 13:27:42 +0000</pubDate>
      <category>General</category>
      <comments>http://www.database-brothers.com/blog/AlexanderKopac.php?id=70#cmt</comments>
    </item>
    <item>
      <title><![CDATA[Jumbalaya Magic - Jumbling/Obsfucating Production Data for Test Enviroments]]></title>
      <description><![CDATA[Hello Ya'll:

As some of you may know, my official title at DBI' for the past several years has been &quot;Database Magician&quot;; (more likely because we all wear many interchangable hats than anything else).  

However, I've been known on many ocassions to speak on 'Parlez-Vous Klingon?  Recursion SQL for Generating Test Data' for IBM DB2 databases.

Therefore, what better way to start my first ever Blog entry by offering some more 'magic' - this time for all ya'll Oracle database practitioners.

Earlier this week, I was fortunate enough to be invited for free pizza (DBA geek food) and to speak at the Austin (Texas) Oracle Users Group where I spoke about 'Database Auditing for Compliance, Security,&amp; Reputation Management'.  

During the session, I promised the 57 attendees that I would make some Oracle SQL available for Jumbling/Obfucating/Scrambling Production Data for Testing environment purposes. 

(BTW, Watch out Vancouver, BC, I'll be at BMC Userworld on Nov 2 and giving up the same stuff <img src="http://www.database-brothers.com/blog/smilies/icon_exclaim.gif" alt="!)" />

Well, what follows is perhaps some Jumbalaya magic - Jumbling/Obsfucating Production Data for Testing Purposes !

As many of you know, there are many application vendors of database &quot;Data Quality &amp; Cleansing tools&quot; that prepare/check for valid addresses for USPS handling by verifying, standardizing, and correcting address elements, as well as producing delivery point barcodes in order to enable pre-sorting for postal automation discounts.  

Many times, the technique that I am providing below can be used to help get thru these 'testing stangleholds' or bottlenecks and mask the real data owners.

Of course, ya'll must try this all out with      sqlplus scott/tiger @jumbalaya.sql &gt; jumbalaya.txt /NOLOG

The sample below (jumbalaya.sql) takes the address from the next-row after the row read (in-hand) and substitutes/updates/puts it into the current row thereby &quot;cornfusing; murdalating and obsfucat'n&quot; the darn data.

The point here is that the address is/remai ..]]></description>
      <link>http://www.database-brothers.com/blog/AlexanderKopac.php?id=69</link>
      <pubDate>Thu, 18 Oct 2007 15:35:01 +0000</pubDate>
      <category>General</category>
      <comments>http://www.database-brothers.com/blog/AlexanderKopac.php?id=69#cmt</comments>
    </item>
  </channel>
</rss>