SEO

Hi All,

Total Db2 Newbie. Cutting my way through the forest!

My db2 7.1.0 is on a small (think VERY small) Multiprise 3000 p30 and
I have no idea why, but the application programmers just adding some
test tables and data, and suddenly I'm infested with hundreds of
ARCHLOG type datasets!!!!!!!

I finally found the information on picking the safe ARCHLOGs to delete
after shutting down (on a now emergency basis, everyday!) based on the
RBAs of last store, from the reports noted in the DB2 books.

Things I can't completely figure out:

DB2 seems to slowly "catch up" with the logs, so a log moves from
important, to "can be deleted, if you need to"

What? Is it delaying something? I would prefer to just force the
write to happen now. We are devolpers, and can replace the data, if
need be. Performance, not a big deal with 1 or 2 people on.

I did figure out to get ONE Archlog using DSNZPARM so at least it's
not doing 2 copies of very trival data.

*sigh* Can I just force ARCHLOG=NO safely? I've been told to NOT
derail this project as it is time important.

What steps can I take to stop this useless ARCHLOG dataset allocs?
They are jamming up my storage packs like crazy. BUT, I need to make
sure the data is still stored (provided the lights don't go out for a
LONG time while the job is running. I can restore to a previous
backup with no protest) (See: I told you they was trivial data)

So, if you answer is I need some ARCHLOGs, I saw a post on using GDGs
for the data. OK. some is OK. How about NONE? Can I do that? and
what if the batch job lives longer than the UPS? What do I need to
restore?

Please provide some answers for this storage filling beast!

If you aswser GDGs... how many? how do I figure that out.

The new IBM manuals are mostly useless. You need to know the answer
to find the question! USENET is about the only place I actually FIND
useful stuff

TIA

Larry

"Larry Williams" <larryw@ix.netcom.com> wrote in message
news:n4cg201ufupce97iljk5lhvgqopk2no868@4ax.com...
> Hi All,
>
> Total Db2 Newbie. Cutting my way through the forest!
>
> My db2 7.1.0 is on a small (think VERY small) Multiprise 3000 p30 and
> I have no idea why, but the application programmers just adding some
> test tables and data, and suddenly I'm infested with hundreds of
> ARCHLOG type datasets!!!!!!!
>
> I finally found the information on picking the safe ARCHLOGs to delete
> after shutting down (on a now emergency basis, everyday!) based on the
> RBAs of last store, from the reports noted in the DB2 books.
>
> Things I can't completely figure out:
>
> DB2 seems to slowly "catch up" with the logs, so a log moves from
> important, to "can be deleted, if you need to"
>
> What? Is it delaying something? I would prefer to just force the
> write to happen now. We are devolpers, and can replace the data, if
> need be. Performance, not a big deal with 1 or 2 people on.
>
> I did figure out to get ONE Archlog using DSNZPARM so at least it's
> not doing 2 copies of very trival data.
>
> *sigh* Can I just force ARCHLOG=NO safely? I've been told to NOT
> derail this project as it is time important.
>
> What steps can I take to stop this useless ARCHLOG dataset allocs?
> They are jamming up my storage packs like crazy. BUT, I need to make
> sure the data is still stored (provided the lights don't go out for a
> LONG time while the job is running. I can restore to a previous
> backup with no protest) (See: I told you they was trivial data)
>
> So, if you answer is I need some ARCHLOGs, I saw a post on using GDGs
> for the data. OK. some is OK. How about NONE? Can I do that? and
> what if the batch job lives longer than the UPS? What do I need to
> restore?
>
> Please provide some answers for this storage filling beast!
>
> If you aswser GDGs... how many? how do I figure that out.
>
> The new IBM manuals are mostly useless. You need to know the answer
> to find the question! USENET is about the only place I actually FIND
> useful stuff
>
> TIA
>
> Larry
>
Are you archiving to tape or disk? Most people archive to tape unless they
have some sort of disk to tape migration software running. You can
automatically set the retention period on the tape. If you take image copies
of everything (including the catalog tables) then you probably don't need
the archive log before that time (unless you want to do a point in time
recovery to before the last image copy).

When data is logged, it is written to the log buffer (memory) and then to
the active log when committed. When the active logs fill up, DB2 switches to
a new active log dataset, and then archives the old one. This is done in a
round-robin fashion depending on the number of active log datasets set up.
So it is unlikely that the logs are slowing things down.

If you download the DB2 manuals in PDF format, they are easy to search with
the PDF search facility. Also look at the Master Index.

You can also join the DB2-L list.
www.ylassoc.com

Lots of db2/mainframe people hang out there.

