Restore DB - Blksize error

AJH

New Member
I'm trying to Restore from a PROD backup to TEST, but are having this error:

Records per Block mismatch, backup has 32, database has 64

I have tried to alter .st file to match Prod for blksize, and retry Restore but still gives error.

Any thoughts?

Thanks
 

TomBascom

Curmudgeon
Blocksize is not the problem. Rows per block is.

You have not mentioned your OpenEdge version and your platform and have not provided any information about the two apparently different .st files. All of that would be useful.

Generally the entries in the .st file look something like this:

Code:
d "Schema Area":6,32;1 .

In this case "d" means that it is a data area, "Schema Area" is the name of the storage area, 6 is the area number, 32 is the rows per block and 1 is the blocks per cluster. Those must *all* match between the source and target database.

You must also have the same list of areas.

The number of extents per area, the path to those extents, and the sizes of each extent do not need to be the same.

You can also restore by first deleting the target db and any existing .st file. But you lose some control over where things go and how extents are sized if you do that.

Personally I usually start by taking the source (PROD) structure file, copy it to the target (TEST) and edit the path names, number of, and sizes of extents if any of that needs to change. I then do a "prostrct create" to initialize the db (that saves time when doing the restore).
 

AJH

New Member
Sorry version OpenEdge Release 10.1C04 Unix\AIX

I made structure files match except for path to those extents. I still get the same error:
Records per Block mismatch, backup has 32, database has 64
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I made structure files match except for path to those extents. I still get the same error:
Records per Block mismatch, backup has 32, database has 64
Can you show the contents of the source and target structure files?

Also, are you doing the restore into a directory that is empty, apart from the .st file? Or does it contain an older copy of the database?
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
It has the older copy of the database
And after you ensure the structure file of that database is current (prostrct list dbname), how do the configuration parameters of each of the storage areas in that structure file compare with those in the structure file of the source database?

In particular, how do the areas' Records Per Block settings (the number after the comma on each line item) compare?
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
There revert back back to what was there before I made them match.
Which means they didn't match in the first place. Which is what the error message told you.

You can't restore a backup of database A overtop of database B if A and B don't match exactly in the manner that Tom described.
In this case "d" means that it is a data area, "Schema Area" is the name of the storage area, 6 is the area number, 32 is the rows per block and 1 is the blocks per cluster. Those must *all* match between the source and target database.

You must also have the same list of areas.

The number of extents per area, the path to those extents, and the sizes of each extent do not need to be the same.
 

AJH

New Member
I use VI on the .st file to make them match:

This is how they look currently
PROD:
d "ACTIVE":7,32;8

Test:
d "ACTIVE":7,64;1

I update Test using VI.
d "ACTIVE":7,32;8

run (prostrct list dbname)
Area Name: ACTIVE, Type 6, Block Size 4096, Extents 2, Records/Block 64, Cluster Size 1
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
Modifying the structure file does not modify the database. If the storage areas don't currently match in RPB, there is nothing you can do to the structure file to make them match. An area's RPB cannot be changed.

You will need to restore your backup into an empty directory (or a directory containing only a valid, matching structure file), not overtop of this non-matching database.
 
Top