The Blog from the DBA Classroom

By: Joel Goodman

Inside the DBA Classroom 2

Posted by Joel Goodman on 24/02/2009

In my first “Inside the DBA Classroom” post I discussed four goals for delivering seminars and courses to DBAs and which may be applied to any skills and knowledge transfer of any kind.

These are:

1. Add Value

2. Obtain Collateral Knowledge and Skill

3. Know the System

4. Raise the Bar

I write demo scripts to helps me achieve these goals.

Writing good demo scripts helps me to “Know the System” by providing a structure to my research. I first create an outline of what is to be demonstrated defining the steps from start to finish. This is followed by an iterative approach of research and script writing whereby steps are gradually added. This may involve more research and changes to t he original structure if new ideas come to mind.

By creating these demos I am able to “Add Value” to presentations beyond the material presented in the theory part of a course. This requires that my demos do not simply reiterate what is in course notes, but rather that they either examine features related to but not covered in the material, or that they go deeper into the technology than do the lessons. This depth also serves to “Raise the Bar” by challenging delegates to dig deeper and to learn more than what is in offer.

Occasionally this also involves my fourth goal of  “Collateral Knowledge and Skill” by providing an opportunity to teach features that are related to those on the course but which are not covered. For example a demo script created to teach DBAs about the various types of locks in oracle provides an opportunity to discuss the UL Lock type. But to demonstrate user locks one must create and acquire them using the dbms_lock package and this helps to teach the use of that package even though the main purpose of the demo may have been “Diagnosing Lock Problems”.

Here are some tips for writing demo scripts:

1. Action and Reaction

Scripts with DDL statements should follow the statements with queries on the appropriate Data Dictionary views to see the consequences of the DDL. This also helps DBAs learn how to “infer” what may have been done when querying the Data Dictionary. I have seen may demos that were generally good at showcasing product features but they jump from one DDL to the next without showing what has changed in the Dictionary. Of course if one must do many identical actions then the DD query may wait until they are complete such as when creating numerous tablespaces for example. In such a case only one query against DBA_TABLESPACES view may be needed.

2. Avoid Copy and Paste

From time to time, output from a query in a demo is used as input to another demo step such as the filter on a query, or an argument to a procedure call etc. Avoid “copy and paste” to prevent errors due to slips of the mouse and to save time. If using SQL*PLUS, then this is done by using the “column <column name> new_value <variable name> ” statement or by using subqueries.

3. Annotate the demo

Add explanatory comments to the demo explaining what is being done, why and how to interpret output when it is not obvious. For example when demonstrating sessions used by a shared database link there are two sessions connected to the same process on the remote database instance and this may require explanation as to why this is so when querying v$session. These annotations are especially useful if the demo is used for self-study by delegates. I often give my demos to others and they can use the annotations so that the demo is a self contained teaching and learning tool.

4. Use Viewlets

For Complex demos involving multiple screens or Graphical tools I recommend creating viewlets (which are recordings of demos) if you havea viewlet builder. Oracle University create may such demos for use in the DBA Classroom.

5. Maintain the Demos

Many opportunities arise to enhance demos including new features that relate to features in the demo, brainstorms where new ideas for existing features arise, or simply tinkering to improve the flow and formatting of the output. I consider demos to be like an applications in that they require maintenance from time to time.

6. Share your Demos

I share my demos with colleagues, customers and peers in the industry often getting good ideas from them and learning from their demos. Some of my colleagues in Oracle University create fabulous demos from which I have learned a great deal especially on DBA 2.0 topics for which Harald van Breederode created many demos.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: