[DB2 for z/OS] Overhead for managing multiple indexes

Raymond Bell

[DB2 for z/OS] Overhead for managing multiple indexes
All,

A quick question looking for some rough answers. Does anyone have, or know
where I can find, a rough finger-in-the-air figure for what kind of DB2
processing overhead there is as you add indexes to a table?

For example, if you have a one-index table and insert into it your insert
time is n. If you add another index your insert time is n+x%. I'm looking
for a rough value for x as you add indexes. Does adding indexes to a table
add, say 5% for every additional index added, or does it start at 5% and
drop a percentage point at a time for each additional index, or get worse,
or be too negligible to measure, or...

I know it's more work you're asking DB2 to do, managing additional indexes;
I just wondered if anyone knew roughly how much.

Cheers,


Raymond Bell
Database Administrator
PS. When I get some time, I'll write a quick note on a V8 CM migration
issue we ran headlong into. I've peaked under the bandage and it's healing
nicely, but it hurt at the time.


This e-mail (and any attachments) may contain privileged and/or confidential information. If you are not the intended recipient please do not disclose, copy, distribute, disseminate or take any action in reliance on it. If you have received this message in error please reply and tell us and then delete it. Should you wish to communicate with us by e-mail we cannot guarantee the security of any data outside our own computer systems. For the protection of Legal & General's systems and staff, incoming emails will be automatically scanned.

Any information contained in this message may be subject to applicable terms and conditions and must not be construed as giving investment advice within or outside the United Kingdom.

The following companies are subsidiary companies of the Legal & General Group Plc which are authorised and regulated by the Financial Services Authority for advising and arranging the products shown: Legal & General Partnership Services Limited (insurance and mortgages), Legal & General Insurance Limited (insurance), Legal & General Assurance Society Limited
(life assurance, pensions and investments), Legal & General Unit Trust Managers Limited and Legal & General Portfolio Management Services Limited (investments).

They are registered in England under numbers shown.
The registered office is Temple Court, 11 Queen Victoria Street, London EC4N 4TP.

Legal & General Partnership Services Limited: 5045000 Legal & General Assurance Society Limited: 166055 Legal & General (Unit Trust Managers) Limited: 1009418 Legal & General (Portfolio Management Services) Limited: 2457525 Legal & General Insurance Limited: 423930

They are registered with the Financial Services Authority under numbers shown. You can check this at www.fsa.gov.uk/register

Legal & General Partnership Services Limited: 300792 Legal & General Assurance Society Limited: 117659 Legal & General (Unit Trust Managers) Limited: 119273 Legal & General (Portfolio Management Services) Limited: 146786 Legal & General Insurance Limited: 202050


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Arlen Stovall

Re: [DB2 for z/OS] Overhead for managing multiple indexes
(in response to Raymond Bell)
Raymond, have a look at Akira's Shibamiya presentation from the IBM TECH.

Introduction to DB2 for z/OS and
OS/390 Capacity Planning for
Basic SQL

ftp://ftp.software.ibm.com/software/db2storedprocedure/db2zos390/techdocs/capacity.pdf

Select, Insert, Update, Delete = 55 to 165us
+ 40 to 80us for each index entry insert or delete
ThanksArlen Stovall


Date: Mon, 4 Dec 2006 13:05:46 +0000From: [login to unmask email]: [DB2-L] [DB2 for z/OS] Overhead for managing multiple indexesTo: [login to unmask email]

All,
A quick question looking for some rough answers. Does anyone have, or know where I can find, a rough finger-in-the-air figure for what kind of DB2 processing overhead there is as you add indexes to a table?
For example, if you have a one-index table and insert into it your insert time is n. If you add another index your insert time is n+x%. I'm looking for a rough value for x as you add indexes. Does adding indexes to a table add, say 5% for every additional index added, or does it start at 5% and drop a percentage point at a time for each additional index, or get worse, or be too negligible to measure, or...
I know it's more work you're asking DB2 to do, managing additional indexes; I just wondered if anyone knew roughly how much.
Cheers,
Raymond Bell Database Administrator PS. When I get some time, I'll write a quick note on a V8 CM migration issue we ran headlong into. I've peaked under the bandage and it's healing nicely, but it hurt at the time.This e-mail (and any attachments) may contain privileged and/or confidential information. If you are not the intended recipient please do not disclose, copy, distribute, disseminate or take any action in reliance on it. If you have received this message in error please reply and tell us and then delete it. Should you wish to communicate with us by e-mail we cannot guarantee the security of any data outside our own computer systems. For the protection of Legal & General's systems and staff, incoming emails will be automatically scanned.Any information contained in this message may be subject to applicable terms and conditions and must not be construed as giving investment advice within or outside the United Kingdom.The following companies are subsidiary companies of the Legal & General Group Plc which are authorised and regulated by the Financial Services Authority for advising and arranging the products shown: Legal & General Partnership Services Limited (insurance and mortgages), Legal & General Insurance Limited (insurance), Legal & General Assurance Society Limited (life assurance, pensions and investments), Legal & General Unit Trust Managers Limited and Legal & General Portfolio Management Services Limited (investments).They are registered in England under numbers shown.The registered office is Temple Court, 11 Queen Victoria Street, London EC4N 4TP.Legal & General Partnership Services Limited: 5045000 Legal & General Assurance Society Limited: 166055 Legal & General (Unit Trust Managers) Limited: 1009418 Legal & General (Portfolio Management Services) Limited: 2457525 Legal & General Insurance Limited: 423930They are registered with the Financial Services Authority under numbers shown. You can check this at www.fsa.gov.uk/registerLegal & General Partnership Services Limited: 300792 Legal & General Assurance Society Limited: 117659 Legal & General (Unit Trust Managers) Limited: 119273 Legal & General (Portfolio Management Services) Limited: 146786 Legal & General Insurance Limited: 202050--------------------------------------------------------------------------------- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm
_________________________________________________________________
Check the weather nationwide with MSN Search: Try it now!
http://search.msn.com/results.aspx?q=weather&FORM=WLMTAG
---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

David Churn

Re: [DB2 for z/OS] Overhead for managing multiple indexes
(in response to Arlen Stovall)
Raymond,

We have not done a benchmark recently but we found that adding indexes is a
"straight-line" cost. Each one adds about the same amount of overhead.

Which version of DB2 are you using?

The last figures that I saw were from the mainframe.

Dave Churn
DST Systems, Inc.
Vice-President, Heart of America DB2 Users Group


On 12/4/06, Bell, Raymond <[login to unmask email]> wrote:
>
> All,
>
> A quick question looking for some rough answers. Does anyone have, or
> know where I can find, a rough finger-in-the-air figure for what kind of DB2
> processing overhead there is as you add indexes to a table?
>
> For example, if you have a one-index table and insert into it your insert
> time is n. If you add another index your insert time is n+x%. I'm looking
> for a rough value for x as you add indexes. Does adding indexes to a table
> add, say 5% for every additional index added, or does it start at 5% and
> drop a percentage point at a time for each additional index, or get worse,
> or be too negligible to measure, or...
>
> I know it's more work you're asking DB2 to do, managing additional
> indexes; I just wondered if anyone knew roughly how much.
>
> Cheers,
>
> Raymond Bell
> Database Administrator
> PS. When I get some time, I'll write a quick note on a V8 CM migration
> issue we ran headlong into. I've peaked under the bandage and it's healing
> nicely, but it hurt at the time.
>
>
> This e-mail (and any attachments) may contain privileged and/or
> confidential information. If you are not the intended recipient please do
> not disclose, copy, distribute, disseminate or take any action in reliance
> on it. If you have received this message in error please reply and tell us
> and then delete it. Should you wish to communicate with us by e-mail we
> cannot guarantee the security of any data outside our own computer systems.
> For the protection of Legal & General's systems and staff, incoming emails
> will be automatically scanned.
>
> Any information contained in this message may be subject to applicable
> terms and conditions and must not be construed as giving investment advice
> within or outside the United Kingdom.
>
> The following companies are subsidiary companies of the Legal & General
> Group Plc which are authorised and regulated by the Financial Services
> Authority for advising and arranging the products shown: Legal & General
> Partnership Services Limited (insurance and mortgages), Legal & General
> Insurance Limited (insurance), Legal & General Assurance Society Limited
> (life assurance, pensions and investments), Legal & General Unit Trust
> Managers Limited and Legal & General Portfolio Management Services Limited
> (investments).
>
> They are registered in England under numbers shown.
> The registered office is Temple Court, 11 Queen Victoria Street, London
> EC4N 4TP.
>
> Legal & General Partnership Services Limited: 5045000 Legal & General
> Assurance Society Limited: 166055 Legal & General (Unit Trust Managers)
> Limited: 1009418 Legal & General (Portfolio Management Services) Limited:
> 2457525 Legal & General Insurance Limited: 423930
>
> They are registered with the Financial Services Authority under numbers
> shown. You can check this at www.fsa.gov.uk/register
>
> Legal & General Partnership Services Limited: 300792 Legal & General
> Assurance Society Limited: 117659 Legal & General (Unit Trust Managers)
> Limited: 119273 Legal & General (Portfolio Management Services) Limited:
> 146786 Legal & General Insurance Limited: 202050
> ---------------------------------------------------------------------------------
> Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
> page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
> select "Join or Leave the list". The IDUG DB2-L FAQ is at
> http://www.idugdb2-l.org. The IDUG List Admins can be reached at
> [login to unmask email] Find out the latest on IDUG conferences
> at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Raymond Bell

Re: [DB2 for z/OS] Overhead for managing multiple indexes
(in response to David Churn)
You know, I nearly said, but hoped it would be deduced from the [DB2 for
z/OS] bit and my warning about our V8 CM issue. But anyway we're DB2 for
z/OS V8, Compat. Mode. Is the 'straight line' overhead you and/or your
members found 2%? Or 4%? S'OK if you're not sure; just wondered.

And Arlen, thanks for the link to Akira's presentation. I'll have a
butchers shortly.


Raymond

_____

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of Dave Churn
Sent: 04 December 2006 13:49
To: [login to unmask email]
Subject: Re: [DB2-L] [DB2 for z/OS] Overhead for managing multiple indexes


Raymond,

We have not done a benchmark recently but we found that adding indexes is a
"straight-line" cost. Each one adds about the same amount of overhead.

Which version of DB2 are you using?

The last figures that I saw were from the mainframe.

Dave Churn
DST Systems, Inc.
Vice-President, Heart of America DB2 Users Group


On 12/4/06, Bell, Raymond <[login to unmask email]
<mailto:[login to unmask email]> > wrote:

All,

A quick question looking for some rough answers. Does anyone have, or know
where I can find, a rough finger-in-the-air figure for what kind of DB2
processing overhead there is as you add indexes to a table?

For example, if you have a one-index table and insert into it your insert
time is n. If you add another index your insert time is n+x%. I'm looking
for a rough value for x as you add indexes. Does adding indexes to a table
add, say 5% for every additional index added, or does it start at 5% and
drop a percentage point at a time for each additional index, or get worse,
or be too negligible to measure, or...

I know it's more work you're asking DB2 to do, managing additional indexes;
I just wondered if anyone knew roughly how much.

Cheers,


Raymond Bell
Database Administrator
PS. When I get some time, I'll write a quick note on a V8 CM migration
issue we ran headlong into. I've peaked under the bandage and it's healing
nicely, but it hurt at the time.



This e-mail (and any attachments) may contain privileged and/or confidential information. If you are not the intended recipient please do not disclose, copy, distribute, disseminate or take any action in reliance on it. If you have received this message in error please reply and tell us and then delete it. Should you wish to communicate with us by e-mail we cannot guarantee the security of any data outside our own computer systems. For the protection of Legal & General's systems and staff, incoming emails will be automatically scanned.

Any information contained in this message may be subject to applicable terms and conditions and must not be construed as giving investment advice within or outside the United Kingdom.

The following companies are subsidiary companies of the Legal & General Group Plc which are authorised and regulated by the Financial Services Authority for advising and arranging the products shown: Legal & General Partnership Services Limited (insurance and mortgages), Legal & General Insurance Limited (insurance), Legal & General Assurance Society Limited
(life assurance, pensions and investments), Legal & General Unit Trust Managers Limited and Legal & General Portfolio Management Services Limited (investments).

They are registered in England under numbers shown.
The registered office is Temple Court, 11 Queen Victoria Street, London EC4N 4TP.

Legal & General Partnership Services Limited: 5045000 Legal & General Assurance Society Limited: 166055 Legal & General (Unit Trust Managers) Limited: 1009418 Legal & General (Portfolio Management Services) Limited: 2457525 Legal & General Insurance Limited: 423930

They are registered with the Financial Services Authority under numbers shown. You can check this at www.fsa.gov.uk/register

Legal & General Partnership Services Limited: 300792 Legal & General Assurance Society Limited: 117659 Legal & General (Unit Trust Managers) Limited: 119273 Legal & General (Portfolio Management Services) Limited: 146786 Legal & General Insurance Limited: 202050


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Mike Bell

Re: [DB2 for z/OS] Overhead for managing multiple indexes
(in response to Raymond Bell)
The expert on this is Akira Shibamiya. He hasn't done his detailed
estimation of DB2 CPU and IO costs since he did one on DB2 V7 so the last
one was about 4-5 years ago. I know I have the presentation saved somewhere
but can't find it right now. If you want my rule of thumb (something better
than a complete guess but not much), I assign a base cost to INSERT of a
number between 3 and 5 depending on how complex the table is. Then I add
1/2 for each RI that has to be checked and 1 for each index to be updated.
Rational is simple - I am counting the cpu cost as being relative to the
number of pages referenced.
Normal index lookup uses 3-5 get pages. Normal index update doesn't use many
more get pages but does have to take a page latch and shuffle the data in
the page. This does assume all RI can be checked directly with a matching
index.