For other sysprog stuff and general mainframe/utilities, ... try the
newsgroup bit.listserv.ibm.main

PM

Mark A wrote:

> "Larry Williams" <larryw@ix.netcom.com> wrote in message
> news:n4cg201ufupce97iljk5lhvgqopk2no868@4ax.com...
>> Hi All,
>>
>> Total Db2 Newbie. Cutting my way through the forest!
>>
>> My db2 7.1.0 is on a small (think VERY small) Multiprise 3000 p30 and
>> I have no idea why, but the application programmers just adding some
>> test tables and data, and suddenly I'm infested with hundreds of
>> ARCHLOG type datasets!!!!!!!
>>
>> I finally found the information on picking the safe ARCHLOGs to delete
>> after shutting down (on a now emergency basis, everyday!) based on the
>> RBAs of last store, from the reports noted in the DB2 books.
>>
>> Things I can't completely figure out:
>>
>> DB2 seems to slowly "catch up" with the logs, so a log moves from
>> important, to "can be deleted, if you need to"
>>
>> What? Is it delaying something? I would prefer to just force the
>> write to happen now. We are devolpers, and can replace the data, if
>> need be. Performance, not a big deal with 1 or 2 people on.
>>
>> I did figure out to get ONE Archlog using DSNZPARM so at least it's
>> not doing 2 copies of very trival data.
>>
>> *sigh* Can I just force ARCHLOG=NO safely? I've been told to NOT
>> derail this project as it is time important.
>>
>> What steps can I take to stop this useless ARCHLOG dataset allocs?
>> They are jamming up my storage packs like crazy. BUT, I need to make
>> sure the data is still stored (provided the lights don't go out for a
>> LONG time while the job is running. I can restore to a previous
>> backup with no protest) (See: I told you they was trivial data)
>>
>> So, if you answer is I need some ARCHLOGs, I saw a post on using GDGs
>> for the data. OK. some is OK. How about NONE? Can I do that? and
>> what if the batch job lives longer than the UPS? What do I need to
>> restore?
>>
>> Please provide some answers for this storage filling beast!
>>
>> If you aswser GDGs... how many? how do I figure that out.
>>
>> The new IBM manuals are mostly useless. You need to know the answer
>> to find the question! USENET is about the only place I actually FIND
>> useful stuff
>>
>> TIA
>>
>> Larry
>>
> Are you archiving to tape or disk? Most people archive to tape unless they
> have some sort of disk to tape migration software running. You can
> automatically set the retention period on the tape. If you take image
> copies of everything (including the catalog tables) then you probably
> don't need the archive log before that time (unless you want to do a point
> in time recovery to before the last image copy).
>
> When data is logged, it is written to the log buffer (memory) and then to
> the active log when committed. When the active logs fill up, DB2 switches
> to a new active log dataset, and then archives the old one. This is done
> in a round-robin fashion depending on the number of active log datasets
> set up. So it is unlikely that the logs are slowing things down.
>
> If you download the DB2 manuals in PDF format, they are easy to search
> with the PDF search facility. Also look at the Master Index.

I'm a DBA not a sysprog, but here are a couple of thoughts -

It also sounds like your active log datasets are too small for the volume of
transactions you are processing, hence the large number of archive logs
being produced.

As previously stated you should really seriously consider archiving to
tape / cartridge.

You also want to look at setting up housekeeping to keep the number of
archive logs manageable. Apart from anything else your bootstraps (I
think) will continue to grow in size. You'll find details of this in the
manuals.

HTH

Phil

On Mon, 9 Feb 2004 21:04:05 -0700, "Mark A" <ma@switchboard.net>
wrote:


>Are you archiving to tape or disk? Most people archive to tape unless they
>have some sort of disk to tape migration software running. You can
>automatically set the retention period on the tape. If you take image copies
>of everything (including the catalog tables) then you probably don't need
>the archive log before that time (unless you want to do a point in time
>recovery to before the last image copy).
>
>When data is logged, it is written to the log buffer (memory) and then to
>the active log when committed. When the active logs fill up, DB2 switches to
>a new active log dataset, and then archives the old one. This is done in a
>round-robin fashion depending on the number of active log datasets set up.
>So it is unlikely that the logs are slowing things down.
>
>If you download the DB2 manuals in PDF format, they are easy to search with
>the PDF search facility. Also look at the Master Index.
>


Tape not an option. I have one tape drive, no scratch pool except for
backups, and no operator.

My comments on the manuals is they are now badly written, and getting
worse. One recent example was something like:

XYZ001 TCP return code was 1

explaination: TCP returned a return code of one (duh)

actions: See "other book"

Other book:
-----------

Return code: 1 see the first book.

