How do ceate an empty copy of a database

l0913a

New Member
Newbie here,

I have to do a dump load of a 70 gig database. If I use prodb to create an empty copy of the existing production database can I just run proutil and load the binary dump flles into the new empty copy of the production database?

Also, what are some of the things I should be thinking about when I create the new and empty copy to improve the database performance.?

One thing I tried was procopy empty8 to a new multivolume void database, it looks like my target databasee has multiple block sized for the procopy fails due to block sized not matching.
 
What you need to do is to create an empty database with the production schema. prodb won't do that for you.

First design the new target structure file. To do that you need to understand your data -- "proutil dbanalys" is a handy tool to get that process started. You might also find this helpful:

Storage Areas

You use "prostrct create" to build the database described in the structure file and copy empty (or empty4 or empty8) into the "void" database (this puts the Meta-schema into the database. Once the empty db is built you load the source schema (.df files, obtained by dumping definitions from the production database). You now have an empty database that is ready to load data into.

(You need to figure out how to assign "objects" (that is tables and indexes) to storage areas if you are changing the design from the source to the target. There are several ways to do this. I just delete all AREA references from the source .df and then write a script that does tables moves -- because the db is empty at this point they are very fast.)

You can do all of the above long before starting the dump and load. Which saves a bit of time.

You are then ready to dump & load. That takes some thought too. There are many ways to approach it. I gave a talk on one approach at Exchange this year and last year that you might find helpful:

Highly Parallel Dump & Load
 
Hi Tom-

Thanks for your reply. Couldn't I just do a procopy of the existing database and then do a prodel the areas? Or is that silly? We have alot of custom tables and really just want to dump and load the data in binary format. So for this scope, I thought a copy of the existing database minus all the data (prodel the areas), followed by a load of the df's for the tables and then the proutil load of the binary dump followed by a rebuild of the indexes would be the simplest procedure.
Let me and all the other newbies know.
 
Prodel deletes whole databases not individual areas.

You could, perhaps use a series of "proutil dbname -C truncate area" to remove all of the data from an area. (If you happen to have all of your data and indexes outside of the schema area.)

But why? You're going to a lot of trouble to make this hard. Just do a prostrct create and load the .df. You'll get what you want (an empty database) in a form that is much more usable in a lot less time and with less aggravation.
 
Why do you think that you want to do a binary dump and load?

It may, or may not, be your best choice. I don't know. But it is not a foregone conclusion that all dump & loads must be binary.

You should think about why you are dumping and loading first and what you hope to achieve as a result. Then (if necessary) plan a target database design that meets those requirements. Then decide how to get there (binary d&l, dictionary d&l, buffer copy d&l, and lots of variations in how you put the process together...). You might even find out that there is no justification for doing a dump and load at all.

It seems to me that you have "the cart before the horse". You're trying to force implementation details -- getting a copy of the empty database by particular means, doing a particular flavor of dump & load... before you have given proper consideration to the much more important questions. And on top of that you want "the simplest procedure".
 
Hi Tom,

I appreciate what you are saying about the cart before the horse. Unfortunately it doesn't seem like my management sees it thatway and wants to slam dunk the dump load. I work in an interesting enfironment, driven by deadlines more than by thoughtfull analysis and then implementation.

If I could get them to agree would you have any interest consutling? Or is that no appropriate for this forum?
 
Hi Tom,

I appreciate what you are saying about the cart before the horse. Unfortunately it doesn't seem like my management sees it thatway and wants to slam dunk the dump load. I work in an interesting enfironment, driven by deadlines more than by thoughtfull analysis and then implementation.

If I could get them to agree would you have any interest consutling? Or is that no appropriate for this forum?

Of course I'd be interested -- it is, after all, what I do for a living ;) But we should take any further discussion of consulting offline. Feel free to e-mail me.
 
Back
Top