Input on best option for Year End data capture.

Suzanne Nichols

Input on best option for Year End data capture.
Listers,

We are reviewing several options to accomplish a year end production
backup of production data. This backup to be used for a large project
that is still in QA and needs to be from the time after all transaction
data from 12/31 is captured but before any year end processing begins.
The project needs to be able to load all the test tables with the data
from the production backups.

Operations can not delay year end processing for the period of time that
it would take to run a full imagecopy on tablespaces needed. It was
suggested that a full imagecopy be run on 12/29 when there is plenty of
time and then run incremental imagecopies on 12/31. They usually do an
unload from a full to get load data for the test tables. This will not
work the same with the full and the incremental.

1. Thought about trying to use merge but find that the merges would
have to be run before any other imagecopies where run. Unfortunately,
my understanding is that you can only merge to current. You can't
exclude a later imagecopy. Again, we don't have time for that.

2. Wonder if we can use an unload from the imcremental and the unload
from the full. I ran a test to make sure I could run an unload from an
incremental. Does anyone have experience with this? ..... Sort the
datasets and remove dups?

3. What about trying to use the full and incremental imagecopy and put
them to the test tables. What kind of translate of obids........ would
have to be done with what utility? Can anyone shed any light on an
approach like this?

4. Other ideas?

We are talking approximately 900 tablespaces.

Thanks for any input you can give.

Suzanne Nichols
Contractor at Kentucky Farm Bureau
Louisville, KY



The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under 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

Phil Grainger

Re: Input on best option for Year End data capture.
(in response to Suzanne Nichols)
Hi Suzanne

One thing you could do is to use DSN1COPY to write each full copy to DASD, then (also using DSN1COPY) write the incrementals over the top - this will replace updated pages with their later versions. You could then use the result as an input to a DSN1COPY OBIDXLAT or even as the source of a consistent Unload

Alternatively, have you investigated whether your hardware is capable of taking a snapshot of ALL of the datasets at the relevant moment - you could then use the snapped datasets as DSN1COPY sources for your copy. This is the option I'd perhaps be favouring as once you have captured the snapshot, you can decide what to do with it at your leisure in the new year

This isn't really a good time to be planning this (as I am sure you know!) as you only have a few days to decide what to do, how to do it and to practice.....

Phil Grainger
CA

________________________________

From: DB2 Data Base Discussion List on behalf of Nichols, Suzanne
Sent: Fri 21/12/2007 20:20
To: [login to unmask email]
Subject: [DB2-L] Input on best option for Year End data capture.



Listers,

We are reviewing several options to accomplish a year end production backup of production data. This backup to be used for a large project that is still in QA and needs to be from the time after all transaction data from 12/31 is captured but before any year end processing begins. The project needs to be able to load all the test tables with the data from the production backups.

Operations can not delay year end processing for the period of time that it would take to run a full imagecopy on tablespaces needed. It was suggested that a full imagecopy be run on 12/29 when there is plenty of time and then run incremental imagecopies on 12/31. They usually do an unload from a full to get load data for the test tables. This will not work the same with the full and the incremental.

1. Thought about trying to use merge but find that the merges would have to be run before any other imagecopies where run. Unfortunately, my understanding is that you can only merge to current. You can't exclude a later imagecopy. Again, we don't have time for that.

2. Wonder if we can use an unload from the imcremental and the unload from the full. I ran a test to make sure I could run an unload from an incremental. Does anyone have experience with this? ..... Sort the datasets and remove dups?

3. What about trying to use the full and incremental imagecopy and put them to the test tables. What kind of translate of obids........ would have to be done with what utility? Can anyone shed any light on an approach like this?

4. Other ideas?

We are talking approximately 900 tablespaces.

Thanks for any input you can give.

Suzanne Nichols
Contractor at Kentucky Farm Bureau
Louisville, KY



The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at www.idug.org <http://www.idug.org/lsidug> under 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 < http://www.idug.org/lsconf > , and much more.
If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services < http://www.idug.org/lsms >

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under 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

Suzanne Nichols

Re: Input on best option for Year End data capture.
(in response to Phil Grainger)
Phil,