keyword searchs are getting much worse, cause if you put in a keyword,
most of the time it gives a terse, useless remark, and includes a link
that will, without fail, say "book must be in same shelf"

And yes, I do know how to use PDF files... now what file do I look at?

If you tell me where doing image copies is explained (with examples
would be nice) that would be great.

We've never done an image copy. Can it be done with DB2 up (if no
transactions are running?) can I then just delete all the arch log
files? (provided the image copy worked ok?)

"Larry Williams" <larryw@ix.netcom.com> wrote in message
news:a1ti20he99545k505p0d3h7e8jrg275vq8@4ax.com...
> On Mon, 9 Feb 2004 21:04:05 -0700, "Mark A" <ma@switchboard.net>
> wrote:
>
>
> >Are you archiving to tape or disk? Most people archive to tape unless
they
> >have some sort of disk to tape migration software running. You can
> >automatically set the retention period on the tape. If you take image
copies
> >of everything (including the catalog tables) then you probably don't need
> >the archive log before that time (unless you want to do a point in time
> >recovery to before the last image copy).
> >
> >When data is logged, it is written to the log buffer (memory) and then to
> >the active log when committed. When the active logs fill up, DB2 switches
to
> >a new active log dataset, and then archives the old one. This is done in
a
> >round-robin fashion depending on the number of active log datasets set
up.
> >So it is unlikely that the logs are slowing things down.
> >
> >If you download the DB2 manuals in PDF format, they are easy to search
with
> >the PDF search facility. Also look at the Master Index.
> >
>
>
> Tape not an option. I have one tape drive, no scratch pool except for
> backups, and no operator.
>
> My comments on the manuals is they are now badly written, and getting
> worse. One recent example was something like:
>
> XYZ001 TCP return code was 1
>
> explaination: TCP returned a return code of one (duh)
>
> actions: See "other book"
>
> Other book:
> -----------
>
> Return code: 1 see the first book.
>
> keyword searchs are getting much worse, cause if you put in a keyword,
> most of the time it gives a terse, useless remark, and includes a link
> that will, without fail, say "book must be in same shelf"
>
> And yes, I do know how to use PDF files... now what file do I look at?
>
> If you tell me where doing image copies is explained (with examples
> would be nice) that would be great.
>
> We've never done an image copy. Can it be done with DB2 up (if no
> transactions are running?) can I then just delete all the arch log
> files? (provided the image copy worked ok?)

I don't know what manuals you are looking at, but they don't sound like the
right ones. Here is the link to manuals. They are the best manuals in the IT
business, by a long shot.
http://www-306.ibm.com/software/data...0/v7books.html

Image copies are in the Utility Reference Manual. Image copies are extremely
important. You must image copy the catalog tablespaces on a regular basis.
There may be example JCL supplied for the catalog image copies with the
install libraries. Backup of user tablespaces is recommended also, but not
quite as critical for a development environment. But if don't do image
copies and there is a disk failure, you could loose the database. Image
copies can be run with share level reference with the system up.

I have never heard of a modern MVS system without an automated tape library
(usually cartridge). But yes, you can delete the archive log files if you
have image copies for all tablespaces and they were made after the archive
log file. I would try to keep the archive logs for a month if possible and
do image copies of everything once a week.

DB2 for OS/390 is not for people who have no education or experience on that
product. I suggest you get some professional help, even if on a part time
temporary basis.

On Tue, 10 Feb 2004 17:48:20 -0700, "Mark A" <ma@switchboard.net>
wrote:

