We have an application through which users store various types of files and
attachments in a LOB in a DB2 7.2 database. Some of these files and
attachments can reach a size of 1 GB, although most are in the 10 MB range.
Logging is not enabled for the LOB columns in the database tables. We do a
full offline backup of the DB every night. So, it appears as though, if we
suffer a system problem during the day sometime, we could loose up to 24
hours of the LOB data.

We would like to recreate the tables and columns holding the LOB data so
that logging is enabled. That way, should a system failure occur, we could
recover all of the LOB data by restoring the back up and then applying the
log files with a roll forward. This is what we would like to do if at all
possible. We currently generate log files every 15 minutes, so by enabling
logging, we would suffer a maximum LOB data loss of 15 minutes.

Our primary goal, which we must accomplish due to regulatory requirements,
is to limit any data loss to one hour or less.

However, we have been told that enabling logging for the LOB tables and
columns will significantly impact the performance of the system in a very
negative way.
Is this correct?

Any other ideas about how we many obtain a max LOB data loss of 1 hour or
less?

Thanks for any and all help.

I can assure you that it is greatly appreciated!

John

"johnm" <johnm@matrixsg.com> wrote in message
news:115dlhu8bmmc288@corp.supernews.com...
> We have an application through which users store various types of files
and
> attachments in a LOB in a DB2 7.2 database. Some of these files and
> attachments can reach a size of 1 GB, although most are in the 10 MB
range.
> Logging is not enabled for the LOB columns in the database tables. We do a
> full offline backup of the DB every night. So, it appears as though, if we
> suffer a system problem during the day sometime, we could loose up to 24
> hours of the LOB data.
>
> We would like to recreate the tables and columns holding the LOB data so
> that logging is enabled. That way, should a system failure occur, we could
> recover all of the LOB data by restoring the back up and then applying the
> log files with a roll forward. This is what we would like to do if at all
> possible. We currently generate log files every 15 minutes, so by enabling
> logging, we would suffer a maximum LOB data loss of 15 minutes.
>
> Our primary goal, which we must accomplish due to regulatory requirements,
> is to limit any data loss to one hour or less.
>
> However, we have been told that enabling logging for the LOB tables and
> columns will significantly impact the performance of the system in a very
> negative way.
> Is this correct?
>
> Any other ideas about how we many obtain a max LOB data loss of 1 hour or
> less?
>
> Thanks for any and all help.
>
> I can assure you that it is greatly appreciated!
>
> John
>
Can you provide the following information?:

1. Number of LOB's inserted per hour and average size
2. Number of LOB's updated per hour and average size
3. Number of LOB's deleted per hour and average size
4. Rough estimate of the amount of non-LOB data inserted, updated, and
deleted per hour
5. Type of disk subsystem (including controller) used for log files
6. Whether the disk and controller used for logging is used for anything
else (DB2 or non-DB2)
7. Size of log buffer
8. Size and number of log files
9. Number of processors

I will gather all of the requested data and post in the next day or so.

I appreciate your time and help.

Thanks,

John


"Mark A" <nobody@nowhere.com> wrote in message
news:PLedndKbBsEylcrfRVn-tA@comcast.com...
> "johnm" <johnm@matrixsg.com> wrote in message
> news:115dlhu8bmmc288@corp.supernews.com...
> > We have an application through which users store various types of files
> and
> > attachments in a LOB in a DB2 7.2 database. Some of these files and
> > attachments can reach a size of 1 GB, although most are in the 10 MB
> range.
> > Logging is not enabled for the LOB columns in the database tables. We do
a
> > full offline backup of the DB every night. So, it appears as though, if
we
> > suffer a system problem during the day sometime, we could loose up to 24
> > hours of the LOB data.
> >
> > We would like to recreate the tables and columns holding the LOB data so
> > that logging is enabled. That way, should a system failure occur, we
could
> > recover all of the LOB data by restoring the back up and then applying
the
> > log files with a roll forward. This is what we would like to do if at
all
> > possible. We currently generate log files every 15 minutes, so by
enabling
> > logging, we would suffer a maximum LOB data loss of 15 minutes.
> >
> > Our primary goal, which we must accomplish due to regulatory
requirements,
> > is to limit any data loss to one hour or less.
> >
> > However, we have been told that enabling logging for the LOB tables and
> > columns will significantly impact the performance of the system in a
very
> > negative way.
> > Is this correct?
> >
> > Any other ideas about how we many obtain a max LOB data loss of 1 hour
or
> > less?
> >
> > Thanks for any and all help.
> >
> > I can assure you that it is greatly appreciated!
> >
> > John
> >
> Can you provide the following information?:
>
> 1. Number of LOB's inserted per hour and average size
> 2. Number of LOB's updated per hour and average size
> 3. Number of LOB's deleted per hour and average size
> 4. Rough estimate of the amount of non-LOB data inserted, updated, and
> deleted per hour
> 5. Type of disk subsystem (including controller) used for log files
> 6. Whether the disk and controller used for logging is used for anything
> else (DB2 or non-DB2)
> 7. Size of log buffer
> 8. Size and number of log files
> 9. Number of processors
>
>

I will gather all of the requested information and post it all within the
next couple of days.

Thanks for the help!

John



"Mark A" <nobody@nowhere.com> wrote in message
news:PLedndKbBsEylcrfRVn-tA@comcast.com...
> "johnm" <johnm@matrixsg.com> wrote in message
> news:115dlhu8bmmc288@corp.supernews.com...
> > We have an application through which users store various types of files
> and
> > attachments in a LOB in a DB2 7.2 database. Some of these files and
> > attachments can reach a size of 1 GB, although most are in the 10 MB
> range.
> > Logging is not enabled for the LOB columns in the database tables. We do
a
> > full offline backup of the DB every night. So, it appears as though, if
we
> > suffer a system problem during the day sometime, we could loose up to 24
> > hours of the LOB data.
> >
> > We would like to recreate the tables and columns holding the LOB data so
> > that logging is enabled. That way, should a system failure occur, we
could
> > recover all of the LOB data by restoring the back up and then applying
the
> > log files with a roll forward. This is what we would like to do if at
all
> > possible. We currently generate log files every 15 minutes, so by
enabling
> > logging, we would suffer a maximum LOB data loss of 15 minutes.
> >
> > Our primary goal, which we must accomplish due to regulatory
requirements,
> > is to limit any data loss to one hour or less.
> >
> > However, we have been told that enabling logging for the LOB tables and
> > columns will significantly impact the performance of the system in a
very
> > negative way.
> > Is this correct?
> >
> > Any other ideas about how we many obtain a max LOB data loss of 1 hour
or
> > less?
> >
> > Thanks for any and all help.
> >
> > I can assure you that it is greatly appreciated!
> >
> > John
> >
> Can you provide the following information?:
>
> 1. Number of LOB's inserted per hour and average size
> 2. Number of LOB's updated per hour and average size
> 3. Number of LOB's deleted per hour and average size
> 4. Rough estimate of the amount of non-LOB data inserted, updated, and
> deleted per hour
> 5. Type of disk subsystem (including controller) used for log files
> 6. Whether the disk and controller used for logging is used for anything
> else (DB2 or non-DB2)
> 7. Size of log buffer
> 8. Size and number of log files
> 9. Number of processors
>
>