Results 1 to 4 of 4

Thread: Visual Explain

  1. #1
    Join Date
    Aug 2007
    Posts
    56

    Unanswered: Visual Explain

    As a DBA, how often do you use Visual Explain during the development process?

    Do you run every query through Visual Explain or run them through based on a particular criteria?

    I've searched for best practices on this topic but have not had much luck.

    Thank you

  2. #2
    Join Date
    Nov 2005
    Location
    IL
    Posts
    557
    generally speaking, developers should be able to define the top what ever number of reports/SQL that are important to them. You concentrate on those first and foremost. Once that is done, you can start with a smaller fish.

    Preferably every new SQL should be going through the review process. Reality proves it wrong. Getting an SQL for review from developers is harder then pulling teeth from the lion at times.

    When I was a developer utilizing mainframe, every new SQL that I wrote had to be reviewed by the DBA or it was a no go. Now days in the UDB world when no one is getting billed for time spent processing this requirement went away at most shops.
    --
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows

    DB2 v9.7.0.6 os 6.1.0.0

  3. #3
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Generally a DBA should be doing a SQL snaphot in one of the environments (test, QA, performance test, production) that would indicate which SQL statements are running slow. Then those problem statements should be explained to figure out how to fix it. In my experience it is usually not necessary or feasible to explain and analyze the output for every SQL statement.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  4. #4
    Join Date
    Jan 2009
    Location
    Zoetermeer, Holland
    Posts
    746
    Quote Originally Posted by Cougar8000
    When I was a developer utilizing mainframe, every new SQL that I wrote had to be reviewed by the DBA or it was a no go. Now days in the UDB world when no one is getting billed for time spent processing this requirement went away at most shops.
    Hee, we've walked the same road : from mainframe developer to DB2/LUW dba. vi is primitive compared to ISPF, right?

    The reason why those (pro-active) days are gone is procedural. Dynamic SQL is hidden in java/jdbc code and mostly generated. When you confront the programmer with the SQL he/she does not even recognize it! To play the role our mainframe-collegues do is very hard to set-up on unix so we let it go and feed the package-cache to db2advis from time to time...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •