DB2 9.5 SQL Procedure Developer exam 735 prep, Part 6: DB2 development tools

In this tutorial, learn about the most common IBM tools available to develop database code. Get an overview of Visual Explain (from within the IBM DB2® Control Center and Command Editor and from within IBM Data Studio), learn about the profiling capabilities in the IBM Data Studio, and see how to run the explain commands DB2EXPLN and DB2EXFMT from the command line. This is sixth in a series of tutorials you can use to help prepare for the DB2 9.5 SQL Procedure Developer exam 735.

Share:

Marina Greenstein (greenstm@us.ibm.com), Executive IT Specialist, IBM

Marina Greenstein photoMarina Greenstein is an Executive IT Software Specialist with the IBM Database Migration Team. She is an IBM Certified Solutions Expert who joined IBM in 1995 with experience in database application architecture and development. During the 13 years Marina has been with the DB2 Migration Team, she has assisted customers in their migrations from Microsoft SQL Server™, Sybase, or Oracle databases to DB2. She has presented migration methodology at numerous DB2 technical conferences and at SHARE. She is also the author of multiple articles, white papers and IBM Redbooks about DB2 migration.



Maria Schwenger, Advisory Software Engineer, IBM

Photo of Maria SchwengerMaria Schwenger joined IBM in 2005 as part of the Entity Analytic Solutions team, bringing more then 10 years of experience in performance engineering, database architecture, administration, and database development on Oracle and MS SQL server, as well as extensive experience in migration from legacy to relational databases. Currently, Maria works in a high-touch model with early release participants to promote DB2 Open Database Technology’s early adoption.



22 January 2009

Before you start

About this series

Thinking about seeking certification on DB2 SQL Procedure Developer (Exam 735)? If so, you've landed in the right spot. This series of six DB2 certification preparation tutorials covers all the basics—the topics you'll need to understand before you read the first exam question. Even if you are not planning to seek certification right away, this set of tutorials is a great place to start learning all about database development for DB2 V9.5.

About this tutorial

In this tutorial, learn about the most common IBM tools available to develop database code. Get an overview of Visual Explain (from within the IBM DB2 Control Center and Command Editor and from within IBM Data Studio), learn about the profiling capabilities in the IBM Data Studio, and see how to run the explain commands DB2EXPLN and DB2EXFMT from the command line. This is sixth in a series of tutorials you can use to help prepare for the DB2 9.5 SQL Procedure Developer exam 735. The material in this tutorial primarily covers the objectives in Section 6 of the test, which is entitled "DB2 development tools." See Resources.

Prerequisites

This tutorial is written for Linux®, UNIX®, or Windows® database developers or administrators, whose skills and experience are at a beginning to intermediate level. You should have a general familiarity with using a UNIX or Windows command-line shell and a working knowledge of DB2 and SQL commands.

System requirements

The examples in this tutorial are specific to DB2 9.5 running on a Windows operating system. The concepts and information provided are relevant to DB2 running on any distributed platform.

You do not need a copy of DB2 9.5 to complete this tutorial. However, you will get more out of the tutorial if you download the free trial version of IBM DB2 9.5 to work along with this tutorial (see Resources).


Introduction

IBM provides several tools to develop database applications. One of these tools is IBM Data Studio, an eclipse-based development environment to facilitate the design, development, deployment, and debugging of the SQL and Java® stored procedures. Command Line Processor also can be used to create and run SQL procedures.

DB2 provides comprehensive explain functionality for displaying information about the query access plan chosen for the SQL statements that enables developers and database admins to analyze and optimize SQL code. This tutorial provides an overview of Visual Explain (from within the DB2 Control Center and Command Editor and from within IBM Data Studio), the profiling capabilities IBM Data Studio offers, as well as a description of how to run the explain commands DB2EXPLN and DB2EXFMT from the command line.


Using IBM Data Studio

IBM Data Studio provides an easy-to-use development environment for creating, building, debugging, testing, deploying, and profiling stored procedures. The Data Studio is based on the Open Standard Eclipse Framework that is used in Java development. It provides a series of different perspective windows to support rapid application development, including SQL and Java-stored procedures development. Using IBM Data Studio, you can perform the following tasks:

  • Connect to databases and explore database objects
  • Create new routines
  • Build routines on local and remote DB2 servers
  • Modify and rebuild existing routines
  • Test and debug the execution of installed routines

