With the growth of data, the reduction in of DBA staffing, tight budgets, and the business goal to be 24x7 it is becoming more important to automate

Transcription

1 1

2 With the growth of data, the reduction in of DBA staffing, tight budgets, and the business goal to be 24x7 it is becoming more important to automate as much Database Administration work as possible. 2

3 IBM has always provided us with some Metadata tools for DB2: Runstats and since V7 Real time Stats (RTS) to help determine the health of data structures. This data can be used either with IBM or other vendors tools. However, in today s environments, purchased tools are often unavailable. By using the Metadata tables supplied by IBM along with a scripting language like REXX it is possible to create your own automation. 3

4 4

5 Runstats and RTS are both processes to gather statistics in DB2. These statistics can serve multiple purposes. One purpose is to make decisions on maintenance. RUNSTATS are a 'hands on' administrative process; RTS is a 'hands off' process. Here are some of the differences: 5

6 6

7 Metadata is data about your data. RTS and Runstats Metadata can be used to drive the automation of your maintenance and utilities. However, to customize your processes, I recommend also having an installation specific Metadata database. This would have account specific information such as: 7

8 This is just a suggested list and can be supplemented by any account specific information you feel is necessary. 8

9 9

10 10

11 One tool you can use if you don t want to develop from scratch is the sample stored procedure DSNACCO(R)X (early version ends with R V9 forward with X). You will need to build a program to call it, perhaps REXX an example of which can be located on the web ( script xmpaccox execute db2 v9 zos databases using dsnaccox stored procedure/). It can be used to query the RTS tables and make recommendations based on them. You can use DSNACCO(R)X to recommend when to run a RUNSTATS, take an image copy or run a REORG. It can also report on the data set extents of all spaces and on objects in a restricted state. With use of parameters, DSNACCO(R)X can be used to specify which table spaces and indexes to analyze, or just run it without parameters to evaluate all spaces in the subsystem. This would give you information and suggest what you need to run. However, you still need to build and submit your jobs. 11

12 DSNACCO(R)X can be used in conjunction with Data Studio (the part that used to be DB2 Control Center). Data Studio provides a nice GUI interface to the parameters of DSNACCO(R)X making it easier to use versus directly calling the procedure. 12

13 Many Vendor tools such as those listed below can be customized to interrogate your Metadata information: CA Database Analyzer BMC DASD MANAGER PLUS for DB2 IBM DB2 Automation Tool for z/os Customization of these tools is outside of the scope of this topic and would require additional training if one does not already possess the skill set. We will now discuss what to do if you don t have these, or can t count on them staying around. 13

14 Much data used is obtained from the DB2 Catalog. If desired, please refer to the following link for detailed information regarding the DB2 10 Catalog structure. ( bm.db2z10.doc.sqlref%2fsrc%2ftpc%2fdb2z_catalogtablesintro.htm). Later, we ll review one possible version of Account Specific Metadata. The final part of our toolkit is whatever programming skill we have (for most mainframe DBAs this is REXX, Edit Macros, JCL, ). We will use these to access all out Metadata (both IBM and Account Specific). 14

15 15

16 The above is one possible Account Metadata sample. Yours may be more complex depending what objects you are using. We will use this model to illustrate some sample admin tasks. 16

17 17

18 The final part of our toolkit is whatever programming skill we have (for most mainframe DBAs this is REXX, Edit Macros, JCL, ). We will use these to access all our Metadata (both IBM and Account Specific). 18

19 Once your Metadata is made generally available, you keep it up as changes are made to your data. This must be made a part of your change process, and included in your reviews. If you keep your Metadata up and do RUNSTATs as needed you will have a repository that can do the following: Serve as a Change Control tool for DB2 Objects Drive reporting on the condition of your DB2 Systems and Objects. Allow automation of Utilities We will go over each of these topics with examples. 19

20 20

21 21

22 To start with you can just make changes to the tables in any editor, as you develop this system, you would want to build an update screen with your Scripting tool (ex: REXX with ISPF panels). 22

23 23

24 24

25 25

26 The IBM Metadata tables in the catalog and your account Specific Metadata Database are the major part of what is needed to generate reports about the objects in your DB2 System. These reports would allow you to be aware of the condition of your DB2 objects and you DB2 Applications. You would do this by having a reporting program execute SQL and feed the results of your queries thru a report writer (such as File Aide, a REXX Script, Crystal Reports ). Have the job use IEBGENER to the reports to your team. Some report queries to be considered above. These would be a good starting point, with you adding more as you feel the need. Craig Mullins book DB2 Developers Guide sixth edition, has quite a few suggestions. 26

27 Here is an example of how you would report on Tablespaces that need Runstats taking into account the Account Specific Metadata. 27

28 This will give you all Tablespaces in the desired databases, in this case PROD1 and PROD2, that are allowed Runstats per the Account Specific Meta data, are greater than 5,000 rows and which also meet the one of the following criteria 28

29 Aside from using the catalog Metadata and the Account Specific Metadata, you can also get information from other sources. This would allow you to track even more information needed for optimizing your Databases. Some of these sources are listed above. These would allow you to report on your Objects, Application performance and resources. 29

30 Reporting on your DB2 Systems can have several benefits, some of which are listed above. Reports would give you information to receive any of the above benefits. There is also one other major benefit, information that is obtained for reporting can also be used to drive Utility Automation. 30

31 31

32 The next step would be automation; it is built on the report queries. In the case of a utility that needs to run, you would use the same SQL where clause with output being used to build a listdef and/or control cards for the utility Your jobs would look along the above steps. This job can always be rerun from the top from the top. If your SQL is correctly done it will never pick up any objects that have finished and it will cleanup any old jobs. 32

33 In the case of an alter to change an objects specific attribute, you would use the same SQL where clause with output being the DDL to alter the objects. This would not be restartable from the top, it could only run with an exclusive window and a DBA would need to look at what caused a problem if one happened. I would recommend only changing attributes that can be changed on the fly, like Bufferpool or Space (Priqty/Secqty). 33

34 Here is an example to create control cards for Runstats above. 34

35 This will give you all control cards for all Tablespaces in the desired databases. In this case PROD1 and PROD2, that are allowed Runstats per the Account Specific Meta data, are greater than 5,000 rows and which also meet the one of the following criteria. 35

36 The Automation of your DB2 Systems Utilities and Maintenance Alters can have several benefits, some of which are listed above. Put more simply, you will get more work done with less effort, because you will not need to be constantly coding routine work. This frees you up for design and tuning which is what will improve your system performance. 36

37 37

38 38