partitioning in V8

Dave Magnusen

partitioning in V8
As a relative newbie to DB2, and V8, please bear with me.

We have an application which would like to create many partitions.
Many thousand...
Has anyone partitioned to this level? Any horror stories, show-stoppers, or
little gotcha's you can share are most appreciated.

Thanks,

dave

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Phil Grainger

Re: partitioning in V8
(in response to Chris Blaicher)
The only gotchas that I know of, for now, are concerned with managing that number of physical objects

Consider how long it takes DB2 to create a table space (say 0.2 secs on a good day?) - now multiply that by a couple of thousand (2,000 * 0.2 secs = 6.66 minutes, or so). Now the same for each partitioned index... The times start to add up

Now, if you are only ever going to create it once, that's OK

But PLEASE, if you ever reorg it, then do so with REUSE, otherwise you have all those thousands of deletes as well as defines!

Also, what if it gets migrated? Someone will have to wait for ALL the partitions to be recalled before any data can be accessed. And how long does it take to open 2,000 table spaces and 2,000 index partitions anyway?

Like you, I'd be interested in any real world stories of kilo-partitioned table spaces

Phil Grainger
CA
Senior Principal Product Manager
Phone: +44 (0)1753 577 733
Mobile: +44 (0)7970 125 752
eMail: [login to unmask email]
Ditton Park
Riding Court Road
Datchet
Slough
SL3 9LL
CA plc a company registered in England and Wales under company registration number 1282495 with its registered office at the address set out above. VAT number 697904179.


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Dave Magnusen
Sent: 29 January 2009 15:01
To: [login to unmask email]
Subject: [DB2-L] partitioning in V8

As a relative newbie to DB2, and V8, please bear with me.

We have an application which would like to create many partitions.
Many thousand...
Has anyone partitioned to this level? Any horror stories, show-stoppers, or
little gotcha's you can share are most appreciated.

Thanks,

dave

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Chris Blaicher

Re: partitioning in V8
(in response to Dave Magnusen)
When developing our utility suite of software we test with 4096
partitions. Not as a regular thing, mind you, but we do test with them,
so I can say it does work.

It takes a little while to define a 4096 part object, and it takes a
while to do a lot of things with a full set of partitions.

We do it with 4096 parts because we have to. There are good reasons to
have multiple partitions and bad reasons.

Good reasons include performance (contention), size (too much data for
the number of parts you have) and roll-off (each part is a day or month
or year).

My suggestion is to see what is driving your need for partitions and
limit it to a reasonable number based on the above. Going to a large
number just because you can is not a good reason.

As for the "gotcha's", my experience is limited and what I have seen and
revolves around the number of data sets involved.

________________________________

Christopher Y. Blaicher
Senior Software Developer
Austin Development Lab

phone: 512.340.6154
moble: 512.627.3803
fax: 512.340.6647

10431 Morado Circle
Austin, TX 78759
BMC Software
-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Dave Magnusen
Sent: Thursday, January 29, 2009 9:01 AM
To: [login to unmask email]
Subject: [DB2-L] partitioning in V8

As a relative newbie to DB2, and V8, please bear with me.

We have an application which would like to create many partitions.
Many thousand...
Has anyone partitioned to this level? Any horror stories,
show-stoppers, or
little gotcha's you can share are most appreciated.

Thanks,

dave

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events
*
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password.
You should have gotten an e-mail with the temporary password assigned to
your account. Please log in and update your member profile. If you are
not already an IDUG.org member, please register at
http://www.idug.org/component/juser/register.html

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Chris Blaicher

Re: partitioning in V8
(in response to Phil Grainger)
OK the developers have put their 2 cents worth in.

I am curious about the largest number of partitions real people use.

I just worked with a customer with a 275 partition object. Does anyone
have over 500 partitions in production? We had one that had 512, but
due to operational problems went back to 256.

________________________________

Christopher Y. Blaicher
Senior Software Developer
Austin Development Lab

phone: 512.340.6154
moble: 512.627.3803
fax: 512.340.6647

10431 Morado Circle
Austin, TX 78759
BMC Software

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Blaicher, Chris
Sent: Thursday, January 29, 2009 9:44 AM
To: [login to unmask email]
Subject: Re: [DB2-L] partitioning in V8

When developing our utility suite of software we test with 4096
partitions. Not as a regular thing, mind you, but we do test with them,
so I can say it does work.

It takes a little while to define a 4096 part object, and it takes a
while to do a lot of things with a full set of partitions.

We do it with 4096 parts because we have to. There are good reasons to
have multiple partitions and bad reasons.

Good reasons include performance (contention), size (too much data for
the number of parts you have) and roll-off (each part is a day or month
or year).

My suggestion is to see what is driving your need for partitions and
limit it to a reasonable number based on the above. Going to a large
number just because you can is not a good reason.

