Conference orarep::nomahs::repository

1078.0. "CDO VERIFY/BEBUILD taking time" by M5::GHODSON () Mon Apr 07 1997 14:04

Hi:

I have a customer with CDD 5.3 and Rdb 6.1-04 on an alpha.  Her 
repository was 2.300 K blocks.  This space just includes the .rdb and
two .rda files.  She has already compressed the snapshot files and moved
them to another place.  The space is used by all the history
data that's been stored in the repository.  She is not using the
logical CDD$KEEP_HISTORY_ON_DELETE.

At this poing something had to be done to get the repository smaller.
To get it compressed she did the following, knowing this is unsupported:

$ mcr sql$
SQL> attach 'filename cdd$database';
SQL> delete from cdd$$o_history_list;
SQL> delete from cdd$$o_history;

and then an sql export/import.

The resulting cdd$database .rdb and rda files shrunk to 640K blocks.
She then did a CDO VERIFY/ALL/NOFIX and got pages of errors saying
 "mcs_history_list ... has no member ...".  This was for each of her
dictionary elements.  She then did a CDO VERIFY/REBUILD.  This
verify completed today.  She is now going to do a CDO VERIFY/ALL/NOFIX to
see what state the repostiory is in.

Her question is, before beginning this process, when she would do a
CDO VERIFY/REBUILD, it would take 20 to 30 hours to complete.  This
time the CDO VERIFY/REBUILD on the compressed dictionary took 54
hours to complete.

  - any explaination for this time difference?
  - would doing something like adjusting rdm$bind_buffers help this
    verify/rebuild?
  
Thanks for any help.
--Gary Hodson

Hi Gary,

>data that's been stored in the repository.  She is not using the
>logical CDD$KEEP_HISTORY_ON_DELETE.

	CDD$KEEP_HISTORY_ON_DELETE is only valid with CDD/Repository V6.1.


>SQL> delete from cdd$$o_history_list;
>SQL> delete from cdd$$o_history;

	Please, don't delete everything in CDD$$O_HISTORY_LIST and 
	CDD$$O_HISTORY. Delete only what is no longer used.


>  - any explaination for this time difference?
>  - would doing something like adjusting rdm$bind_buffers help this
>    verify/rebuild?
  
	I am not really astonished by the fact the second rebuild takes longer.
	One thought among others, maybe your SQL IMPORT was too strong. Is 
	there any Rdb difference after the VERIFY/REBUILD_DIRECTORY against 
	what you specified in your IMPORT?

Patrick

    Thanks Patrick.  The customer actually only deleted history data
    from last year.  After doing the verify/rebuild, she then yestday
    did a verify/all/nofix and just got a few orphans.  She then did
    a verify/orphans/fix to clean these.  Now she is doing another
    verify/all/nofix.