Here are the steps required to develop, debug, and test a simple stored procedure using IBM Data Studio.

Step 1: Connect to a database in the Database Explorer of Data perspectives.

Figure 1. Using Database Explorer to connect to the SAMPLE database
Using Database Explorer to connect to the SAMPLE database

Database Explorer enables you to view all your database objects and get information about those objects. For example, you can view column properties and sample data for any given table. You can even update data in the table by selecting Edit from the drop-down menu by right clicking on the table name.

Figure 2. Viewing table data in Database Explorer
Viewing table data in Database Explorer

Step 2: Create a data development project in Data Project Explorer to start stored procedure development. Be sure to select the connection you created in Step 1.

Figure 3. Creating a data development project in Data Project Explorer
Creating a data development project in Data Project Explorer

Step 3: Create a procedure in a new project.

Highlight the Stored Procedures folder, and select New > Stored Procedures from the drop-down menu. The New Stored Procedure wizard enables you to pick up SQL or Java language.

Figure 4. Creating a new procedure in the Data Project Explorer
Creating a new procedure in the Data Project Explorer

Step 4: Deploy the stored procedure.

To deploy the stored procedure, select Deploy on the drop-down menu for the procedure, as shown in Figure 5.

Figure 5. Deploying the procedure in the Data Project Explorer
Deploying the procedure in the Data Project Explorer

You can instead select Deploy from the drop-down menu by right-clicking in the text editor where the procedure is displayed. The deployment step is building your stored procedure on the database. If you want to deploy your procedure for debugging, select Enable debugging in the Routine Options window, and select Finish.

Figure 6. Enabling debugging in the Deploy Routine wizard
Enabling debugging in the Deploy Routine wizard

Step 5: Run the stored procedure.

After successful deployment, you can run the stored procedure by selecting the Run option from the drop-down menu by right clicking on the procedure name in Data Project Explorer or in the text editor where the procedure is displayed.

Figure 7. Running the stored procedure from Data Project Explorer
Running the stored procedure from Data Project Explorer

Note that you can view output of the procedure in the Data Output Window.

Debugging the stored procedure

IBM Data Studio provides a comprehensive mechanism to debug SQL and Java stored procedures. Data Studio runs the procedure statement at the time, sets breakpoints, and displays values of the local variables, SQLCODE and SQLSTATE. After you deploy procedure checking using the Enable Debugging option, you can debug this procedure by selecting Debug from the drop-down menu after right clicking on the procedure name (or right clicking in the text editor where this procedure displayed).

Figure 8. Selecting Debug from the drop-down menu
Selecting Debug from the drop-down menu

Notice that Data Studio transfers you into the Debug perspective, where you can debug your procedure by stepping through each statement or by going from one breakpoint to the next.

Profiling the stored procedure

IBM Data Studio Developer provides a comprehensive mechanism to profile SQL stored procedures. When you select this option, the procedure statements run on the database server, and specified profiling data is collected. You can run profiling to discover and capture tuning data for SQL procedures and nested procedures. Collected data is presented beside the source for each procedure. Database admins or application developers can use this data to more efficiently tune resource-consuming statements.

To run profiling, right-click the SQL procedure in either Data Source Explorer or Data Project Explorer, and select Run Profiling from the menu.

Figure 9. Select Run Profiling in the Data Project Explorer window
Select Run Profiling in the Data Project Explorer window

In the resulting window, specify the monitor element options and click OK.

Figure 10. Select the performance events you want to monitor
Select the performance events you want to monitor

If the routine has parameters, a window opens prompting you to specify parameter values. After the procedure runs, a window opens prompting you to select which SQL procedures to include in the profiling report. If no SQL procedure profiling data is captured, a report is not generated.

To view the profiling data, go to the Data Output view. The data is located under the Profiling Data tab.

Figure 11. Review the captured profiling data
Review the captured profiling data

Restrictions

  • SQL procedure profiling is only available for SQL procedures and nested SQL procedure calls. Profiling is not available for non-SQL procedures and statements.
  • SQL procedure profiling is only supported for SQL procedures that target DB2 Universal Database™ for Linux, UNIX, and Windows, Version 8.2 or higher.

Generating access plan diagrams with Visual Explain

