dbTalk Databases Forums  

Better Update of column CARD on syscat.tables

comp.databases.ibm-db2 comp.databases.ibm-db2


Discuss Better Update of column CARD on syscat.tables in the comp.databases.ibm-db2 forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Bruce
 
Posts: n/a

Default Better Update of column CARD on syscat.tables - 10-10-2011 , 02:44 PM






Hi all -

DB2 for LUW 9.1.4...on AIX 6...

Going through a PeopleSoft migration..about 3600 tables...big boss
wants us to do a runstats AFTER a redirected-restore to ensure that
the row-count is the same on the target DB as it was on the source...I
tried to explain...etc.etc.etc... but they still want this.

I did 'db2 reorgchk update statistics...' and it took 17 hours.

I did a 'db2 runstats on table xyz' for the entire DB and it took 10
hours...

Is there a better faster way to get CARD on syscat.tables updated?

I suppose I could SELECT COUNT(*) for all tables...on source and
target DB's...and write the results somewhere and compare...

The entire exercise is pointless but...still...thought I'd
ask....Looking for a quick thinggie here.

Reply With Quote
  #2  
Old   
Arun Srini
 
Posts: n/a

Default Re: Better Update of column CARD on syscat.tables - 10-11-2011 , 05:22 AM






Reorgchk is an utility to check the requirement for a reorg - which is
the activity involving de-clustering the data in a table or index.
The option of 'update statistics' does collect all the stats but it's
main aim is to check for reorg and so does a lot more than just
collecting stats.
runstats is mainly used to collect statistics for db2 optimizer's use
and it too does a lot more than collect a cardinality of the
table(frequency stats, quantile stats etc). It helps DB2 to form the
best access paths for any query, and it's cardinality may not be
accurate when run while the table data is being modified.
What you should be doing is to fire off 'select count(*)' statements
and check against the source data and using the above two utilities is
like going to Italy to eat a pizza.

Arun

On Oct 10, 3:44*pm, Bruce <bwmille... (AT) gmail (DOT) com> wrote:
Quote:
Hi all -

DB2 for LUW 9.1.4...on AIX 6...

Going through a PeopleSoft migration..about 3600 tables...big boss
wants us to do a runstats AFTER a redirected-restore to ensure that
the row-count is the same on the target DB as it was on the source...I
tried to explain...etc.etc.etc... but they still want this.

I did 'db2 reorgchk update statistics...' and it took 17 hours.

I did a 'db2 runstats on table xyz' for the entire DB and it took 10
hours...

Is there a better faster way to get CARD on syscat.tables updated?

I suppose I could SELECT COUNT(*) for all tables...on source and
target DB's...and write the results somewhere and compare...

The entire exercise is pointless but...still...thought I'd
ask....Looking for a quick thinggie here.

Reply With Quote
  #3  
Old   
Bruce
 
Posts: n/a

Default Re: Better Update of column CARD on syscat.tables - 10-11-2011 , 07:14 AM



On Oct 11, 6:22*am, Arun Srini <arunro... (AT) gmail (DOT) com> wrote:
Quote:
Reorgchk is an utility to check the requirement for a reorg - which is
the activity involving de-clustering the data in a table or *index.
The option of 'update statistics' does collect all the stats but it's
main aim is to check for reorg and so does a lot more than just
collecting stats.
runstats is mainly used to collect statistics for db2 optimizer's use
and it too does a lot more than collect a cardinality of the
table(frequency stats, quantile stats etc). It helps DB2 to form the
best access paths for any query, and it's cardinality may not be
accurate when run while the table data is being modified.
What you should be doing is to fire off 'select count(*)' statements
and check against the source data and using the above two utilities is
like going to Italy to eat a pizza.

Arun

On Oct 10, 3:44*pm, Bruce <bwmille... (AT) gmail (DOT) com> wrote:



Hi all -

DB2 for LUW 9.1.4...on AIX 6...

Going through a PeopleSoft migration..about 3600 tables...big boss
wants us to do a runstats AFTER a redirected-restore to ensure that
the row-count is the same on the target DB as it was on the source...I
tried to explain...etc.etc.etc... but they still want this.

I did 'db2 reorgchk update statistics...' and it took 17 hours.

I did a 'db2 runstats on table xyz' for the entire DB and it took 10
hours...

Is there a better faster way to get CARD on syscat.tables updated?

I suppose I could SELECT COUNT(*) for all tables...on source and
target DB's...and write the results somewhere and compare...

The entire exercise is pointless but...still...thought I'd
ask....Looking for a quick thinggie here.- Hide quoted text -

- Show quoted text -
Did you even read my question? Sheesh...I know all
that...obviously...I pointed it all out in my posting...I'm asking for
a simple easier way to update CARD without running a long-ass DB2
utility that does 'the world'.

Reply With Quote
  #4  
Old   
MarkB
 
Posts: n/a

Default Re: Better Update of column CARD on syscat.tables - 10-12-2011 , 01:15 AM



Hi Bruce,

"A simple easier way":

update sysstat.tables
set card=NNN
where tabschema='YOUR_TABLE_SCHEMA' and tabname='YOUR_TABLE_NAME'

and you will see the same value NNN in the syscat.tables.card after
that.

Regards,
Mark B.

Reply With Quote
  #5  
Old   
Frederik Engelen
 
Posts: n/a

Default Re: Better Update of column CARD on syscat.tables - 10-27-2011 , 11:12 AM



On 12 okt, 08:15, MarkB <mark.barinst... (AT) gmail (DOT) com> wrote:
Quote:
Hi Bruce,

"A simple easier way":

update sysstat.tables
set card=NNN
where tabschema='YOUR_TABLE_SCHEMA' and tabname='YOUR_TABLE_NAME'

and you will see the same value NNN in the syscat.tables.card after
that.

Regards,
Mark B.
Check the db2look mimic mode...

--
Frederik Engelen

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.