example would be -
table with 3 indexes and 2 RI
current cost is 4 for base, 2 for 2nd and 3rd index and 1 for 2 RI = 7
one more index would increase the cost to 8 so 14% increase.

Mike
HLS Technologies



-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of Bell, Raymond
Sent: Monday, December 04, 2006 7:06 AM
To: [login to unmask email]
Subject: [DB2-L] [DB2 for z/OS] Overhead for managing multiple indexes

All,

A quick question looking for some rough answers. Does anyone have, or know
where I can find, a rough finger-in-the-air figure for what kind of DB2
processing overhead there is as you add indexes to a table?

For example, if you have a one-index table and insert into it your insert
time is n. If you add another index your insert time is n+x%. I'm looking
for a rough value for x as you add indexes. Does adding indexes to a table
add, say 5% for every additional index added, or does it start at 5% and
drop a percentage point at a time for each additional index, or get worse,
or be too negligible to measure, or...

I know it's more work you're asking DB2 to do, managing additional indexes;
I just wondered if anyone knew roughly how much.

Cheers,


Raymond Bell
Database Administrator
PS. When I get some time, I'll write a quick note on a V8 CM migration
issue we ran headlong into. I've peaked under the bandage and it's healing
nicely, but it hurt at the time.



This e-mail (and any attachments) may contain privileged and/or confidential
information. If you are not the intended recipient please do not disclose,
copy, distribute, disseminate or take any action in reliance on it. If you
have received this message in error please reply and tell us and then delete
it. Should you wish to communicate with us by e-mail we cannot guarantee the
security of any data outside our own computer systems. For the protection of
Legal & General's systems and staff, incoming emails will be automatically
scanned.

Any information contained in this message may be subject to applicable terms
and conditions and must not be construed as giving investment advice within
or outside the United Kingdom.

The following companies are subsidiary companies of the Legal & General
Group Plc which are authorised and regulated by the Financial Services
Authority for advising and arranging the products shown: Legal & General
Partnership Services Limited (insurance and mortgages), Legal & General
Insurance Limited (insurance), Legal & General Assurance Society Limited
(life assurance, pensions and investments), Legal & General Unit Trust
Managers Limited and Legal & General Portfolio Management Services Limited
(investments).

They are registered in England under numbers shown.
The registered office is Temple Court, 11 Queen Victoria Street, London EC4N
4TP.

Legal & General Partnership Services Limited: 5045000 Legal & General
Assurance Society Limited: 166055 Legal & General (Unit Trust Managers)
Limited: 1009418 Legal & General (Portfolio Management Services) Limited:
2457525 Legal & General Insurance Limited: 423930

They are registered with the Financial Services Authority under numbers
shown. You can check this at www.fsa.gov.uk/register

Legal & General Partnership Services Limited: 300792 Legal & General
Assurance Society Limited: 117659 Legal & General (Unit Trust Managers)
Limited: 119273 Legal & General (Portfolio Management Services) Limited:
146786 Legal & General Insurance Limited: 202050

----------------------------------------------------------------------------
----- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page
select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Michael Ebert