Using IBM Data Studio, you can generate a diagram of the query access plan for an SQL or XPATH statement. You can also:

  • View the statistics that were used at the time of optimization. You can then compare these statistics to the current catalog statistics to help you determine whether rebinding the package might improve performance.
  • Determine whether or not an index was used to access a table. If an index was not used, Visual Explain can help you determine which columns might benefit from being indexed.
  • View the effects of performing various tuning techniques by comparing the before and after versions of the access plan graph for a query.
  • Obtain information about each operation in the access plan, including the total estimated cost and number of rows retrieved (cardinality).

To generate a query access plan, complete the following steps.

Step 1: Select the SQL or XPATH statement you want to explain as follows:

  • From the Data Project Explorer or Database Explorer, right-click on an SQL statement (CREATE, INSERT, UPDATE, SELECT, or CALL), SQL stored procedure, or SQL user-defined function, and select Visual Explain.
  • From the SQL Editor, highlight and right-click the SQL, XPATH, or XQUERY statement, and select Visual Explain.
Figure 12. Select Visual Explain in the Data Project Explorer window
Select Visual Explain in the Data Project Explorer window

Step 2: Follow the steps in the Collect Explain Data wizard.

On the first page of the wizard, specify the terminator of the SQL, XPATH, or XQUERY statement for which you want to diagram the access plan. Optionally, you can also specify whether to save your settings as the defaults for all diagrams that you create with Visual Explain, specify a new working directory, or indicate whether you want to store the collected explain data in explain tables. This is the place to define whether to trace the creation of the diagram and the collection of the explain data, in case you need a trace for troubleshooting.

On the second page of the wizard, you can set values for the special registers to customize the runtime environment to influence the collection of explain data. Optionally, you can also specify whether to save your settings as the defaults for all diagrams that you create with Visual Explain.

Click Finish to close the wizard and to generate the diagram.

To save the diagram, save it in the Access Diagram view and in the Overview Diagram section. The directory specified in the wizard is a temporary location.

The workbench displays the diagram in the Access Plan Diagram view. In this view, you can navigate through the diagram, view descriptions of the nodes in the diagram, and search for nodes. Hover tips show you the details.

Figure 13. Access Plan Diagram in IBM Data Studio Developer
Access Plan Diagram in IBM Data Studio Developer

Restrictions

Visual Explain in the workbench supports the following data servers:

  • DB2 Version 9.5.1 for Linux, UNIX, and Windows
  • DB2 UDB for z/OS™ Version 8 (New Function Mode)
  • DB2 Version 9.1 for z/OS

If you want to create access plan diagrams for DB2 Version 8.2 for Linux, UNIX, and Windows or for DB2 UDB for z/OS Version 8 (Compatibility Mode), you must install additional software. The workbench launches this software when you want to create access plan diagrams.

  • For DB2 Version 8.2 for Linux, UNIX, and Windows, you must install Client for DB2 for Linux, UNIX, and Windows.
  • For DB2 UDB for z/OS Version 8 (Compatibility Mode), you must install Visual Explain for DB2 for z/OS.

Handling procedures from the DB2 command line

DB2 Command Line Processor (CLP) is a native way to interface with DB2. Any task that can be done using different GUI tools could be accomplished using CLP. You can configure, tune, get help, run SQL queries, create (build), run stored procedures, or get information for different SQLCODE using CLP.

To build a stored procedure from the DB2 command line, edit the file containing this procedure to add a terminating character that DB2 can recognize. Each statement in the SQL procedure requires a terminator. The default is semicolon (;). You need select an alternative termination character to use in the script for CLP to know where your procedure is terminated. Most often used are “at” (@) and exclamation (!) characters.

Listing 1 shows a script that contains a simple stored procedure with an “@” termination character in the end.

Listing 1. Stored procedure script with a termination character
CREATE PROCEDURE NUMBER_OF_ORDERS 
         (in_status varchar(10), in_date DATE, out num_of_order int)
P1: BEGIN
	
      DECLARE v_number INTEGER DEFAULT 0;
	
		SELECT count(poid)
		  INTO v_number
		  FROM PURCHASEORDER
	       WHERE ucase(status) = ucase(in_status)
		   AND orderdate < in_date;
		  
      SET  num_of_order = v_number;		  

