prodb, procopy or just cp
- Thread starter andersb
- Start date
tamhas
ProgressTalk.com Sponsor
You might get by with it in the simplest cases, but you won't get there with a database that has structure. Not that there aren't tools that might let you patch it together, but why? Always use the Progress tools which are knowledgeable about the structure of the database. Anything else either won't work or is risky.
BTW, same applies to backups. You cannot guarantee a useful backup with cp. Period. You can backup to a file and then use cp on the file, but the backup itself *must* be done with the Progress utilities to insure that it is usable and complete.
BTW, same applies to backups. You cannot guarantee a useful backup with cp. Period. You can backup to a file and then use cp on the file, but the backup itself *must* be done with the Progress utilities to insure that it is usable and complete.
TomBascom
Curmudgeon
I think that you're overstating the case. The Progress tools are db aware and that is certainly a plus. But OS tools will work -- you just have to be a lot more careful about some of the details (like making sure that the db is down and getting all of the components and possibly doing a prostrct repair).
For some situations, particularly very large databases, OS tools are the only viable choice. It simply takes to long to wait for a single threaded Progress copy or backup to complete. Whereas a multi-threaded "dd" command can do wonders
For some situations, particularly very large databases, OS tools are the only viable choice. It simply takes to long to wait for a single threaded Progress copy or backup to complete. Whereas a multi-threaded "dd" command can do wonders
tamhas
ProgressTalk.com Sponsor
Point being that you know how to use the non-Progress tools and get away with it, but most people don't.
Case in point being a customer I had who was using a network backup product to backup a live Progress database. I got both Gus and the president of the company who made the backup software to say that this wouldn't produce a reliable backup and they still did it.
Case in point being a customer I had who was using a network backup product to backup a live Progress database. I got both Gus and the president of the company who made the backup software to say that this wouldn't produce a reliable backup and they still did it.
ron
Member
Ha! Ha! I agree with both of you!
First - I would have to say emphatically that the "rule" is: use the Progress tools. To not use the tools provided when they will do what's needed is to take a foolhardy risk, in my opinion.
Having said that, however, I also agree fully with Tom: there are situations where the tools just don't do what you want. But if you do go outside the Progress toolset then OF COURSE you have to be damned careful and make certain that everything is done correctly.
I have a once-a-month job to copy a 300GB "warm spare" DB from one environment to another. I can't use procopy because it requires that I truncate the BI, which isn't possible with a warm spare DB. My choices were to take a "norecover" tape backup and restore it (which would have taken FAR longer than what was acceptable) - or cp all the DB extents and then do a prostrct repair. I chose the latter. Works just fine and takes a small fraction of the time. But, the process had to be carefully tested.
Nearly every "rule" has an exception!
First - I would have to say emphatically that the "rule" is: use the Progress tools. To not use the tools provided when they will do what's needed is to take a foolhardy risk, in my opinion.
Having said that, however, I also agree fully with Tom: there are situations where the tools just don't do what you want. But if you do go outside the Progress toolset then OF COURSE you have to be damned careful and make certain that everything is done correctly.
I have a once-a-month job to copy a 300GB "warm spare" DB from one environment to another. I can't use procopy because it requires that I truncate the BI, which isn't possible with a warm spare DB. My choices were to take a "norecover" tape backup and restore it (which would have taken FAR longer than what was acceptable) - or cp all the DB extents and then do a prostrct repair. I chose the latter. Works just fine and takes a small fraction of the time. But, the process had to be carefully tested.
Nearly every "rule" has an exception!
