Frank,
You may try this,
- Take list of files in live (LISTFILE [log in to unmask])
- Use this list as file reference while doing RESTORE by removing MACMANGB from the list
- After restoring, re-index the database
Good luck,
Ram Thekkekara
Hickory Farms, Inc
Ph: (419) 893 7611 ext 376
email : [log in to unmask]
---------- Original Message ----------------------------------
From: "Wilkinson, Mark" <[log in to unmask]>
Reply-To: "Wilkinson, Mark" <[log in to unmask]>
Date: Fri, 12 May 2000 10:05:36 +0100
>Hmm. These GB files seem to be created by IMAGE when the database is first
>opened so restoring a database that has a GB file means that the database
>was actually open when it was stored. Restoring it is *NOT* a very good
>ideas.
>
>Example from our test box.
>
>937\SWY2K\DB:LISTF VFDS01@,2
>ACCOUNT= SWY2K GROUP= DB
>
>FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
> SIZE TYP EOF LIMIT R/B SECTORS #X MX
>
>VFDS01 PRIV 128W FB 14 14 1 32 1 1
>VFDS0101 PRIV 256W FB 63 63 1 128 1 1
>VFDS0102 PRIV 256W FB 54 54 1 112 1 1
>VFDS0103 PRIV 256W FB 231 231 1 464 1 4
>VFDS0104 PRIV 256W FB 167 167 1 336 1 1
>VFDS0105 PRIV 128W FB 113 113 1 128 1 29
>VFDS0106 PRIV 256W FB 78 78 1 160 1 27
>VFDS0107 PRIV 256W FB 23 23 1 48 1 1
>VFDS0108 PRIV 256W FB 300 300 1 608 1 5
>VFDS0109 PRIV 256W FB 72 72 1 160 1 2
>VFDS0110 PRIV 256W FB 115 115 1 240 1 2
>VFDS0111 PRIV 256W FB 167 167 1 336 1 1
>VFDS0112 PRIV 256W FB 800 800 1 1616 1 1
>VFDS0113 PRIV 256W FB 667 667 1 1344 1 1
>VFDS0114 PRIV 128W FB 500 500 1 512 1 32
>
>
>937\SWY2K\DB:QUERY
>
>HP32216N.03.14 QUERY/NM FRI, MAY 12, 2000, 10:02 AM
>COPYRIGHT HEWLETT-PACKARD CO. 1976
>
>>X DB01.PUB
>
>B=VFDS01.DB.SWY2K
>PASSWORD =
>MODE = 1
>ASSIGN LOCKOPTION=OFF
>END OF XEQ FILE
>
>>:LISTF VFDS01@,2
>ACCOUNT= SWY2K GROUP= DB
>
>FILENAME CODE ------------LOGICAL RECORD----------- ----SPACE----
> SIZE TYP EOF LIMIT R/B SECTORS #X MX
>
>VFDS01 * PRIV 128W FB 14 14 1 32 1 1
>VFDS0101 PRIV 256W FB 63 63 1 128 1 1
>VFDS0102 PRIV 256W FB 54 54 1 112 1 1
>VFDS0103 PRIV 256W FB 231 231 1 464 1 4
>VFDS0104 PRIV 256W FB 167 167 1 336 1 1
>VFDS0105 PRIV 128W FB 113 113 1 128 1 29
>VFDS0106 PRIV 256W FB 78 78 1 160 1 27
>VFDS0107 PRIV 256W FB 23 23 1 48 1 1
>VFDS0108 PRIV 256W FB 300 300 1 608 1 5
>VFDS0109 PRIV 256W FB 72 72 1 160 1 2
>VFDS0110 PRIV 256W FB 115 115 1 240 1 2
>VFDS0111 PRIV 256W FB 167 167 1 336 1 1
>VFDS0112 PRIV 256W FB 800 800 1 1616 1 1
>VFDS0113 PRIV 256W FB 667 667 1 1344 1 1
>VFDS0114 PRIV 128W FB 500 500 1 512 1 32
>VFDS01GB* PRIV 128W FB 1680 1681 1 1696 1 *
>
>>
>
>FWIW.
>
>Mark Wilkinson.
>
>> -----Original Message-----
>> From: Hoxsie, Howard [mailto:[log in to unmask]]
>> Sent: 12 May 2000 00:14
>> To: [log in to unmask]
>> Subject: Re: Restore problem for an image database
>>
>>
>> IIRC, and ICBW, but I thought the "dbnameGB" files were the
>> Omnidex key
>> files and they get handled quirkily by Image when doing STORE's and
>> RESTORE's. It's like they're part of the database, but not
>> really. I don't
>> recall off-hand just how that works, you'd need to talk to a
>> DBA for that.
>> :-)
>>
>> Howard Hoxsie
>> HP3000 Systems Administrator
>> 600 University Street, Suite 600
>> Seattle, WA 98101
>> Nordstrom.com
>> 206.215.7069 voice
>> 206.215.7869 fax
>> [log in to unmask]
>> visit us at http://www.nordstrom.com
>>
>> > -----Original Message-----
>> > From: [log in to unmask]
>> > [SMTP:[log in to unmask]]
>> > Sent: Thursday, May 11, 2000 3:11 PM
>> > To: [log in to unmask]
>> > Subject: Re: Restore problem for an image database
>> >
>> > Frank,
>> >
>> > Try the restore using the command:
>> > :restore *T; MACMAN.MACSDATA.BTLIVE, MACMAN##.MACSDATA.BTLIVE;...
>> >
>> > Since only 27 files qualified for the restore, I suspect
>> that "MACMANGB"
>> > is
>> > the file that gets created when a database is first opened
>> up and deleted
>> > when the last process accessing the database closes it.
>> >
>> > I don't know how it was included in the backup in the first
>> place, since
>> > most backup packages will 'flag' such a file as being in a
>> state that
>> > prevents it from being stored (Although I have no experience how the
>> > 'online' store packages handle such a file).
>> >
>> > Regards
>> > Paul Christidis
>> >
>> >
>> >
>> >
>> >
>> >
>> > I am hoping someone can help me resolve an issue. I have
>> been restoring
>> > databases in a production group with out problems by doing
>> the following:
>> >
>> > :FILE T;DEV=7
>> > :RESTORE *T;@[log in to unmask];&
>> > :ACCOUNT=BTTEST;CREATOR=MGR;GID=BTTEST;&
>> > :SHOW;PROGRESS=1
>> > This restore restores about 5 image databases in the group,
>> the root file
>> > and the individual files. I have spent most of this
>> afternoon trying to
>> > restore the data from our live account to a test account,
>> and am getting
>> > the
>> > following errors:
>> >
>> >
>> > MACMANGB.MACSDATA.BTLIVE NOT RESTORED: FILE IS PART OF AN IMAGE
>> > DATABASE
>> > AND
>> > ROOT IS NOT
>> > SPECIFIED.
>> >
>> > WILL RESTORE 27
>> > FILES ; NUMBER OF FILES ON MEDIA 48502
>> > MACMAN05.MACSDATA.BTTEST NOT RESTORED: DISC ALLOCATION FAILURE
>> >
>> > A discfree c returns the following for the volume set the
>> files are on:
>> >
>> > LDEV : 3 -- (SGA_APPL_VOLUME_SET:MEMBER1)
>> > Device | 50331632 | 43226304 ( 86%) |
>> 7105328 ( 14%) |
>> > Permanent | 50331632 (100%) | 43226304 ( 86%) |
>> 7105328 ( 14%) |
>> > Transient | 50331632 (100%) | 0 ( 0%) |
>> 7105328 ( 14%) |
>> >
>> > LDEV : 4 -- (SGA_APPL_VOLUME_SET:MEMBER2)
>> > Device | 50331632 | 42820912 ( 85%) |
>> 7510720 ( 15%) |
>> > Permanent | 50331632 (100%) | 42820912 ( 85%) |
>> 7510720 ( 15%) |
>> > Transient | 50331632 (100%) | 0 ( 0%) |
>> 7510720 ( 15%) |
>> >
>> > LDEV : 5 -- (SGA_APPL_VOLUME_SET:MEMBER3)
>> > Device | 50331632 | 43170208 ( 86%) |
>> 7161424 ( 14%) |
>> > Permanent | 50331632 (100%) | 43170208 ( 86%) |
>> 7161424 ( 14%) |
>> > Transient | 50331632 (100%) | 0 ( 0%) |
>> 7161424 ( 14%) |
>> >
>> >
>> > LDEV : 50 -- (SGA_APPL_VOLUME_SET:MEMBER4)
>> > Device | 41943024 | 21072960 ( 50%) |
>> 20870064 ( 50%) |
>> > Permanent | 41943024 (100%) | 21072960 ( 50%) |
>> 20870064 ( 50%) |
>> > Transient | 41943024 (100%) | 0 ( 0%) |
>> 20870064 ( 50%) |
>> >
>> > LDEV : 51 -- (SGA_APPL_VOLUME_SET:MEMBER5)
>> > Device | 41943024 | 21236192 ( 51%) |
>> 20706832 ( 49%) |
>> > Permanent | 41943024 (100%) | 21236192 ( 51%) |
>> 20706832 ( 49%) |
>> > Transient | 41943024 (100%) | 0 ( 0%) |
>> 20706832 ( 49%) |
>> >
>> >
>> > This seems to be ample free room, I am overlaying the
>> existing databases
>> > to
>> > refresh the account.
>> >
>> > I have tried adding NOACD on the restore line with the same results.
>>
>
|
