[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::repository

Title:Oracle CDD/Repositorynce
Notice:Current versions are V7.0-01 and V6.1-03eld Test 3
Moderator:8292::PJACOBN
Created:Thu Jan 21 1993
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1094
Total number of notes:4913

1088.0. "takes too long to convert from 5.3 to 7.0 " by 8292::PJACOB (Patrick [email protected]) Tue May 13 1997 07:39

    A customer has performance problem to convert their repository from
    5.3-09 to 7.0. 
    
    This repository has a CDD$DATA.RDA of 220000 blocks and a CDD$DATABASE.RDA 
    of 404000 blocks. They use CONVERT/REPOS to convert from 5.3-09 to 7.0 on 
    VAX 4106. Up to now, it took more than 1 day and 2 hours and
    it is not finished yet. 1 hour and 46 minutes CPU , 16 megas of memory
    for the process 31,344,000 pages fault ! The process is mostly in PFW state.
    Pagefiles are not satured.
    The dictionary is linked to 27 other dictionaries but the conversion
    does not seem to access them. 2 sort files of 80000 blocks each have been
    created but they don't seems to grow. CDD$WAIT is defined to protected . 
    Record statistics of RMU/SHOW STATISTICS shows :
            36149 records marked
          1034057 records fetched , 0 fragmented
            12404 records stored  , 0 fragmented
            12404 pages checked   , 0 discarded
                1 record erased   , 0 fragmented
    
    Any help will be appreciated. Any recommandations if he has to retry the
    conversion again on another machine? 
    
    Patrick
T.RTitleUserPersonal
Name		DateLines
1088.1UKVMS3::PJACKSONOracle UK Rdb SupportTue May 13 1997 08:428
    That's 3 times bigger than the biggest repostiory I have seen before,
    so I am not surprised that it takes a while :-)
    
    Paging seems to be the main problem. What are the working set
    parameters for the process (quota and extent)? What does monitor page show?
    How many Rdb buffers are you using?
    
    Peter
1088.2still faulting and faulting and faulting and faulting and faulting8292::PJACOBPatrick [email protected]Tue May 13 1997 10:3615
    
    last news ( direct live ) : 
    	1h49 CPU 
    	33,527,213 page faults 
    	1 day 5 hour elapsed 
    Customer getting more and more anxious.
    
    WSQUOTA : 16000 , WSEXTENT :32000 , RDM$BIND_BUFFERS not defined ( ie
    50 ). MONITOR PAGE varies showing sometimes Demand Zero Fault Rate
    activity but more often Free List Fault Rate and Demand Zero Fault
    Rate.  Essentially Page Read Rate and Page Read I/O Rate activity.
    
    Any help?
    
    Patrick
1088.3NOVA::SMITHIDon't understate or underestimate Rdb!Tue May 13 1997 10:516
You need to get the faulting down.

I'd set WSQUOTA closer to WSEXTENT (see Rdb documentation for Sorting).
Upping RDM$BIND_BUFFERS wouldn't hurt, this should cut down the I/O's.

Ian
1088.4UKVMS3::PJACKSONOracle UK Rdb SupportTue May 13 1997 11:027
    Looks like it just needs more memory.
    
    What's WSMAX for the system?
    
    Setting WSQUOTA equal to WSEXTENT might help.
    
    Peter
1088.5some infos8292::PJACOBPatrick [email protected]Thu May 15 1997 06:4939
Hi all,

I get the repository from the customer. I restored only the failing repository
because I don't have so much space. I fixed the location which removed the 
external references anyway. 
	WSquo:        		32000
	WSextent:     		32000
	Pgflquo:     	       270000
	WSMAX 	      	        28700
	VIRTUALPAGECNT 	       270144      
	PAGEFILE.SYS	       270096
	RDM$BIND_BUFFERS          500	

I am less lucky(?) than the customer because I get an error. Conversion fails :
$ repos opera convert/repos D$DOGG:[DICTIONNAIRE.DOGG]
Are you satisfied with the backup of your repository? [Y/N] (N): y
%CDO-E-ERRCONVERT, error converting object
-CDD-E-NOUPGRADE, use DICTIONARY IMPORT/EXPORT or CONVERT/DICTIONARY to upgrade
to protocol version 26.3
-COSI-F-FILWRITEERR, error writing file
$

$ repos export/version=v53 D$DOGG:[DICTIONNAIRE.DOGG] test.cddx 
%CDDX-F-ERREXPRT, error exporting repository
-COSI-F-EXQUOTA, exceeded quota
-SYSTEM-F-VASFULL, virtual address space is full
%CDDX-F-ERREXPRT, error exporting repository
$

Patrick

PS: 
Yesterday, the customer conversion was at 48,000,000 page faults and more than
2h12 CPU times : 2 days and still no conversion completion ! If he has to
interrupt it , what suggestion can be done precisely ? Setting wsquo to 32000 (
like wsextent ) does not seem to convince him . Setting bind buffers as well (
which value?).

BUG # 1088 has been submitted