END P1 @

This script is saved as file myscript.db2.

To build the procedure number_of_orders from DB2 CLP, run the following command: db2 –td@ -vf myscript.db2. The general syntax for this CLP command is db2 -td <terminating-character> -vf <CLP-script-name>

Note that option -td indicates that the CLP terminator default is to be reset with terminating character. The -vf indicates that the CLP's optional verbose (-v) option is to be used, which causes each SQL statement or command in the script to be displayed to the screen as it is run, along with any output that results from its execution. The -f option indicates that the target of the command is a file.

Now execute this procedure from CLP. You can use a CALL statement to invoke a stored procedure from the command line. The stored procedure should exist in the DB2 catalog (previously built), and a connection to the database should be established. The syntax for a CALL statement is db2 call procname (parm1, ….).

You also need to provide values for each IN and INOUT parameter and for the ? placeholder for each OUT parameter. Note that the data type of the parameters in the CALL statement should be compatible with the data types for the parameters in the CREATE PROCEDURE statement.

Now invoke the number_of_orders procedure using db2 call number_of_orders(‘Shipped’,current date, ?).

Figure 15. Using a CALL statement to invoke the number_of_orders procedure
Using a CALL statement to invoke the number_of_orders procedure

Using the SQL Explain Facility and the DB2 Access Plan

The SQL Explain Facility is part of the SQL compiler that you can use to capture information about the environment in which the static or dynamic SQL statement is compiled. Capturing this information enables you to evaluate different factors about the structure and performance of the SQL statements, including cost information, the sequence of operations required to process the query, predicates and selectivity estimates, and statistics for all objects referenced in the SQL statement at the time of the explain.

This information helps you understand:

  • Which execution plan is chosen for a query
  • What changes you could implement to optimize SQL code
  • Whether there is a need to change or add database structures to achieve better performance
  • Whether an application should be rebound

When the DB2 engine processes a query, the DB2 optimizer generates several alternative plans to access the requested data. The optimizer estimates the execution cost of each plan and chooses the lowest-cost plan to execute. This plan is called Access Plan.

DB2 Query Access Plan is an important aspect of the development process, because the efficiency of the SQL code you write is always important. Whether you are developing new code, implementing changes into an existing database application, upgrading to a new version of DB2, or generally working on performance optimization, working with the access plan is the best way to ensure sufficient performance of your SQL code.

DB2 provides several tools (both visual and command line) that you can employ to generate and retrieve this important information. The most common tools are:

  • Visual Explain in DB2 Control Center and Command Editor
  • DB2EXPLN and DB2EXFMT commands invoked from the command line
  • IBM Data Studio - Visual Explain
  • IBM Data Studio - SQL procedure profiling tool (Visual)

The choice of which tool to use depends on your preferences. For example, your preferences might indicate whether you prefer a GUI-interface (Visual Explain) or text output with an optional character-style graph (db2exfmt, db2expln), whether you require detailed optimizer information (Visual Explain or db2exfmt), and so on.

Figure 16. Diagram to illustrate the relationship between the DB2 Optimizer and SQL explain facility
Diagram to illustrate the relationship between the DB2 Optimizer and SQL explain facility

The explain information is stored in a set of tables called explain or plan tables. When using Visual Explain, these tables can be automatically created for you, and the information window can be displayed.

Figure 17. Informational message when the explain tables are automatically created by Visual explain in Command Editor:
Figure 17. Informational message when the explain tables are automatically created by Visual explain in Command Editor:

If you use the command line, you need to create these tables manually for the user ID that runs the explain facility. You could do that in either of the following two ways:

  • Run EXPLAIN.DDL provided in the ~/sqllib/MISC directory by entering the following:
    $ db2 connect to sample
    $ db2 -tf ~/sqllib/MISC/EXPLAIN.DDL
    $ db2 terminate
  • Run the SYSINSTALLOBJECTS system stored procedure to create the explain tables:
    $ db2 connect to sample
    $ db2 "CALL SYSPROC.SYSINSTALLOBJECTS('EXPLAIN','C',NULL,CURRENT SCHEMA)"
    $ db2 terminate

You can also query the Explain tables directly to gather performance information using standard SQL statements.

Using Visual Explain