Thank you for the suggestions. I agree, this is not a good time to be
planning this. However, I just found out about the need yesterday.
That is why input from the list is so helpful..

Could you explain futher what you mean by "write the incrementals over
the top". I understand that we would create a sequential dataset on
DASD from running dsn1copy with the full imagecopy as input. Then
?????? with the incremental. Last step, run dsn1copy
obidxlat with combined dsn1copy dataset to as input to test tablespace?


Suzanne

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]
On Behalf Of Grainger, Phil
Sent: Friday, December 21, 2007 3:27 PM
To: [login to unmask email]
Subject: Re: [DB2-L] Input on best option for Year End data
capture.


Hi Suzanne

One thing you could do is to use DSN1COPY to write each full
copy to DASD, then (also using DSN1COPY) write the incrementals over the
top - this will replace updated pages with their later versions. You
could then use the result as an input to a DSN1COPY OBIDXLAT or even as
the source of a consistent Unload

Alternatively, have you investigated whether your hardware is
capable of taking a snapshot of ALL of the datasets at the relevant
moment - you could then use the snapped datasets as DSN1COPY sources for
your copy. This is the option I'd perhaps be favouring as once you have
captured the snapshot, you can decide what to do with it at your leisure
in the new year

This isn't really a good time to be planning this (as I am sure
you know!) as you only have a few days to decide what to do, how to do
it and to practice.....

Phil Grainger
CA

________________________________

From: DB2 Data Base Discussion List on behalf of Nichols,
Suzanne
Sent: Fri 21/12/2007 20:20
To: [login to unmask email]
Subject: [DB2-L] Input on best option for Year End data capture.



Listers,

We are reviewing several options to accomplish a year end
production backup of production data. This backup to be used for a
large project that is still in QA and needs to be from the time after
all transaction data from 12/31 is captured but before any year end
processing begins. The project needs to be able to load all the test
tables with the data from the production backups.

Operations can not delay year end processing for the period of
time that it would take to run a full imagecopy on tablespaces needed.
It was suggested that a full imagecopy be run on 12/29 when there is
plenty of time and then run incremental imagecopies on 12/31. They
usually do an unload from a full to get load data for the test tables.
This will not work the same with the full and the incremental.

1. Thought about trying to use merge but find that the merges
would have to be run before any other imagecopies where run.
Unfortunately, my understanding is that you can only merge to current.
You can't exclude a later imagecopy. Again, we don't have time for that.


2. Wonder if we can use an unload from the imcremental and the
unload from the full. I ran a test to make sure I could run an unload
from an incremental. Does anyone have experience with this? ..... Sort
the datasets and remove dups?

3. What about trying to use the full and incremental imagecopy
and put them to the test tables. What kind of translate of
obids........ would have to be done with what utility? Can anyone
shed any light on an approach like this?

4. Other ideas?

We are talking approximately 900 tablespaces.

Thanks for any input you can give.

Suzanne Nichols
Contractor at Kentucky Farm Bureau
Louisville, KY



The IDUG DB2-L Listserv is only part of your membership in IDUG.
DB2-L list archives, the FAQ, and delivery preferences are at
www.idug.org < http://www.idug.org/lsidug > under 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
< http://www.idug.org/lsconf > , and much more.
If you have not yet signed up for Basic Membership in IDUG,
available at no cost, click on Member Services
< http://www.idug.org/lsms >

The IDUG DB2-L Listserv is only part of your membership in IDUG.
DB2-L list archives, the FAQ, and delivery preferences are at
www.idug.org < http://www.idug.org/lsidug > under 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
< http://www.idug.org/lsconf > , and much more.
If you have not yet signed up for Basic Membership in IDUG,
available at no cost, click on Member Services
< http://www.idug.org/lsms >


The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under 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

Avram Friedman

Re: Input on best option for Year End data capture.
(in response to Suzanne Nichols)
Two suggestions

Do you have any 3rd party aids? A log tool that will allow you to do a logical
forward recovery? A back up tool that will allow you to do either a DB2
Change Accum type function or a share level referance IC under share level
change circumstances. If you don't have such tools how deep are your
pockets and great is your modivation ... Purchasing the product this evening
and installing and testing over the long weekend holiday could work. The
slezzy approach would be to go on trial.

