DB2 Logging (& all the rest)

Max Scarpa

DB2 Logging (& all the rest)
Hi Roger

Again, what you wrote is absolutely correct.
But in production, sometimes VERY big production environments and in legacy
application (and sometimes integrated with new application in JAVA etc),
it's not simple to improve new features to speed up logging:

- Very often big inserts are not a 'normal' daily operation, you've to do
it when you have, for instance, new customers, your company is amalgamated
with another company and you have to load new informations, or for many
days a 'normal' insert procedure abended so you've to inserts a lot of
records in 'one shot', usually using a batch job. DASD space is not
'tuned', in general, for such 'abnormal' operations.I saw active logs
filled with data in few seconds when some big inserts occur via batch job
(and when logs are full, DB2 stops working........).
Altering a column to LOBs is not, in general, a solution.

-Logging, 'per se', may be not an issue, but I've to consider the
possibility of ROLLBACKs for heavy insert jobs and things become hard in
this case as there are logs/archives to consider. One of the most important
problem, at least in my experience, is a lllooooonnnnggg ROLLBACK.

- LOAD LOG NO is not always possible, as if something goes wrong in LOAD
phase (mainly for the lack of DASD space) you've to recover the
tablespace(s), which (almost) double the unavailability period, and in any
case the table is not always available for online in a 24x7 shop.
Sometimes this is true even for very small, highly accessed tables where,
even if LOAD duration is few minutes you can cause a lot of abends, due to
high tx/sec value. With a looong series of phone calls made by (angry)
customers. And during these days it's not a good idea to make customers
angry.