Visual Explain graphically displays the access plan for any explainable SQL or XQuery statement, including INSERT, UPDATE, DELETE, MERGE, VALUES, REFRESH TABLE, and SET INTEGRITY. This display is called an access plan diagram, and it illustrates how DB2 optimizer accesses the data for a specified SQL statement. You can use the information available from the graph to tune your queries for better performance.

With Visual Explain you can:

  • View the statistics that were used at the time of optimization. You can then compare these statistics to the current catalog statistics to help you determine whether rebinding the package might improve performance.
  • Determine whether or not an index was used to access a table. If an index was not used, Visual Explain can help you determine which columns might benefit from being indexed.
  • View the effects of performing various tuning techniques by comparing the before and after versions of the access plan graph for a query.
  • Obtain information about each operation in the access plan, including the total estimated cost and number of rows retrieved (cardinality).
Figure 18. Interaction between the DB2 optimizer and Visual Explain when invoked from the Control Center
Interaction between the DB2 optimizer and Visual Explain when invoked from the Control Center

How to start Visual Explain

To start Visual Explain from the Control Center, right-click a database name and select either Show Explained Statements History or Explain Query.

Figure 19. Select Explain Query from the right-click menu to invoke Visual Explain
Select Explain Query from the right-click menu to invoke Visual Explain

To start Visual Explain from the Command Editor, run an explainable statement on the Interactive page or the Script page. To create an access plan without executing the statement, enter the explainable statement in the text area. Select Create access plan from the Interactive or Script menus, or click the Create access plan icon icon. To generate access plans and execute the statement at the same time, click the Generate access plans icon icon.

Command results are displayed in the output area of the Commands page, while SQL results are returned on the Query Results page. The access plan appears in graphical form on the Access Plan page.

An access plan graph is color and shape-coded, and it shows details about:

  • Tables (and their associated columns) and indexes
  • Operators, such as table scans, sorts, and joins
  • Table spaces and functions

The access plan diagram consists of nodes and lines that connect those nodes. The nodes represent data sources, operators, queries, and query blocks. Nodes can have only one parent node, but they can have unlimited child nodes. The arrows on the sides indicate the direction of the flow. Usually, a table node is at the bottom of the graph, and the access plan proceeds upward from there.

Each operation shows as a color-coded node in a tree structure. Clicking on a node enables you to view the arguments, statistics, and cost estimate of the node.

Figure 20. Example of an access plan graph
Example of an access plan graph

Generating an access plan using the DB2 command line

Visual Explain is intuitive and user friendly, but you don't always have access to a graphical environment (DB2 Control Center or IBM Data Studio). In these cases, there are two command line utilities you can use: DB2EXPLN and DB2EXFMT. The command line explain tools are usually located in the misc subdirectory of your instance sqllib directory, or they appear in the PATH environment variable. The command line explain tools provide comprehensive information in a concise manner. Use the tools if you frequently analyze SQL statements for performance.

The DB2EXPLN tool

The DB2EXPLN tool describes the access plan selected for SQL and XQuery statements. For static SQL and XQuery statements, DB2EXPLN examines the packages stored in the system catalog tables. For dynamic SQL and XQuery statements, DB2EXPLN examines the sections in the query cache. Use DB2EXPLN to obtain a quick explanation of the chosen access plan.

Figure 21. DB2EXPLN parameter list
DB2EXPLN parameter list

As shown in Figure 21, DB2EXPLN has many command line parameters to use according to the current requirements in different combinations. The examples below demonstrate the parameters that are most commonly used. For more details refer to the DB2EXPLN documentation (see Resources).

The DB2EXFMT tool

You can use the DB2EXFMT tool to format the contents of the explain tables. The tool also has many command line parameters to use according to the current requirements. More detailed information is available in the DB2EXFMT documentation (see Resources).

Figure 22. DB2EXFMT parameter list
DB2EXFMT parameter list

Examples of generating access plans from the DB2 command line

Follow the steps in this section to generate access plans from the DB2 command line. Two examples are provided. The first example generates the access plan for an SQL PL procedure. The second example takes the SQL statement from the routine and uses Explain mode and the DB2EXFMT tools.

Example 1

Step 1: If this is the first time you are running Explain with this user ID, manually create the explain tables where all the explain data is stored by running the script db2 -tvf ~/sqllib/misc/EXPLAIN.DDL.