Re: [DB2 for z/OS] Overhead for managing multiple indexes
(in response to Mike Bell)
I don't think there is any such figure. In our SAP environment, the
developers created large tables with multiple indexes, some of which were
considerably bigger than the table itself (multi-column tables where every
column except the last one - a counter - was in the primary key - and you
can't compress indexes). I don't think that could be maintained with 2% or
even 50% overhead. So you'd have to take row/keylength into account.

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




"Bell, Raymond" <[login to unmask email]>
To
[login to unmask email]
cc

bcc

Subject
Re: [DB2-L] [DB2 for z/OS] Overhead for managing multiple indexes





"Bell, Raymond" <[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]>
04-12-06 15:01


You know, I nearly said, but hoped it would be deduced from the [DB2 for
z/OS] bit and my warning about our V8 CM issue. But anyway we're DB2 for
z/OS V8, Compat. Mode. Is the 'straight line' overhead you and/or your
members found 2%? Or 4%? S'OK if you're not sure; just wondered.

And Arlen, thanks for the link to Akira's presentation. I'll have a
butchers shortly.


Raymond

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Max Scarpa

Re: [DB2 for z/OS] Overhead for managing multiple indexes
(in response to Michael Ebert)
Raymond

In my ACME 'All-purpose DVD' I've found:

'Insert Performance Considerations in DB2 for OS/390 - Part 1 & 2'
by A. Shibamiya

'Hardware conscious index design' by T. Lahdenmaki

I'm sure I've other papers but I can't find them now

They have some calculations.

HTH

Max Scarpa

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Raymond Bell

Re: [DB2 for z/OS] Overhead for managing multiple indexes
(in response to Max Scarpa)
Arlen, Mike, Max, Dr. E, etc,

Thanks for all the pointers. So, somewhere between bugger-all and 20% for
this particular table. Fortunately the table concerned already has 2
indexes, 2 RI parents and 5 RI children, so the relative cost of adding
another index is small. Plus it gets a new app' out of the poo of having to
scan 12M rows to get the one or two they're after if this column is indexed.

Cheers, all. What a great resource DB2-L is. I just hope it's accessible
from Bangalore. D'oh! Promised myself I wouldn't comment on that.


Raymond Bell
Database Administrator
PS. Spot the deliberately misspelt word...

_____

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of arlen stovall
Sent: 04 December 2006 13:47
To: [login to unmask email]
Subject: Re: [DB2-L] [DB2 for z/OS] Overhead for managing multiple indexes



Raymond, have a look at Akira's Shibamiya presentation from the IBM TECH.



Introduction to DB2 for z/OS and

OS/390 Capacity Planning for

Basic SQL



ftp://ftp.software.ibm.com/software/db2storedprocedure/db2zos390/techdocs/ca
pacity.pdf
<ftp://ftp.software.ibm.com/software/db2storedprocedure/db2zos390/techdocs/c
apacity.pdf>



Select, Insert, Update, Delete = 55 to 165us

+ 40 to 80us for each index entry insert or delete



Thanks
Arlen Stovall





_____

Date: Mon, 4 Dec 2006 13:05:46 +0000
From: [login to unmask email]
Subject: [DB2-L] [DB2 for z/OS] Overhead for managing multiple indexes
To: [login to unmask email]


All,
A quick question looking for some rough answers. Does anyone have, or know
where I can find, a rough finger-in-the-air figure for what kind of DB2
processing overhead there is as you add indexes to a table?
For example, if you have a one-index table and insert into it your insert
time is n. If you add another index your insert time is n+x%. I'm looking
for a rough value for x as you add indexes. Does adding indexes to a table
add, say 5% for every additional index added, or does it start at 5% and
drop a percentage point at a time for each additional index, or get worse,
or be too negligible to measure, or...
I know it's more work you're asking DB2 to do, managing additional indexes;
I just wondered if anyone knew roughly how much.
Cheers,

Raymond Bell
Database Administrator
PS. When I get some time, I'll write a quick note on a V8 CM migration
issue we ran headlong into. I've peaked under the bandage and it's healing
nicely, but it hurt at the time.




This e-mail (and any attachments) may contain privileged and/or confidential information. If you are not the intended recipient please do not disclose, copy, distribute, disseminate or take any action in reliance on it. If you have received this message in error please reply and tell us and then delete it. Should you wish to communicate with us by e-mail we cannot guarantee the security of any data outside our own computer systems. For the protection of Legal & General's systems and staff, incoming emails will be automatically scanned.

Any information contained in this message may be subject to applicable terms and conditions and must not be construed as giving investment advice within or outside the United Kingdom.

The following companies are subsidiary companies of the Legal & General Group Plc which are authorised and regulated by the Financial Services Authority for advising and arranging the products shown: Legal & General Partnership Services Limited (insurance and mortgages), Legal & General Insurance Limited (insurance), Legal & General Assurance Society Limited
(life assurance, pensions and investments), Legal & General Unit Trust Managers Limited and Legal & General Portfolio Management Services Limited (investments).

They are registered in England under numbers shown.
The registered office is Temple Court, 11 Queen Victoria Street, London EC4N 4TP.

Legal & General Partnership Services Limited: 5045000 Legal & General Assurance Society Limited: 166055 Legal & General (Unit Trust Managers) Limited: 1009418 Legal & General (Portfolio Management Services) Limited: 2457525 Legal & General Insurance Limited: 423930

They are registered with the Financial Services Authority under numbers shown. You can check this at www.fsa.gov.uk/register

Legal & General Partnership Services Limited: 300792 Legal & General Assurance Society Limited: 117659 Legal & General (Unit Trust Managers) Limited: 119273 Legal & General (Portfolio Management Services) Limited: 146786 Legal & General Insurance Limited: 202050


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm