need help dump-reload

C

customprogress

Member
i am doing the following:
1. dump - ok
2. prostrct create dbname , 2 gig and ok.
3. i try start using pro dbname
4. all sorts of errors no matter what i try, i know i am missing a step?
its been a long time.

any help apppreciated.

Damian.
 
It is traditional to mention the version of Progress. You might also mention the operating system in passing. "All sorts of errors" is rather vague too. You might consider providing an actual error message number or perhaps the relevant portion of the .lg file. ;)

None the less I'll go out on a limb and guess that the first error that you see when you attempt to start a session with "pro" is:

dbname is a void multi-volume database. (613)
Click to expand...

To fix that you need to procopy a non-void database onto the structure that you just created. Something like this:

procopy $DLC/empty dbname
Click to expand...

You then need to load the schema (presumably you dumped it when you dumped the data) before you can load the tables.

Depending on how you're doing this you may also need to rebuild indexes once the data is loaded.
 
[FONT=r_ansi]
version 7, aix 4.x

Unable to run the PROGRESS Procedure Editor _edit.p. (3261)
Press space bar to continue.

heres the .lg file.

[FONT=r_ansi]Sun Nov 19 01:18:09 2006
01:18:09 SRV 0: /u1/data/zatn is a void multi-volume database. (613)
Sun Nov 19 12:01:12 2006
12:01:12 procopy session begin for root on /dev/pts/1. (451)
12:01:34 Database copied from /dlc7/empty. (1365)
12:01:34 procopy session end. (334)
Sun Nov 19 12:01:55 2006
12:01:55 Single-user session begin for root on /dev/pts/1. (451)
12:02:06 Single-user session end. (334)
Sun Nov 19 12:04:06 2006
12:04:06 SRV 0: Multi-user session begin. (333)
12:04:18 Usr 1: Login by root on /dev/pts/1. (452)
12:06:54 Usr 1: Logout by root on /dev/pts/1. (453)
12:11:59 Usr 1: Login by root on /dev/pts/1. (452)
12:12:10 Usr 1: Logout by root on /dev/pts/1. (453)
12:13:36 Usr 1: Login by root on /dev/pts/1. (452)
12:13:46 Usr 1: Logout by root on /dev/pts/1. (453)
12:14:14 Usr 1: Login by root on /dev/pts/1. (452)
12:14:42 Usr 1: Logout by root on /dev/pts/1. (453)
"zatn.lg" 25 lines, 1064 characters
[/FONT][/FONT]
 
Ok, you got the procopy taken care of. Now you need to load the .df file.

Did you dump the .df?

How did you do the data dump? Is it a dictionary dump? (.d files) or a binary dump? (.bd files).

Unable to run _edit.p would seem to indicate that you have an incomplete (or corrupted) install or that this is a runtime license of Progress. If so then it is going to be a struggle to get beyond that.

If this is a runtime license then it would be helpful if you have a copy of an empty database with the application schema in it rather than $DLC/empty.db. This is generally provided by the vendor who sold the runtime-only application. Without that you're probably going to have a difficult time loading the data and getting your r-code to run against the new database (the CRC's will probably be different because loading a .df file usually doesn't result in the same field rpos values).

Do you have source (either clear text or encrypted) to compile?

Why are you loading into v7 on AIX 4? If you're going to the trouble of dumping and loading you really ought to upgrade to something that was released in this century... Plus your wristwatch will have more compute power than whatever ancient beast it is that is still running AIX4 ;)

In any event -- to load the .df file (if you have one and cannot find an empty db for the application schema...) try "pro zatn -p dict.p" or "pro -rx -p dict.p" to get you into the data dictionary. If you're lucky that may bypass the _edit.p problem.
 
first off, thanks tom.

i have been promised funds for upgrade in a "few months" these few months is now 2 years! :biggrin:

the dump is no problem . "admin" dump df and .d , seq, etc.

i went back to a basic create a db, empty and try log in using pro and i get the same error.

the existing production multi volume databases have no problem.
?is it a PATH problem maybe?
heres exactly what i tried.

# prodb zatn
Please enter
demo to get the system demonstration database, or
sports to get the sports demonstration database, or
isports to get the international sports database, or
empty to get the system empty database, or
anyname to get a copy of that database. : empty
New PROGRESS database zatn created (from empty).
# pg zatn.lg
Database created from empty on Mon Nov 20 16:54:02 2006
# pro zatn


@@@@@@ @@@@@@ @@@@@@@ @@@@@ @@@@@@ @@@@@@@ @@@@@ @@@@@
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @
@ @ @ @ @ @ @ @ @ @ @ @
@@@@@@ @@@@@@ @ @ @ @@@@ @@@@@@ @@@@@ @@@@@ @@@@@
@ @ @ @ @ @ @ @ @ @ @ @
@ @ @ @ @ @ @ @ @ @ @ @ @ @
@ @ @ @@@@@@@ @@@@@ @ @ @@@@@@@ @@@@@ @@@@@
Progress Software Corporation
14 Oak Park
Bedford, Massachusetts 01730
617-280-4000
PROGRESS is a registered trademark of Progress Software Corporation
Copyright 1984,1985,1986,1987,1988,1989,1990,1991,1992,1993,1994,1995,1996
by Progress Software Corporation
All Rights Reserved
PROGRESS Version 7.3D01 as of Fri May 24 14:15:10 EST 1996
Unable to run the PROGRESS Procedure Editor _edit.p. (3261):mad:
Press space bar to continue.
 
It might be a PATH, PROPATH or a DLC problem although I don't, offhand, see how it could be unless you are, perhaps, using very different methods to access these two databases.

Are there any scripts involved? Is the "pro" script, perhaps, being run out of $DLC in one case and out of /usr/bin in the other? (That might happen if there is a script to start the old database and if at some point somebody installing progress selected the "install scripts" option (I always answer *NO* to that prompt...) and then some changes/upgrades occured that moved the "official" $DLC)

Can you successfully start a simple "pro" session from the command line against the old database, get to the editor, "quit" and then "pro" the new database and have it fail? (I would expect that they either both work or they both fail.)
 
Hello.

The other step before to pro command is copy an empty database, for example, if your database is of default blocks, just:

procopy $DLC/empty db-name

If you database is of 8192 blocks: do the same :

procopy $DLC/empty8 db-name
 
Hi Tom,

I am just adding one more query to this existing dump-load thread.

Progress 9.1D
Linux OS

Ours is a 24*7 production DB, but we need to do the ASCII dump/load. AI imaging is implemented. To minimize the downtime, is there a way around where our ai files are helpful. Is it possible that we take a full backup of the DB and restore it on some other server, do the D/L on this DB. And once the D&L is over, we bring down the production DB, roll forward all the AI files on this new DB and copy this DB on to the production DB . I need your guidance in this regard. If this is possible, then how reliable this process is? And if i am wrong, is there a way where we can reduce the Production DB downtime for ASCII Dump/Load?

--Dilip
 
No, you cannot roll forward the ai files in that manner. AI files are specific to the block structure of a particular instance of a database. The newly created db will not be compatible.

You could do something similar via replication triggers. It's complicated to setup though.

How much downtime can you actually afford? How big is the database?
 
The database size is around 25GB. I can take a downtime of around 6 hours. We need time for index rebuilding as well along with the Ascii D/L.
 
dilipsdc said:
The database size is around 25GB. I can take a downtime of around 6 hours. We need time for index rebuilding as well along with the Ascii D/L.
Click to expand...

Unless you have woefully inadequate hardware 6 hours should be plenty of time to dump & load 25GB.

Why do you think that you need to use an ASCII d&l? And if you do use ASCII d&l why do you think that you need an index rebuild?
 
Dear dilipsdc,

Did you try start the Database without the Before Image? When you disable the Before Image, the process of Dump and Load is faster.

Try start the Database with this line:

pro [database] -i -TM 32 -TB 31

This way the database will not create a register in Before Image for each register created in DB.

Note: When I knew Binary Dump Load never more changed, It's very quickly.

Regards.


dilipsdc said:
Hi Tom,

I am just adding one more query to this existing dump-load thread.

Progress 9.1D
Linux OS

Ours is a 24*7 production DB, but we need to do the ASCII dump/load. AI imaging is implemented. To minimize the downtime, is there a way around where our ai files are helpful. Is it possible that we take a full backup of the DB and restore it on some other server, do the D/L on this DB. And once the D&L is over, we bring down the production DB, roll forward all the AI files on this new DB and copy this DB on to the production DB . I need your guidance in this regard. If this is possible, then how reliable this process is? And if i am wrong, is there a way where we can reduce the Production DB downtime for ASCII Dump/Load?

--Dilip
Click to expand...
 
You must log in or register to reply here.
Back
Top