On Dec 31 at the end of business declare a disaster and invoke your disaster
recovery process. Hopefully you recover to current under these
circumstances at an alternate site (after all it is a disaster). then you can
make the required backups at your DR site for your test system.

In most variations of both suggestions many people are going to have an
unhappy holiday season at work ... I would at least order pizza.


Avram Friedman

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under 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

James Campbell

Re: Input on best option for Year End data capture.
(in response to Avram Friedman)
What version of z/OS and what disk technology are you using? Can you stop db2d (or at
least quiesce write to force all updates to disk) and do a DFSMS COPY CONCURRENT -
hopefully utilising a SnapShot - on the tablespaces, then use DSN1COPY on the copies?

Otherwise, I'd suggest a log analysis tool to extract the updates from 29Dec to 31Dec (we
write dates as day/month down here in Oz). One advantage of this is that you can run the log
analysis after the event, so provided you keep the archive logs you can run this next year. Of
course you might have a few sleepless nights thinking about all the things that can go wrong.
(Do make sure you have DATA CAPTURE CHANGES turned on for all tables.)

What time do you need to be up on 1Jan? Can the schedule be changed?

James Campbell


On 21 Dec 2007 at 15:20, Nichols, Suzanne wrote:

>
> Listers,
> We are reviewing several options to accomplish a year end production backup of production
> data.This backup to be used for a large project that is still in QA and needs to be from the time
> after all transaction data from 12/31 is captured but before any year end processing begins. The
> project needs to be able to load all the test tables with the data from the production backups.
> Operations can not delay year end processing for the period of time that it would take to run a full
> imagecopy on tablespaces needed. It was suggested that a full imagecopy be run on 12/29 when
> there is plenty of time and then run incremental imagecopies on 12/31. They usually do an unload
> from a full to get load data for the test tables. This will not work the same with the full and the
> incremental.
> 1. Thought about trying to use merge but find that the merges would have to be run before any
> other imagecopies where run. Unfortunately, my understanding is that you can only merge to
> current. You can't exclude a later imagecopy. Again, we don't have time for that.
> 2. Wonder if we can use an unload from the imcremental and the unload from the full. I ran a test
> to make sure I could run an unload from an incremental. Does anyone have experience with this?
> ..... Sort the datasets and remove dups?
> 3. What about trying to use the full and incremental imagecopy and put them to the test tables.
> What kind of translate of obids........ would have to be done with what utility? Can anyone shed
> any light on an approach like this?
> 4. Other ideas?
> We are talking approximately 900 tablespaces.
> Thanks for any input you can give.
> Suzanne Nichols
> Contractor at Kentucky Farm Bureau
> Louisville, KY
>
>

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under 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

Michael Ebert

Re: Input on best option for Year End data capture.
(in response to James Campbell)
Hi Suzanne,

how big and how active are your tablespaces? With luck you don't have to
copy all of them at the same time. Unfortunately it is not quite trivial
to find out this information. There are several possibilities. A couple of
years ago I posted a SAS program to parse the SYSLGRNX VSAM file,
extracting the info when each TS is active. I guess it should be on the
IDUG Code place (I'm a bit out of touch after doing mostly Oracle for 2
years). Another option is to run REPORT RECOVERY; however I've never used
that so I don't know how to do that exactly. One prerequisite for getting
sensible output is to have the appropriate PCLOSEN and PCLOSET values: I
recommend PCLOSEN=32767 (effectively disabling this parameter) and
PCLOSET=25 (mins).

The third possibility is to run a full IC on (or before) Dec 31st
(SHRLEVEL CHANGE) and then run another job at years end: in this job you
run an incremental IC with appropriate changelimits to take an IC only if
the TS was changed. Note that even when running this with SHRLEVEL REF you
do not have a guarantee that you get a systemwide consistent copy.
Probably the best strategy is to run a full IC before years end, then run
a conditional incremental IC with SHRLEVEL CHANGE close to midnight,
disable write traffic to the DB on midnight and run another conditional
incremental IC with SHRLEVEL REF after midnight.

