In <1995Jan17.231747.22825 AT draper DOT com>, URMM AT vm.marist DOT edu
(Martha McConaghy) writes:
>Melinda,
>
>Basically it was because I didn't have a mirror volume at all. When I
>installed ADSM and configured the server about 1.5 years ago, I made a
>mistake when defining the database and mirror volumes and ended up with
>two primary volumes instead. I wasn't aware of this until Mike started
>to work with me on the crash recovery. By then, the database had filled
>the first volume and had started using the second volume (the one destroyed).
>
>I recommend that if you "think" you are using mirror volumes for the database
>and/or recovery log that you use QUERY DBV and QUERY LOGV to verify it.
>IMHO, its an easy mistake to make and, unless you have reason to check,
>you won't know it. I've already run into one other person who fell into
>the same trap as I did.
>
The command 'query dbvol' shows whether or you you have mirrors
defined. Here is the output from the os/2 command line admin client
for my production system. I hope these examples will be useful to
someone in light of Martha's recent bad experience.
adsm> q dbvol
Volume Name Copy Volume Name Copy Volume Name Copy
(Copy 1) Status (Copy 2) Status (Copy 3) Status
---------------- ------ ---------------- ------ ---------------- ------
ADSM.PROD.DBA00 Sync'd ADSM.PROD.DBB00 Sync'd Undef-
ADSM.PROD.DBA00 Sync'd ADSM.PROD.DBB00 Sync'd Undef-
ined
ADSM.PROD.DBA01 Sync'd ADSM.PROD.DBB01 Sync'd Undef-
ined
ADSM.PROD.DBA02 Sync'd ADSM.PROD.DBB02 Sync'd Undef-
ined
ADSM.PROD.DBA03 Sync'd ADSM.PROD.DBB03 Sync'd Undef-
ined
ADSM.PROD.DBA04 Sync'd ADSM.PROD.DBB04 Sync'd Undef-
ined
ADSM.PROD.DBA05 Sync'd ADSM.PROD.DBB05 Sync'd Undef-
ined
ADSM.PROD.DBA06 Sync'd ADSM.PROD.DBB06 Sync'd Undef-
ined
ADSM.PROD.DBA07 Sync'd ADSM.PROD.DBB07 Sync'd Undef-
ined
And here is the 'query logvol' output.
adsm> q logvol
Volume Name Copy Volume Name Copy Volume Name Copy
(Copy 1) Status (Copy 2) Status (Copy 3) Status
---------------- ------ ---------------- ------ ---------------- ------
ADSM.PROD.RLA03 Sync'd ADSM.PROD.RLB03 Sync'd Undef-
ADSM.PROD.RLA03 Sync'd ADSM.PROD.RLB03 Sync'd Undef-
ined
ADSM.PROD.RLA02 Sync'd ADSM.PROD.RLB02 Sync'd Undef-
ined
And here is what the report looks like when no mirrors are defined.
This is from my test system.
adsm> q dbvol
Volume Name Copy Volume Name Copy Volume Name Copy
(Copy 1) Status (Copy 2) Status (Copy 3) Status
---------------- ------ ---------------- ------ ---------------- ------
ADSM.VN9A.DBA01 Sync'd Undef- Undef-
ADSM.VN9A.DBA01 Sync'd Undef- Undef-
ined ined
ADSM.VN9A.DBA00 Sync'd Undef- Undef-
ined ined
adsm>
>
>The problem, as I see it, is a information gap between the program directory
>and the Administration Guide. Neither is wrong, but some important information
>appears to get lost when going from one to the other. I think there should
>be more information in the Prog Dir about the DSMINIT exec and what questions
>it will ask. Perhaps a sample run based on the sample server definition
>given earlier. Not knowing what questions would be asked, I probably entered
>the mirror volume addresses at the wrong time and ended up with them being
>primary volumes instead. Also, the Prog Dir could mention the QUERY DBV
>and QUERY LOGV commands to verify that the volumes have been defined correctly.
>
>Some of this is explained in the Admin Guide. However, its later in the book
>and isn't near the sections you use when installing the product. Therefore,
>I think it would be very helpful to have them referenced in the Prog Dir
>as well. I can't find documentation on DSMINIT in either Admin books.
>
>Maybe its just me, but I found the installation of ADSM on VM very confusing.
>I think it was mainly due to so many new concepts coming all at once. I was
>"blown away" by all the different things that had to be customized and
>set properly. It took a long while for me to grasp it all. I'm still not
>too confident on some things, 1.5 years later. Perhaps I'm the only one
>who has found it confusing. If not, however, I think the authors of the Prog
>Dir should keep it in mind. Anything they can do to help us do a successful
>installation of the product will make us all happy in the long run.
>
>Anyway, that's the first part of my long, sad story. I'll save the rest
>for later. At least I'll have something to talk about at SCIDS (if the audit
>is done by then). %-)
>
>Martha
Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550
|