>"Larry Williams" <larryw@ix.netcom.com> wrote in message
>news:a1ti20he99545k505p0d3h7e8jrg275vq8@4ax.com.. .
>> On Mon, 9 Feb 2004 21:04:05 -0700, "Mark A" <ma@switchboard.net>
>> wrote:
>>
>>
>> >Are you archiving to tape or disk? Most people archive to tape unless
>they
>> >have some sort of disk to tape migration software running. You can
>> >automatically set the retention period on the tape. If you take image
>copies
>> >of everything (including the catalog tables) then you probably don't need
>> >the archive log before that time (unless you want to do a point in time
>> >recovery to before the last image copy).
>> >
>> >When data is logged, it is written to the log buffer (memory) and then to
>> >the active log when committed. When the active logs fill up, DB2 switches
>to
>> >a new active log dataset, and then archives the old one. This is done in
>a
>> >round-robin fashion depending on the number of active log datasets set
>up.
>> >So it is unlikely that the logs are slowing things down.
>> >
>> >If you download the DB2 manuals in PDF format, they are easy to search
>with
>> >the PDF search facility. Also look at the Master Index.
>> >
>>
>>
>> Tape not an option. I have one tape drive, no scratch pool except for
>> backups, and no operator.
>>
>> My comments on the manuals is they are now badly written, and getting
>> worse. One recent example was something like:
>>
>> XYZ001 TCP return code was 1
>>
>> explaination: TCP returned a return code of one (duh)
>>
>> actions: See "other book"
>>
>> Other book:
>> -----------
>>
>> Return code: 1 see the first book.
>>
>> keyword searchs are getting much worse, cause if you put in a keyword,
>> most of the time it gives a terse, useless remark, and includes a link
>> that will, without fail, say "book must be in same shelf"
>>
>> And yes, I do know how to use PDF files... now what file do I look at?
>>
>> If you tell me where doing image copies is explained (with examples
>> would be nice) that would be great.
>>
>> We've never done an image copy. Can it be done with DB2 up (if no
>> transactions are running?) can I then just delete all the arch log
>> files? (provided the image copy worked ok?)
>
>I don't know what manuals you are looking at, but they don't sound like the
>right ones. Here is the link to manuals. They are the best manuals in the IT
>business, by a long shot.
>http://www-306.ibm.com/software/data...0/v7books.html
>
>Image copies are in the Utility Reference Manual. Image copies are extremely
>important. You must image copy the catalog tablespaces on a regular basis.
>There may be example JCL supplied for the catalog image copies with the
>install libraries. Backup of user tablespaces is recommended also, but not
>quite as critical for a development environment. But if don't do image
>copies and there is a disk failure, you could loose the database. Image
>copies can be run with share level reference with the system up.
>
>I have never heard of a modern MVS system without an automated tape library
>(usually cartridge). But yes, you can delete the archive log files if you
>have image copies for all tablespaces and they were made after the archive
>log file. I would try to keep the archive logs for a month if possible and
>do image copies of everything once a week.
>
>DB2 for OS/390 is not for people who have no education or experience on that
>product. I suggest you get some professional help, even if on a part time
>temporary basis.
>
>
>
Yes, friends, the box from IBM for Partnerworld has one tape drive,
and you are told not to use it for backups(?)

Second note: Yea, I keep telling them a part time DBA would be a good
idea... like yelling at a stone

> >I don't know what manuals you are looking at, but they don't sound like
the
> >right ones. Here is the link to manuals. They are the best manuals in the
IT
> >business, by a long shot.
> >http://www-306.ibm.com/software/data...0/v7books.html
> >
> >Image copies are in the Utility Reference Manual. Image copies are
extremely
> >important. You must image copy the catalog tablespaces on a regular
basis.
> >There may be example JCL supplied for the catalog image copies with the
> >install libraries. Backup of user tablespaces is recommended also, but
not
> >quite as critical for a development environment. But if don't do image
> >copies and there is a disk failure, you could loose the database. Image
> >copies can be run with share level reference with the system up.
> >
> >I have never heard of a modern MVS system without an automated tape
library
> >(usually cartridge). But yes, you can delete the archive log files if you
> >have image copies for all tablespaces and they were made after the
archive
> >log file. I would try to keep the archive logs for a month if possible
and
> >do image copies of everything once a week.
> >
> >DB2 for OS/390 is not for people who have no education or experience on
that
> >product. I suggest you get some professional help, even if on a part time
> >temporary basis.
> >
> Yes, friends, the box from IBM for Partnerworld has one tape drive,
> and you are told not to use it for backups(?)
>
> Second note: Yea, I keep telling them a part time DBA would be a good
> idea... like yelling at a stone
>
I don't consider archiving the logs to tape to be a "backup." It's a
necessity for making DB2 work.

O
>I don't consider archiving the logs to tape to be a "backup." It's a
>necessity for making DB2 work.
>
I'm not kidding, IBM says not to use the drive for backups. A tape
drive that can't do backups???

The Multiprise 3000 is a very strange box. 50+mips and no tape drive?
IBM wants $55,000 for a tape drive external to the box! (a rental
unit, no less)

I'm glad you at least gave me a lead. Thanks.

> O
> >I don't consider archiving the logs to tape to be a "backup." It's a
> >necessity for making DB2 work.
> >
> I'm not kidding, IBM says not to use the drive for backups. A tape
> drive that can't do backups???
>
> The Multiprise 3000 is a very strange box. 50+mips and no tape drive?
> IBM wants $55,000 for a tape drive external to the box! (a rental
> unit, no less)
>
> I'm glad you at least gave me a lead. Thanks.

I am not sure what the Multiprise 3000 is, but I don't know of any
mainframes with integrated tape drives. Most mainframes have robotic
cartridge systems, not necessarily made by IBM.