- Not all DB2 customers have SHARKs and FICON (there are a lot of ESCON
shops and you've to consider it) and we all have to work with the
instruments we have, in a real world.
For instance one of the most difficult thing in big companies is to talk
with DASD people. In general DASD people do not want to modify their system
parameters and striping, if not properly set, can cause some problems.
Anyway 13 Mb/sec is a lab value (a perfect world with no garbage,no angry
customers,pointed-hairy bosses or blondes - btw I like blondes) and a row
of 100 byte, as I could see from thislist, is a too short row to simulate
real environment, IBM should at least double this value (my opinion).

- One of the most cited (nice) features of ORACLE is that 'ORACLE can avoid
logging' and this higly considered by application people. And every time I
say that DB2 cannot do it, I win a free-for-all pack.

Waiting for new lashes & best regards

Max Scarpa


'Nuclear reactions,rabbits and married couples do things that
can be masured in attoseconds'
Richard P. Feynman



Dak Mac

Re: DB2 Logging (& all the rest)
(in response to Max Scarpa)

Hi Roger
I noticed a term 'DASD space' : Can I know the meaning of this
what does DASD : stand for ?
Thanks a mil.
Dak'
Max Scarpa <[login to unmask email]> wrote:Hi Roger

Again, what you wrote is absolutely correct.
But in production, sometimes VERY big production environments and in legacy
application (and sometimes integrated with new application in JAVA etc),
it's not simple to improve new features to speed up logging:

- Very often big inserts are not a 'normal' daily operation, you've to do
it when you have, for instance, new customers, your company is amalgamated
with another company and you have to load new informations, or for many
days a 'normal' insert procedure abended so you've to inserts a lot of
records in 'one shot', usually using a batch job. DASD space is not
'tuned', in general, for such 'abnormal' operations.I saw active logs
filled with data in few seconds when some big inserts occur via batch job
(and when logs are full, DB2 stops working........).
Altering a column to LOBs is not, in general, a solution.

-Logging, 'per se', may be not an issue, but I've to consider the
possibility of ROLLBACKs for heavy insert jobs and things become hard in
this case as there are logs/archives to consider. One of the most important
problem, at least in my experience, is a lllooooonnnnggg ROLLBACK.

- LOAD LOG NO is not always possible, as if something goes wrong in LOAD
phase (mainly for the lack of DASD space) you've to recover the
tablespace(s), which (almost) double the unavailability period, and in any
case the table is not always available for online in a 24x7 shop.
Sometimes this is true even for very small, highly accessed tables where,
even if LOAD duration is few minutes you can cause a lot of abends, due to
high tx/sec value. With a looong series of phone calls made by (angry)
customers. And during these days it's not a good idea to make customers
angry.

- Not all DB2 customers have SHARKs and FICON (there are a lot of ESCON
shops and you've to consider it) and we all have to work with the
instruments we have, in a real world.
For instance one of the most difficult thing in big companies is to talk
with DASD people. In general DASD people do not want to modify their system
parameters and striping, if not properly set, can cause some problems.
Anyway 13 Mb/sec is a lab value (a perfect world with no garbage,no angry
customers,pointed-hairy bosses or blondes - btw I like blondes) and a row
of 100 byte, as I could see from thislist, is a too short row to simulate
real environment, IBM should at least double this value (my opinion).

- One of the most cited (nice) features of ORACLE is that 'ORACLE can avoid
logging' and this higly considered by application people. And every time I
say that DB2 cannot do it, I win a free-for-all pack.

Waiting for new lashes & best regards

Max Scarpa


'Nuclear reactions,rabbits and married couples do things that
can be masured in attoseconds'
Richard P. Feynman





---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

David S Waugh

Re: DB2 Logging (& all the rest)
(in response to Cathy Taddei)
DASD: Direct Access Storage Device

---------- Dak Mac <[login to unmask email]> writes:


Hi Roger
I noticed a term 'DASD space' : Can I know the meaning of this
what does DASD : stand for ?
Thanks a mil.
Dak'
Max Scarpa <[login to unmask email]> wrote:Hi Roger

Again, what you wrote is absolutely correct.
But in production, sometimes VERY big production environments and in legacy
application (and sometimes integrated with new application in JAVA etc),
it's not simple to improve new features to speed up logging:

- Very often big inserts are not a 'normal' daily operation, you've to do
it when you have, for instance, new customers, your company is amalgamated
with another company and you have to load new informations, or for many
days a 'normal' insert procedure abended so you've to inserts a lot of
records in 'one shot', usually using a batch job. DASD space is not
'tuned', in general, for such 'abnormal' operations.I saw active logs
filled with data in few seconds when some big inserts occur via batch job
(and when logs are full, DB2 stops working........).
Altering a column to LOBs is not, in general, a solution.

-Logging, 'per se', may be not an issue, but I've to consider the
possibility of ROLLBACKs for heavy insert jobs and things become hard in
this case as there are logs/archives to consider. One of the most important
problem, at least in my experience, is a lllooooonnnnggg ROLLBACK.

- LOAD LOG NO is not always possible, as if something goes wrong in LOAD
phase (mainly for the lack of DASD space) you've to recover the
tablespace(s), which (almost) double the unavailability period, and in any
case the table is not always available for online in a 24x7 shop.
Sometimes this is true even for very small, highly accessed tables where,
even if LOAD duration is few minutes you can cause a lot of abends, due to
high tx/sec value. With a looong series of phone calls made by (angry)
customers. And during these days it's not a good idea to make customers
angry.

- Not all DB2 customers have SHARKs and FICON (there are a lot of ESCON
shops and you've to consider it) and we all have to work with the
instruments we have, in a real world.
For instance one of the most difficult thing in big companies is to talk
with DASD people. In general DASD people do not want to modify their system
parameters and striping, if not properly set, can cause some problems.
Anyway 13 Mb/sec is a lab value (a perfect world with no garbage,no angry
customers,pointed-hairy bosses or blondes - btw I like blondes) and a row
of 100 byte, as I could see from thislist, is a too short row to simulate
real environment, IBM should at least double this value (my opinion).

- One of the most cited (nice) features of ORACLE is that 'ORACLE can avoid
logging' and this higly considered by application people. And every time I
say that DB2 cannot do it, I win a free-for-all pack.

Waiting for new lashes & best regards

Max Scarpa


'Nuclear reactions,rabbits and married couples do things that
can be masured in attoseconds'
Richard P. Feynman





---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now



Cathy Taddei

Re: DB2 Logging (& all the rest)
(in response to Dak Mac)
Dak, DASD stands for Direct Access Storage Device, and refers to computer
disk (hard drive) storage. In the mainframe world, a typical disk will
emulate an IBM model 3390 disk drive, which has the capacity to store
(depending on who you ask!) between 2.3 and 2.6 gigabytes (depending on
block size and other factors). A typical mainframe installation will have
hundreds, if not thousands, of such devices.

Hope this helps,
Cathy Taddei

-----Original Message-----
From: Dak Mac [mailto:[login to unmask email]
Sent: Monday, December 23, 2002 3:38 PM
To: [login to unmask email]
Subject: Re: DB2 Logging (& all the rest)



Hi Roger


I noticed a term 'DASD space' : Can I know the meaning of this


what does DASD : stand for ?


Thanks a mil.


Dak'


------------------------------------------------------------------------------

This email is confidential and may be legally privileged.

It is intended solely for the addressee. Access to this email by anyone else, unless expressly approved by the sender or an authorized addressee, is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution or any action omitted or taken in reliance on it, is prohibited and may be unlawful. If you believe that you have received this email in error, please contact the sender, delete this e-mail and destroy all copies.


=====