The advantage is that you can run & test this before so that you can gain
some experience about runtimes and which TSs actually are quiet and which
are hot; and you don't need any special tools. You can then use the ICs to
populate a test DB, e.g. via DSN1COPY (with the usual caveats) or UNLOAD
FROMCOPY and reloading (maybe after running MERGECOPY to coalesce the
full and incremental ICs into one full IC).

Dr. Michael Ebert
DB2 & Oracle Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany




"Nichols, Suzanne" <[login to unmask email]>
To
[login to unmask email]
cc

bcc

Subject
[DB2-L] Input on best option for Year End data capture.





"Nichols, Suzanne" <[login to unmask email]>
Please respond to : DB2 Database Discussion list at IDUG
<[login to unmask email]>
Sent by: DB2 Data Base Discussion List <[login to unmask email]>
21-12-07 21:20


Listers,
We are reviewing several options to accomplish a year end production
backup of production data. This backup to be used for a large project
that is still in QA and needs to be from the time after all transaction
data from 12/31 is captured but before any year end processing begins. The
project needs to be able to load all the test tables with the data from
the production backups.
Operations can not delay year end processing for the period of time that
it would take to run a full imagecopy on tablespaces needed. It was
suggested that a full imagecopy be run on 12/29 when there is plenty of
time and then run incremental imagecopies on 12/31. They usually do an
unload from a full to get load data for the test tables. This will not
work the same with the full and the incremental.
1. Thought about trying to use merge but find that the merges would have
to be run before any other imagecopies where run. Unfortunately, my
understanding is that you can only merge to current. You can't exclude a
later imagecopy. Again, we don't have time for that.
2. Wonder if we can use an unload from the imcremental and the unload from
the full. I ran a test to make sure I could run an unload from an
incremental. Does anyone have experience with this? ?.. Sort the datasets
and remove dups?
3. What about trying to use the full and incremental imagecopy and put
them to the test tables. What kind of translate of obids??.. would have
to be done with what utility? Can anyone shed any light on an approach
like this?
4. Other ideas?
We are talking approximately 900 tablespaces.
Thanks for any input you can give.
Suzanne Nichols
Contractor at Kentucky Farm Bureau
Louisville, KY




IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for
the use of the individual or entity shown above as addressees . It may
contain information which is privileged, confidential or otherwise
protected from disclosure under applicable laws . If the reader of this
transmission is not the intended recipient, you are hereby notified that
any dissemination, printing, distribution, copying, disclosure or the
taking of any action in reliance on the contents of this information is
strictly prohibited. If you have received this transmission in error,
please immediately notify us by reply e-mail or using the address below
and delete the message and any attachments from your system .

Amadeus Data Processing GmbH
Geschäftsführer: Eberhard Haag
Sitz der Gesellschaft: Erding
HR München 48 199
Berghamer Strasse 6
85435 Erding
Germany

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under 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

Phil Grainger

Re: Input on best option for Year End data capture.
(in response to Michael Ebert)
Suzanne

Just run another DSN1COPY from your incremental (SYSUT1) to the "temp" on-DASD versions (SYSUT2)

DSN1COPY will overwrite the necessary pages, so far as I remember

Phil G
CA

________________________________

From: DB2 Data Base Discussion List on behalf of Nichols, Suzanne
Sent: Fri 21/12/2007 21:31
To: [login to unmask email]
Subject: Re: [DB2-L] Input on best option for Year End data capture.


Phil,

Thank you for the suggestions. I agree, this is not a good time to be planning this. However, I just found out about the need yesterday. That is why input from the list is so helpful..

Could you explain futher what you mean by "write the incrementals over the top". I understand that we would create a sequential dataset on DASD from running dsn1copy with the full imagecopy as input. Then ?????? with the incremental. Last step, run dsn1copy obidxlat with combined dsn1copy dataset to as input to test tablespace?

Suzanne

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Grainger, Phil
Sent: Friday, December 21, 2007 3:27 PM
To: [login to unmask email]
Subject: Re: [DB2-L] Input on best option for Year End data capture.