As for the "gotcha's", my experience is limited and what I have seen and
revolves around the number of data sets involved.

________________________________

Christopher Y. Blaicher
Senior Software Developer
Austin Development Lab

phone: 512.340.6154
moble: 512.627.3803
fax: 512.340.6647

10431 Morado Circle
Austin, TX 78759
BMC Software
-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Dave Magnusen
Sent: Thursday, January 29, 2009 9:01 AM
To: [login to unmask email]
Subject: [DB2-L] partitioning in V8

As a relative newbie to DB2, and V8, please bear with me.

We have an application which would like to create many partitions.
Many thousand...
Has anyone partitioned to this level? Any horror stories,
show-stoppers, or
little gotcha's you can share are most appreciated.

Thanks,

dave

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events
*
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password.
You should have gotten an e-mail with the temporary password assigned to
your account. Please log in and update your member profile. If you are
not already an IDUG.org member, please register at
http://www.idug.org/component/juser/register.html

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events
*
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password.
You should have gotten an e-mail with the temporary password assigned to
your account. Please log in and update your member profile. If you are
not already an IDUG.org member, please register at
http://www.idug.org/component/juser/register.html

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Patrick Bossman

Re: partitioning in V8
(in response to Chris Blaicher)
For SQL performance, the performance of data partitioned seconday index
(DPSI) access where limited partition scan isn't available gets worse as the
number of partitions increases.

Partition by C1, 4000 parts.
Create DPSI on (C2)
Assume C2 is very selective (say COLCARDF 100 million)
Assume T1 has 200 million rows.

SELECT cols
FROM T1
WHERE C2 = ?
FOR FETCH ONLY;

DB2 has to perform 4000 probes to find around 2 rows. The more partitions,
the more probes.

A non-partitioned index on C2 would perform one probe.

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Jack Campbell

Re: partitioning in V8
(in response to Patrick Bossman)
In addition to Phil's comment on dataset opens......

how would so many partitions affect your MAX OPEN DATASETS for the DB2
sub-system. If there are a large number of partitions open concurrently this
could cause the close/re-open of datasets relating to other tablespaces.

If the table has a high hit-rate for multiple partitions concurrently, what
adverse affect would this have on other tables in the same bufferpool? You
may need to isolate the table into its own bufferpool

What would the effect be on utilities, such as COPY and REORG (assuming the
use of DPSI's), if a large number of parts need to be proicessed - VSAM
allocate overhead? Particular for 3rd party products which run at the VSAM
dataset level?




Regards

Jack

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Phil Grainger

Re: partitioning in V8
(in response to Jack Campbell)
Oh, and one other thing

Heaven help you if you have LOB or XML columns

If you DO, you will need one additional (table space + table + index) for EACH LOB/XML column for EACH partition

and you are still limited to 64K objects per database. Remember, the numbers add up FAST

a 4,096 partitioned object with one partitioned index and one LOB column will account for:

4,096 table space page sets
1 table
4,096 index page sets
4,096 LOB table spaces
4,096 aux tables
4,096 aux index page sets

= 20,481 objects!!!

Phil Grainger
CA

________________________________

From: DB2 Data Base Discussion List on behalf of Jack Campbell
Sent: Thu 29/01/2009 17:47
To: [login to unmask email]
Subject: Re: [DB2-L] partitioning in V8



In addition to Phil's comment on dataset opens......

how would so many partitions affect your MAX OPEN DATASETS for the DB2
sub-system. If there are a large number of partitions open concurrently this
could cause the close/re-open of datasets relating to other tablespaces.

If the table has a high hit-rate for multiple partitions concurrently, what
adverse affect would this have on other tables in the same bufferpool? You
may need to isolate the table into its own bufferpool

What would the effect be on utilities, such as COPY and REORG (assuming the
use of DPSI's), if a large number of parts need to be proicessed - VSAM
allocate overhead? Particular for 3rd party products which run at the VSAM
dataset level?




Regards

Jack

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html




______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Myron Miller

Re: partitioning in V8
(in response to Phil Grainger)
Phil,
I'm going to be a nitpicker here, but how can you have an XML column in V8? Your numbers are extremely accurate and make a point that many people don't consider when using these types of objects.

Excellent points.

Myropn




________________________________
From: "Grainger, Phil" <[login to unmask email]>
To: [login to unmask email]
Sent: Thursday, January 29, 2009 2:45:36 PM
Subject: Re: [DB2-L] partitioning in V8

Oh, and one other thing

Heaven help you if you have LOB or XML columns

If you DO, you will need one additional (table space + table + index) for EACH LOB/XML column for EACH partition

and you are still limited to 64K objects per database. Remember, the numbers add up FAST

a 4,096 partitioned object with one partitioned index and one LOB column will account for:

4,096 table space page sets
1 table
4,096 index page sets
4,096 LOB table spaces
4,096 aux tables
4,096 aux index page sets

= 20,481 objects!!!

Phil Grainger
CA

________________________________

From: DB2 Data Base Discussion List on behalf of Jack Campbell
Sent: Thu 29/01/2009 17:47
To: [login to unmask email]
Subject: Re: [DB2-L] partitioning in V8



In addition to Phil's comment on dataset opens......

how would so many partitions affect your MAX OPEN DATASETS for the DB2
sub-system. If there are a large number of partitions open concurrently this
could cause the close/re-open of datasets relating to other tablespaces.

If the table has a high hit-rate for multiple partitions concurrently, what
adverse affect would this have on other tables in the same bufferpool? You
may need to isolate the table into its own bufferpool

What would the effect be on utilities, such as COPY and REORG (assuming the
use of DPSI's), if a large number of parts need to be proicessed - VSAM
allocate overhead? Particular for 3rd party products which run at the VSAM
dataset level?




Regards

Jack

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html




______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Myron Miller

Re: partitioning in V8
(in response to Myron Miller)
My first question would be why so many? Is the table really that big? Due consideration of all the objects that have to be open and managed is as many others have mentioned a major concern.


________________________________
From: Dave Magnusen <[login to unmask email]>
To: [login to unmask email]
Sent: Thursday, January 29, 2009 10:01:23 AM
Subject: [DB2-L] partitioning in V8

As a relative newbie to DB2, and V8, please bear with me.

We have an application which would like to create many partitions.
Many thousand...
Has anyone partitioned to this level? Any horror stories, show-stoppers, or
little gotcha's you can share are most appreciated.

Thanks,

dave

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Paul Fegan

Re: partitioning in V8
(in response to Myron Miller)
Phil,

We have a new development with exactly the situation you just mentioned.

We have a table with LOB data that has a requirement to be stored for in
excess of 10 years. The individual LOB's aren't huge (estimated at between
300K and 500K per LOB). The only way we can see to allow for growth is to
allocate a 4096 partition base table with the accompanying AUX TS's and
AUX IX's. It would have been nice if IBM had extended the add partition to
include tablespace with LOB's but unfortunately they haven't, so you have
to allocate everything up front.

We're relatively lucky as we can define the partitioning key on an
identity column

PRTNBR INTEGER NOT NULL
GENERATED ALWAYS
AS IDENTITY
(
START WITH 1
INCREMENT BY 1
MINVALUE 1
MAXVALUE 16384000
CYCLE
CACHE 20
NO ORDER
)
.........
PARTITION BY RANGE
(
PRTNBR ASC
)
(
PARTITION 1
ENDING AT (4000)
,PARTITION 2
ENDING AT (8000)
,PARTITION 3
ENDING AT (12000)
.......

So each partition get 4000 LOB's (approx 2G) and we have enough partitions
to give us around 10 years of storage. If we hit the max value before then
it just cycles round to partition 1 again and they all start to grow to
4G. This gives us manageable sized partitions, that don't take too long to
copy or reorg and because of the nature of the stored data we should only
ever be referencing a few of the partitions at any given time. Once a
partition is filled it gets reorged and never touched again. If any of the
apps guys get any bright Ideas about scanning this puppy we will of
course have to kill them slowly and painfully.

The down side is that even empty the table takes around 2 hours to drop
and redefine. Which means once it's created it doesn't get changed as any
changes which require the base table to be dropped and recreated will
take more time than we have in app upgrade window. The other interesting
thing with this tables definition is that it's the first table I've ever
created that required a purpose built REXX exec just to create the DDL.
Try typing in 4096 partition ENDING AT values and see how many you get
wrong and then of course there are the 4096 AUX tablespaces and Index
spaces. I'm getting RSI just thinking about it.


Paul Fegan
DB2 Database Administrator
_____________________________________________________________
INFORMATION MANAGEMENT DIVISION | Queensland Transport
Creating business confidence

477 Boundary Street, Spring Hill QLD 4000
P: 07 3834 5022 F: 07 3834 2911
M: 0433 039 360
E: [login to unmask email]



"Grainger, Phil" <[login to unmask email]>
Sent by: DB2 Data Base Discussion List <[login to unmask email]>
30/01/2009 05:45 AM
Please respond to
DB2 Database Discussion list at IDUG <[login to unmask email]>


To
[login to unmask email]
cc

Subject
Re: [DB2-L] partitioning in V8





Oh, and one other thing

Heaven help you if you have LOB or XML columns

If you DO, you will need one additional (table space + table + index) for
EACH LOB/XML column for EACH partition

and you are still limited to 64K objects per database. Remember, the
numbers add up FAST

a 4,096 partitioned object with one partitioned index and one LOB column
will account for:

4,096 table space page sets
1 table
4,096 index page sets
4,096 LOB table spaces
4,096 aux tables
4,096 aux index page sets

= 20,481 objects!!!

Phil Grainger
CA

________________________________

From: DB2 Data Base Discussion List on behalf of Jack Campbell
Sent: Thu 29/01/2009 17:47
To: [login to unmask email]
Subject: Re: [DB2-L] partitioning in V8



In addition to Phil's comment on dataset opens......

how would so many partitions affect your MAX OPEN DATASETS for the DB2
sub-system. If there are a large number of partitions open concurrently
this
could cause the close/re-open of datasets relating to other tablespaces.

If the table has a high hit-rate for multiple partitions concurrently,
what
adverse affect would this have on other tables in the same bufferpool? You
may need to isolate the table into its own bufferpool

What would the effect be on utilities, such as COPY and REORG (assuming
the
use of DPSI's), if a large number of parts need to be proicessed - VSAM
allocate overhead? Particular for 3rd party products which run at the VSAM
dataset level?




Regards

Jack

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You
should have gotten an e-mail with the temporary password assigned to your
account. Please log in and update your member profile. If you are not
already an IDUG.org member, please register at
http://www.idug.org/component/juser/register.html




______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You
should have gotten an e-mail with the temporary password assigned to your
account. Please log in and update your member profile. If you are not
already an IDUG.org member, please register at
http://www.idug.org/component/juser/register.html


***********************************************************************
WARNING: This e-mail (including any attachments) may contain legally
privileged, confidential or private information and may be protected by
copyright. You may only use it if you are the person(s) it was intended
to be sent to and if you use it in an authorised way. No one is
allowed to use, review, alter, transmit, disclose, distribute, print
or copy this e-mail without appropriate authority.

If this e-mail was not intended for you and was sent to you by mistake,
please telephone or e-mail me immediately, destroy any hardcopies of
this e-mail and delete it and any copies of it from your computer
system. Any right which the sender may have under copyright law, and
any legal privilege and confidentiality attached to this e-mail is not
waived or destroyed by that mistake.

It is your responsibility to ensure that this e-mail does not contain
and is not affected by computer viruses, defects or interference by
third parties or replication problems (including incompatibility with
your computer system).

Opinions contained in this e-mail do not necessarily reflect the
opinions of the Queensland Department of Main Roads, Queensland
Transport or Maritime Safety Queensland, or endorsed organisations
utilising the same infrastructure.
***********************************************************************

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html

Steen Rasmussen

Re: partitioning in V8
(in response to Paul Fegan)
Hello Dave,

I would suggest you search the archives on this list. We have had many discussions related to this topic the past few years, but let me give you a couple of ideas:

1) You will definitely go with TCP instead of ICP (meaning the LIMITKEYS will be described on the create table statement as opposed to the create index statement).
2) Consider not to specify all partitions in one statement. It will run for a while since all the VSAM datasets need to be created and updated in the catalog. If the process fails somewhere, the entire thing need to be backed out. Instead specify a few in the create tablespace statement, create the table and index - and then use the ALTER command to add more partitions.
3) If you can avoid mixing ADD and ROTATE later on - I recommend this process since the physical and logical partitions will be out of sync and things can appear a little complicated when looking at utilities and display command output.
If you need to REBALANCE using REORG - practice this too. You will end in a RECP status if some partitions end up empty (at least this is how it used to be and I don't know if IBM changed this).

You can also use the IDUG website - I and others have presentations out there you might find useful.

Good luck

Steen Rasmussen
CA
Sr Engineering Services Architect
IBM Certified Database Associate - DB2 9 Fundamentals
IBM Certified Database Administrator - DB2 9 DBA for z/OS


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Dave Magnusen
Sent: Thursday, January 29, 2009 9:01 AM
To: [login to unmask email]
Subject: [DB2-L] partitioning in V8

As a relative newbie to DB2, and V8, please bear with me.

We have an application which would like to create many partitions.
Many thousand...
Has anyone partitioned to this level? Any horror stories, show-stoppers, or
little gotcha's you can share are most appreciated.

Thanks,

dave

______________________________________________________________________

* IDUG 2009 Melbourne, Australia * 18-20 March * http://IDUG.ORG/Events *
______________________________________________________________________




IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html


______________________________________________________________________

* IDUG 2009 Rome, Italy * 5-9 October * http://IDUG.ORG/Events *
______________________________________________________________________



IDUG.org was recently updated requiring members to use a new password. You should have gotten an e-mail with the temporary password assigned to your account. Please log in and update your member profile. If you are not already an IDUG.org member, please register at http://www.idug.org/component/juser/register.html