52 DB2 10 for Linux on System z Using z/VM v6.2, SSI Clusters and LGR
Last committed transaction = 2012-06-14- UTC
DB20000I The ROLLFORWARD command completed successfully.
As expected, all records were restored (Example 5-25).
Example 5-25 All records have been restored sucessfuly even with the wrong timestamp
db2inst1@itsolnx1:~> db2 "select received,source from in_tray2"
-------------------------- --------
2012-06-14- right1
2012-06-14- right2
2012-06-14- right11
2012-06-14- right12
2012-06-14- wrong1
2012-06-14- wrong2
2012-06-14- wrong11
2012-06-14- wrong12
8 record(s) selected.
As a result of the sequence of events in this case (Example 5-21 and Example 5-25), DB2
restore and rollforward commands are not affected by a configuration using the wrong time.
However, the data integrity is affected. Be aware that if your data uses a current timestamp, it
picks up the time from the guest and applications may face issues. Avoiding this issue is
analyzed in the next section.
5.2 Network Time Protocol (NTP)
A standard way of keeping dates synchronized is by using NTP. It is widely used to
synchronize computer clocks via the Internet. It will always keep the time synchronized in
your environment, even if it has been relocated to hardware that has the wrong time and the
server has been rebooted.
5.2.1 Configuring NTP
The NTP configuration file is located at /etc/ntp.conf. If you do not have this file, the NTP
package is probably not installed, so you can use the package management tool of your Linux
distribution to install it.
A basic configuration file follows in Example 5-26.
Example 5-26 ntp.conf basic configuration
server aaa.bbb.ccc.ddd
# Drift file.
driftfile /var/lib/ntp/drift/ntp.drift
Chapter 5. Time synchronization 53
This basic configuration defines the server used to synchronize your time and a drift file that
stores the error frequency (drift). If the daemon is stopped and restarted it can reinitialize
itself to the previous estimate without spending time recomputing the frequency estimate,
based on the drift file. This file is required, so please check its permissions to avoid errors.
The file used in our lab had more parameters. This is just an example of the configuration
used in our experiments (Example 5-27).
Example 5-27 Configuration file used in our test server
itsolnx1:~ # cat /etc/ntp.conf
## NTP config file
# path for drift file
driftfile /var/lib/ntp/drift/ntp.drift
# alternate log file
logfile /var/log/ntp
# Authentication stuff
# path for keys file
keys /etc/ntp.keys
# define trusted keys
trustedkey 1
requestkey 1
server iburst
This configuration uses some security parameters to control access to the NTP server. When
an NTP daemon is first set up, it is also set as an NTP server, not only as a
client, meaning that by default the NTP server is accessible from all hosts in your network.
The restrict parameter allows you to limit this access, if needed, and also will limit how the
NTP server acts on your server. In the configuration shown in Example 5-27,
we have not restricted access in any way, but for further information you can check the
ntp.conf man page or:
As soon as the configuration is complete, you can start the NTP daemon in order to start time
synchronization (Example 5-28).
Example 5-28 Starting the NTP daemon
itsolnx1:~ # /etc/init.d/ntp start
Starting network time protocol daemon (NTPD)
Also, set NTPservice to load at boot time, which on SLES or Red Hat Enterprise Linux can be
done by using the chkconfig utility (Example 5-29).
Example 5-29 Setting up NTP to start at boot time
itsolnx1:~ # chkconfig ntp on
itsolnx1:~ # chkconfig --list ntp
ntp 0:off 1:off 2:off 3:on 4:off 5:on 6:off

Get DB2 10 for Linux on System z Using z/VM v6.2, Single System Image Clusters and Live Guest Relocation now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.