Hi Suzanne

One thing you could do is to use DSN1COPY to write each full copy to DASD, then (also using DSN1COPY) write the incrementals over the top - this will replace updated pages with their later versions. You could then use the result as an input to a DSN1COPY OBIDXLAT or even as the source of a consistent Unload

Alternatively, have you investigated whether your hardware is capable of taking a snapshot of ALL of the datasets at the relevant moment - you could then use the snapped datasets as DSN1COPY sources for your copy. This is the option I'd perhaps be favouring as once you have captured the snapshot, you can decide what to do with it at your leisure in the new year

This isn't really a good time to be planning this (as I am sure you know!) as you only have a few days to decide what to do, how to do it and to practice.....

Phil Grainger
CA

________________________________

From: DB2 Data Base Discussion List on behalf of Nichols, Suzanne
Sent: Fri 21/12/2007 20:20
To: [login to unmask email]
Subject: [DB2-L] Input on best option for Year End data capture.



Listers,

We are reviewing several options to accomplish a year end production backup of production data. This backup to be used for a large project that is still in QA and needs to be from the time after all transaction data from 12/31 is captured but before any year end processing begins. The project needs to be able to load all the test tables with the data from the production backups.

Operations can not delay year end processing for the period of time that it would take to run a full imagecopy on tablespaces needed. It was suggested that a full imagecopy be run on 12/29 when there is plenty of time and then run incremental imagecopies on 12/31. They usually do an unload from a full to get load data for the test tables. This will not work the same with the full and the incremental.

1. Thought about trying to use merge but find that the merges would have to be run before any other imagecopies where run. Unfortunately, my understanding is that you can only merge to current. You can't exclude a later imagecopy. Again, we don't have time for that.

2. Wonder if we can use an unload from the imcremental and the unload from the full. I ran a test to make sure I could run an unload from an incremental. Does anyone have experience with this? ..... Sort the datasets and remove dups?

3. What about trying to use the full and incremental imagecopy and put them to the test tables. What kind of translate of obids........ would have to be done with what utility? Can anyone shed any light on an approach like this?

4. Other ideas?

We are talking approximately 900 tablespaces.

Thanks for any input you can give.

Suzanne Nichols
Contractor at Kentucky Farm Bureau
Louisville, KY



The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at www.idug.org <http://www.idug.org/lsidug> under 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 < http://www.idug.org/lsconf > , and much more.
If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services < http://www.idug.org/lsms >

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at www.idug.org <http://www.idug.org/lsidug> under 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 < http://www.idug.org/lsconf > , and much more.
If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services < http://www.idug.org/lsms >


The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at www.idug.org <http://www.idug.org/lsidug> under 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 < http://www.idug.org/lsconf > , and much more.
If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services < http://www.idug.org/lsms >

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under 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

Mike Kalena

Re: Input on best option for Year End data capture.
(in response to Phil Grainger)
Suzanne,

I didn't realize DSN1COPY could do this either but we're going to try it
too. I found the doc is very good:

http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dsnugh18/3.7.1.2?SHE
LF=&DT=20061201100238


Michael Kalena
973-793-2133
[login to unmask email]

DB2 Info Page at BSC
(http://whsysops1/db2/)


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Grainger, Phil
Sent: Saturday, December 22, 2007 3:10 PM
To: [login to unmask email]
Subject: Re: [DB2-L] Input on best option for Year End data capture.

Suzanne

Just run another DSN1COPY from your incremental (SYSUT1) to the "temp"
on-DASD versions (SYSUT2)

DSN1COPY will overwrite the necessary pages, so far as I remember

Phil G
CA

________________________________

From: DB2 Data Base Discussion List on behalf of Nichols, Suzanne
Sent: Fri 21/12/2007 21:31
To: [login to unmask email]
Subject: Re: [DB2-L] Input on best option for Year End data capture.


Phil,

Thank you for the suggestions. I agree, this is not a good time to be
planning this. However, I just found out about the need yesterday.
That is why input from the list is so helpful..

Could you explain futher what you mean by "write the incrementals over
the top". I understand that we would create a sequential dataset on
DASD from running dsn1copy with the full imagecopy as input. Then
?????? with the incremental. Last step, run dsn1copy
obidxlat with combined dsn1copy dataset to as input to test tablespace?


Suzanne

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]
On Behalf Of Grainger, Phil
Sent: Friday, December 21, 2007 3:27 PM
To: [login to unmask email]
Subject: Re: [DB2-L] Input on best option for Year End data
capture.


