Are you an application DBA, but you hear the call of DB2 system administration? Then this session is for you. We will explain different aspects and

Transcription

1 Are you an application DBA, but you hear the call of DB2 system administration? Then this session is for you. We will explain different aspects and must- know aspects to become a system administrator on DB2. First we will look at the kind of tasks are expected from a system administrator, then we will dive in knowledge concepts and practical ready to use examples of how certain task must be performed. Did you ever wonder about installation, migration, applying maintenance and how it should be done? Do you want to know more about disaster recovery and how to prepare for it? How should you capture dumps for problem analysis and how do you get them to IBM? This action packed session will bundle, basic information, advanced understanding, good practices, ready to use scripts. Get ready to get started on the system 1

2 2

3 SMP/E manages multiple software versions, helps apply patches and updates (PTFs), facilitates orderly testing and, if necessary, reversion to a previous state, allows a "trial run" pseudo-installation to verify that actual installation will work, keeps audit and security records to assure only approved software updates occur, and otherwise provides highly evolved, centralized control over all software installation on z/os 3

4 Example DB2 11 for z/os required FMIDs : HDBBB10 (DB2 Base) HIYBB10 (IMS Attach - must be installed even if you do not have IMS) HIZBB10 (Subsystem Initialization) HIR2230 (IRLM V ) HDREB10 (DB2 RACF Authorization Exit) JDBBB14 (DB2 English Panels) Optional FMIDs: JDBBB12 (DB2 JDBC/SQLJ) JDBBB17 (DB2 ODBC) JDBBB11 (DB2 Kanji Panels, delivered with Japanese feature) Each SYSMOD is assigned a seven character SYSMOD ID to uniquely identify it. When the SYSMOD is installed this ID is recorded in the CSI entry for the element being added or replaced. 4

5 5

6 6

7 7

8 8

9 9

10 10

11 11

12 DSNTIJMV updates SYS1.PARMLIB SYS1.PROCLIB 12

13 13

14 14

15 15

16 ssiddist : treats all the distributed calls DB2PWLM* : are used to run fenced stored procedures, messages and errors of a stored procedure can be found in it s corresponding WLM-tasks. the name of these WLM-tasks can be chosen freely, starting them with the same ssid prefix is a good idea. 16

17 DB2 Master address space shows when DB2 was started, shows error messages etc, shows when a log was full etc DB2 mstr is comparable to the DB2diag log. The + sign that is circled on the slide, is the command recognition character. This is used, when giving commands to DB2, to identify the DB2 you are addressing. Personally I prefer a better chosen recognition character. Then +, I prefer -ssid or that would be in this case -DB2P. This is a choice of the person installing DB2. 17

18 All needed information is on the slide Now let s see how we can interact in an other way with DB2 on z/os. 18

19 19

20 20

21 21

22 22

23 23

24 24

25 25

26 26

27 27

28 28

29 29

30 30

31 31

32 32

33 33

34 34

35 35

36 36

37 37

38 38

39 39

40 40

41 41

42 42

43 43

44 44

45 45

46 Logically the db2 log is a never ending log. Each log point has a relative byte address (RBA) which makes it unique. 46

47 However sometimes an RBA is not enough. In case of a data sharing environment, we have two or more DB2 subsystems that pretend and behave as a single subsystem. The problem is that each DB2 member has its own logging, and therefore a RBA might be unique within one member, but not in the data sharing group. In order to solve this, IBM started using the LRSN, which is a modified timestamp based on the sysplex store clock. 47

48 Underlying this logical never ending log, is a number of physical datasets. The conditions are on slide. 48

49 DB2 will start writing in the first active log dataset until it is full, then it switches over the second vsam dataset. Meanwhile DB2 starts offloading the first dataset to archive the information. Hence the name archive log. When we get to the last active log dataset, DB2 wraps around the first active log dataset. 49

50 One of the question I often receive is, how many active log datasets should I define? If possible, I try to get to a situations that in normal conditions, I keep the last 24h in my active log datasets and ALWAYS have dual logging in place. 50

51 As a part of logging there is another extremely important construct in DB2. it s called the Boot Strap Data Set (BSDS). It contains (amongst other information) the active and archive log description and start & end rba for each log. You could see this as an index of your log datasets. In order for DB2 to start up, you need two identical BSDS-files. 51

52 52

53 When we said earlier DB2 archives the log into an archive log file. We should have said archive log files. DB2 always writes out 2 files. First it writes it out the B-file (containing the current content of the BSDS) Secondly it writes out the A-file (containing the actual log records) 53

54 The archive log is mostly controlled by DSNZPARMS 54

55 DB2 does not write messages, or trace output to the log. However it does write a whole lot of information to the log. The list is on the slide. 55

56 This slide explains what DB2 writes to it s log during a system check point. All information is on the slide 56

57 57

58 DB2 uses it s log at start up time. As a matter of fact you can start up DB2 without catalog and directory, but not without a log. DB2 always processes the log in the same manner (after normal shutdown or abend). We can always see those 4 phases in the DB2 mstr address space. 58

59 59

60 60

61 This are some parameters that can influence the speed of start up. URLGWTH : the more long running threads you have, the longer startup might take. CHKFREQ : DB2 always start processing from its last system checkpoint, frequent checkpoints are a must for a speedy startup. LBACKOUT : as long as all 4 phases have not complete, NOBODY can work on the system. By using LBACKOUT=NO, everyone is punished for one badly behaving (read not committing) thread. LBACKOUT=AUTO will limit the back out processing to a number of checkpoints (default 5). The recovery of those threads will be postponed until after DB2 started up. PCLOSEN/PCLOSET : number of system checkpoints / minutes before a data set switches from RW to RO. Lower value of these parameters can greatly improve start up time (default 5 checkpoints or 10 minutes). The database buffers for that page set is, SYSLGRNX is updated, there for less logs to be scanned. When DB2 is shutting down, let it shutdown (even if it takes long). DB2 taking a long time to shutdown is a symptom (of not committing threads) not a 61

62 cause. 61

63 62

64 63

65 64

66 65

67 66