Max and Lyon
There is an additional wrinkle to this backup recovery issue.
In a single shop there can be many groups with diffrerent but over
stakes in the Business Continuity world. For example
The storage Management team may have the responsibility for
PRODUCTION and SYSTEM DASD back ... These are often to copy
DB2 terms and the backups are taken quite independently of what DB2
or might not be doing at the moment.
The Systems Programmers / System DBA's Here the backup / recovery
to be very bookish ... we will restrore the DB2 subsystem to
current is defined as to the latest logs available at DR. We will
intrastructure support (Software and logs) to allow application
recover there objects to 'current'
Applications. From my own perspective this is where things get a
It is not uncommon for an application group to arugue
PIT recoveries only and then we will simply rerun the updating
The primary key of our big objects is date related so we know what
have changed and what parts have not. Why back up (Image copy
that have not changed for years
What tends to happen is things get bumped up the chain, An
recovery failure results in they claiming the SysProgs SysDBAs
should of been
better prepared. A DB2 system recovery failure is usually the fault
Management, A Storage management failure gets blamed on the
system group. Operating system problems usually gets blamed on the
Continuity plan etc etc etc
The problem is each of these groups has diffrent procedures and
As a result when procedures get more and more diffrent groups take
to CYA (Cover Your Ass) For example many storage management groups
back up DB2 database volumes no matter how lould people screem WE
From a DB2 Systems standpoint CYA calls for coping things when the
copy in SYSCOPY approaches or exceeds the log archive rentenion
Typically an attempt should be made to charge a lot for this
Municipalities will often shovel the snow for lazy homeowners and
levy a Big
FEE its the same idea.
The CYA requirements tend to be reduced in shops that have
policies. When application groups have expected and monitored
for copies there is less CYA work for the SysProgs.
By the way I don't whant people to think I am picking on
everyone sees the world through there own glasses and mine are
those of an
old time SysProg.
On Fri, 11 Jan 2008 09:16:07 +0100, [login to unmask email]
>I agree with Lyon. In many shops I saw there's no a 'approved'
>it depends on SLAs (if any), on type of business the company
does, down to
>the single DBA's ideas about backups.
>And a given strategy change over the time: for example moving
>IC-based DR to a DASD-replication DR. So don't consider a
>a 'strategy forever', nothing is forever (even love. If it is,
>you're a candidate for elections in US).
>Among the many things, consider that a IC-based backup strategy
>in the sense that you can manage it by your own, while a
>(actually it's used for DR purposes) is somewhat 'system-wide'
and has a
>more limited field of use. And you've to ask for help to your
>As I said some years ago (when I thought things were all white
or or all
>black) you have to detect the 'heartbeat' (or wavelength as I
call it) of
>main applications (ie a meaningful period of applications
>heartbeat is known, your IC strategy become quite clear.
>For instance, historical tables usually have a long-period
>(weekly monthly, yearly...) ie they are not updated so
>tables (or something similar) are updated not so often.
>Orders tables are updated every second. Some bank table$ are
updated a lot
>during some periods (say Xmas). Some others are updated
randomly. And all
>of the are updated batch, online or both.
>The only hint I can give to you is: it's better to have one IC
>than one IC missing. This is your real goal.
>Certified DB2 Jedi Knight
>Star join wars department
> "Lyon, Lockwood"
> <[login to unmask email]
> .COM> To
> Sent by: DB2 Data [login to unmask email]
> Base Discussion cc
> <[login to unmask email] Subject
> ORG> Re: [DB2-L] DB2 Backups Strategy on
> 09/01/2008 23.48
> Please respond to
> DB2 Database
> Discussion list
> at IDUG
> <[login to unmask email]
>As I have expounded in multiple articles and IDUG
>shops go about this backwards. They keep asking about
>strategies. There are no such: there are only "backup tactics"
>support a Recovery Strategy.
>I recommend you review your Tablespace/Index recovery
>applications have SLAs regarding downtime during a recovery,
>combination of backup strategies do you need to meet those
>Example: a 100GB table with a 50 GB partitioning index. The
>(a financial one) requires that any outage be no more than 30
>In our case, while it might have been possible to recover the
>from multiple partition backups, the REBUILD of the Index took
>hours. Hence, we had to consider: (a) Index Image Copies; (b)
>mirroring; (c) "Shadow" tables; and, (d) other backup
>Fifth Third Bancorp
The IDUG DB2-L Listserv is only part of your membership in IDUG.
DB2-L list archives, the FAQ, and delivery preferences are at
the Listserv tab. While at the site, you can also access the IDUG
Online Learning Center, Tech Library and Code Place, see the latest
IDUG conference information, and much more. If you have not yet
signed up for Basic Membership in IDUG, available at no cost, click
on Member Services at http://www.idug.org/lsms