Hi Suzanne

One thing you could do is to use DSN1COPY to write each full
copy to DASD, then (also using DSN1COPY) write the incrementals over the
top - this will replace updated pages with their later versions. You
could then use the result as an input to a DSN1COPY OBIDXLAT or even as
the source of a consistent Unload

Alternatively, have you investigated whether your hardware is
capable of taking a snapshot of ALL of the datasets at the relevant
moment - you could then use the snapped datasets as DSN1COPY sources for
your copy. This is the option I'd perhaps be favouring as once you have
captured the snapshot, you can decide what to do with it at your leisure
in the new year

This isn't really a good time to be planning this (as I am sure
you know!) as you only have a few days to decide what to do, how to do
it and to practice.....

Phil Grainger
CA

________________________________

From: DB2 Data Base Discussion List on behalf of Nichols,
Suzanne
Sent: Fri 21/12/2007 20:20
To: [login to unmask email]
Subject: [DB2-L] Input on best option for Year End data capture.



Listers,

We are reviewing several options to accomplish a year end
production backup of production data. This backup to be used for a
large project that is still in QA and needs to be from the time after
all transaction data from 12/31 is captured but before any year end
processing begins. The project needs to be able to load all the test
tables with the data from the production backups.

Operations can not delay year end processing for the period of
time that it would take to run a full imagecopy on tablespaces needed.
It was suggested that a full imagecopy be run on 12/29 when there is
plenty of time and then run incremental imagecopies on 12/31. They
usually do an unload from a full to get load data for the test tables.
This will not work the same with the full and the incremental.

1. Thought about trying to use merge but find that the merges
would have to be run before any other imagecopies where run.
Unfortunately, my understanding is that you can only merge to current.
You can't exclude a later imagecopy. Again, we don't have time for that.


2. Wonder if we can use an unload from the imcremental and the
unload from the full. I ran a test to make sure I could run an unload
from an incremental. Does anyone have experience with this? ..... Sort
the datasets and remove dups?

3. What about trying to use the full and incremental imagecopy
and put them to the test tables. What kind of translate of
obids........ would have to be done with what utility? Can anyone
shed any light on an approach like this?

4. Other ideas?

We are talking approximately 900 tablespaces.

Thanks for any input you can give.

Suzanne Nichols
Contractor at Kentucky Farm Bureau
Louisville, KY



The IDUG DB2-L Listserv is only part of your membership in IDUG.
DB2-L list archives, the FAQ, and delivery preferences are at
www.idug.org < http://www.idug.org/lsidug > under 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
< http://www.idug.org/lsconf > , and much more.
If you have not yet signed up for Basic Membership in IDUG,
available at no cost, click on Member Services
< http://www.idug.org/lsms >

The IDUG DB2-L Listserv is only part of your membership in IDUG.
DB2-L list archives, the FAQ, and delivery preferences are at
www.idug.org < http://www.idug.org/lsidug > under 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
< http://www.idug.org/lsconf > , and much more.
If you have not yet signed up for Basic Membership in IDUG,
available at no cost, click on Member Services
< http://www.idug.org/lsms >


The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L
list archives, the FAQ, and delivery preferences are at www.idug.org
< http://www.idug.org/lsidug > under 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
< http://www.idug.org/lsconf > , and much more.
If you have not yet signed up for Basic Membership in IDUG, available at
no cost, click on Member Services < http://www.idug.org/lsms >

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L
list archives, the FAQ, and delivery preferences are at
http://www.idug.org/lsidug under 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


***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************

The IDUG DB2-L Listserv is only part of your membership in IDUG. DB2-L list archives, the FAQ, and delivery preferences are at http://www.idug.org/lsidug under 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