Common Deployment Considerations for LUW and zSeries

DB2 LUW and DB2 on zSeries have a number of common options for deploying DB2 objects. This section covers the common deployment methods and traits.

Deploying from One Database to Another

Often procedures need to be moved from a test environment to a production environment, and having a complicated system of recording files and redeploying may not be practical. To simplify the movement from one system to another, you can instead use the Deploy option in the Development Center. This allows you to move the procedures directly from one cataloged system to another.

To use the Deploy option, you can either right-click on the Stored Procedure folder or right-click on an individual stored procedure and choose Deploy. The individual option is shown in Figure 11.18. You may also start the deployment option directly from the Development Center start-up menu. The Deploy option is recommended when you are supporting multiple environments, because it will work with both LUW and with zSeries. It also allows you to deploy several stored procedures at a time, unlike the Import option.

Figure 11.18. Selecting the Deploy options for a stored procedure.

Once you have selected which procedure you are going to deploy, you can select the target server. The wizard will offer you a list of all the databases that you have cataloged on the system you are using. The tool will not check if the required tables and objects for the stored procedure on the source server exist on the target server. It is therefore important that you have your target database properly set up. The database selection of TEST2 as the target database is shown in Figure 11.19.

Figure 11.19. Selecting the target database.

Note

Figure 11.19 shows three steps on the left side of the window: Target database, Options, and Summary. If you had right-clicked on the Stored Procedure folder instead of right-clicking on an individual stored procedure, another step would have given you the option to choose the stored procedures to deploy.

A number of options control how the stored procedures are deployed on the target database. In Figure 11.20, if you select the Deploy Source to Database option, the procedure source will be placed in the catalog tables. The Deploy Using Binaries If Available option is used when a C compiler is required on the target server. If the option was chosen, the binarieswhich are the .SAR fileswould be exported to the target server. This option is no longer needed for DB2 for LUW with the addition of Native PSM. It should also not be applicable to zSeries. The Error Handling options allow you to control how the deploy process is handled. By not having the entire script roll back on a single failure, you can then correct your error and rerun just a small section of the script. Creating smaller scripts will also result in easier error detection and correction.

Figure 11.20. Deploy options.

The deployment options will make it a lot easier for you to move your procedures across the systems. Often your test and production systems are almost identical, and your changes may be fairly minor. By choosing DROP DUPLICATES, all the duplicate procedures on the target server will be dropped and replaced by those coming from the source server. This would be the best method for moving your tested changes into production. If you only want to deploy new procedures, and are concerned about overwriting duplicaate procedures on you production system, then make sure to select Treat Duplicates as Errors.

If you are performing a large-scale deployment of several stored procedures, then using scripts would probably be the most effective method. If, however, you would like to deploy the scripts on zSeries, you will also need to write the JCL to execute them and add the bind and compile steps. However, if you are only moving a few procedures from test to production, then the Deploy tool will make your life a lot easier.