Step 2: Set parameters to instruct the query compiler to gather the explain information and populate the explain tables.

For SQL statements, you can use: db2 set current explain mode explain. This puts DB2 in explain mode, and the explain data is gathered on all subsequent queries without actually running them. Remember to run db2 set current explain mode no when you are done with your access plans in Step 4, so all queries will run again.

For SQL PL procedures, use one of the following approaches:

  • (Recommended) Call SYSPROC.SET_ROUTINE_OPTS to set the explain directive at the DB2 session level so that you can control which procedures need to be explained within only the current session. You can skip this step if you include the following command at the top of the file you will run in Step 3: CALL SYSPROC.SET_ROUTINE_OPTS('EXPLAIN ALL');
  • Set DB2_SQLROUTINE_PREPOPTS at the instance level so that each procedure you create is explained. Remember that setting this option on instance level requires restarting the database, and it affects all users and statements. Use:
    $ db2set DB2_SQLROUTINE_PREPOPTS="EXPLAIN ALL EXPLSNAP ALL"
    $ db2stop
    $ db2start

Step 3: Run the desired workload. You can run a separate statement, or you can create and run a file with multiple with SQL/XPATH statements or SQL PL routines. For example, to run the example file called myscript.db2, enter db2 -td@ -vf myscript.db2

Figure 23. Content of myscript.db2 file
Content of myscript.db2 file

Step 4: Extract Explain Plan using the db2expln or db2exfmt tools to format the contents of the explain tables as follows: db2exfmt -d sample -g TIC -w -1 -n % -s % -# 0 -o exfmt_output.out.

Figure 24 shows a summary of Step 2 to Step 4 that shows how this process looks in the CLP window using DB2EXFMT.

Figure 24. myscript.db2 file for Example 1
myscript.db2 file for Example 1

Detailed information about the access plan for procedure NUMBER_OF_ORDERS is in the file exfmt_output.out. By using this information, you can see which indexes are being used as well as other performance considerations about this query.

Figure 25 shows a similar result when DB2EXPLN is used. For example, the procedure you created in the previous steps is called directly from the command line using DB2EXPLN. Use the following command to generate and display the output in the terminal: db2expln -d sample -statement "call number_of_orders ('Shipped', current date, ?)" –terminal.

Figure 25. DB2EXPLN statement calls the procedure
DB2EXPLN statement calls the procedure

Example 2

To obtain more detailed information about an SQL statement inside SQL routines (such as procedures and functions), you could execute only the query portion of the routine and run it through Explain Mode and DB2EXFMT tools. Here's how to simply follow the steps defined in this tutorial:

Step 1: Be sure the Explain tables are created or create them manually.

Step 2: Instruct DB2 optimizer to collect the explain data without actually running the SQL statement using db2 set current explain mode explain

Step 3: Run the select statement from the procedure NUMBER_OF_ORDERS you created above. For simplicity, substitute the IN parameters with hard-coded values, and remove the OUT parameter. Use db2 "SELECT count (poid) FROM PURCHASEORDER WHERE ucase (status) = ucase ('Unshipped') AND orderdate < CURRENT DATE"

After running this select statement, you see the following warning message indicating the statement was explained but has not been executed: SQL0217W The statement was not executed as only Explain information requests are being processed. SQLSTATE=01604

Remember to turn off the explain plan mode using db2 set current explain mode no.

Step 4: As in the first example, generate the text output using the db2exfmt command: db2exfmt -d sample -g TIC -w -1 -n % -s % -# 0 -o exfmt_output.out

Figure 26 shows the resulting summary screen.

Figure 26. Explaining SQL statement with Explain mode and DB2EXFMT
Explaining SQL statement with Explain mode and DB2EXFMT

All detailed explain information is located in the exfmt_output.out file DB2EXFMT generated. Examine the text file and look for possible performance improvements. The information is separated in several sections, including Database and Package Context, Original and Optimized statement, Access Plan, Plan Details, Objects Used in Access Plan, Extended Diagnostic Information, and so on. Figure 27 shows the Access Plan character style graph generated in this file.

Figure 27. Access Plan presented with character style graph
Access Plan presented with character style graph

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=366135
ArticleTitle=DB2 9.5 SQL Procedure Developer exam 735 prep, Part 6: DB2 development tools
publish-date=01222009