Dwight..
I could surely be wrong, but I thought that DIRMC pointing to a disk
pool helped in the way you describe below, in some older version or
release levels (don't know which, but I'm thinking v1) but that the way
ADSM does tape processing in v2 or some level of v2, it makes DIRMC not
so valuable anymore. So I've been taking DIRMC back off our clients.
I thought I got this from a conversation with Andy at IBM... Andy, am
I all washed up?
Thanks,
Julie
JPHINNEY AT HUMANA DOT COM
Dwight E. Cook wrote:
>
> Item Subject: 1.txt "internet headers"
> Could not convert BINARY FILE item to text.
> Will attempt to 'shar' item as file '03h802f' at end of msg.
>
> .......................................................................
>
> Item Subject: Why is the same tape mounted several times during a restore?
> OK, double check in the installing the clients manual for the platform
> of the clients suffering this to get all the specifics... but the
> directory information (some or all) is I bet what is doing it to you.
> On our novell servers we saw such things... our cure was to create a
> diskpool that never went to tape, pointed a special management class
> to it then our novell folks use :
> incremental -subdir=yes -pass=xxxx -dirmc=thatspecialmc
> this way all the directory poop was always available online (on disk)
> but it is something with how/when it gathers directory information and
> the order in which restores take place.
> I believe when this was first an issue here we were seeing 1 tape
> mounted in excess of 25 times... there are other cures... longer mount
> retention times in conjunction with more tape drives...
> hope this helps..
> later
> Dwight
>
> ______________________________ Reply Separator
> _________________________________
> Subject: Why is the same tape mounted several times during a restor
> Author: ADSM-L (ADSM-L AT VM.MARIST DOT EDU) at unix,sh
> Date: 11/20/97 4:35 AM
>
> I just performed a restore for a client that deleted a marketing directory
> that
> had 84 sub-directories beneath it. There were a total of about 1200 files (2
> GB). Unfortunately they did not tell me until after the next incremental was
> run
> so that all of the deleted directories and files were marked inactive. I used
> a
> line command to restore the data and learned first hand the value of Version
> 3's
> point-in-time restore when ADSM also restored all of the files that the client
> had deleted over the past 60 days. (approximately 800 files, 1 GB)
> restore d:\inet\www\marketing\* -subdir=yes -latest
> I do not use collocation so the data for the client was spread across 38
> volumes. If this wasn't bad enough it mounted 17 of the tapes twice for a
> total
> of 55 mounts. Why isn't ADSM smart enough to restore all of the files needed
> from each tape the first time it's mounted? It looks like ADSM called for the
> tapes in volume sequence except in the case of the re-mounted volumes:
> AB0005
> AB0009
> AB0013
> AB0009 <- Second mount
> AB0013 <- Second mount
> AB0029
> Etc.
>
> If this wasn't already enough fun, during my first attempt to do the restore
> after about 40 tapes the session timed out because it was waiting for a reply
> that I failed to answer quick enough. (15 minute default).
>
> So I started the restore again thinking that it would pick up where it left
> off.
> restore d:\inet\www\marketing\* -subdir=yes -latest -replace=no
> I was surprised and disappointed that ADSM called for all of the same tapes
> again, all forty before it got to the point where it began restoring data
> again.
> During the first forty tapes it gave be a "Skipping" message for all of the
> files that it restore during the first attempt.
> When ADSM builds the list of files that need to be restored, why does it try
> to
> restore the files that already exist? With -replace=no couldn't it compare the
> list of files that the database knows about to the hard drive and determine
> that
> there is no need to mount the tape and attempt the restore?
>
> I plan on ordering Version 3 for AIX this week. Hopefully my restores will go
> smoother in the future.
>
> Larry Robertson
> Compuware Corporation
> larry_robertson AT compuware DOT com
>
> # This is a shell archive. Remove anything before this line,
> # then unpack it by saving it in a file and typing "sh file".
> #
> # Wrapped by Openmail for HP9000 <openmail@tuleosm1> on Thu Nov 20 13:08:39
> 1997
> #
> # This archive contains:
> # 03h802f
> #
> # Error checking via wc(1) will be performed.
>
> LANG=""; export LANG
> PATH=/bin:/usr/bin:$PATH; export PATH
>
> rm -f /tmp/uud$$
> (echo "begin 666 /tmp/uud$$\n#;VL*n#6%@x\n \nend" | uudecode) >/dev/null 2>&1
> if [ X"`cat /tmp/uud$$ 2>&1`" = Xok ]
> then
> unpacker=uudecode
> else
> echo Compiling unpacker for non-ascii files
> pwd=`pwd`; cd /tmp
> cat >unpack$$.c <<'EOF'
> #include <stdio.h>
> #define C (*p++ - ' ' & 077)
> main()
> {
> int n;
> char buf[128], *p, a,b;
>
> scanf("begin %o ", &n);
> gets(buf);
>
> if (freopen(buf, "w", stdout) == NULL) {
> perror(buf);
> exit(1);
> }
>
> while (gets(p=buf) && (n=C)) {
> while (n>0) {
> a = C;
> if (n-- > 0) putchar(a << 2 | (b=C) >> 4);
> if (n-- > 0) putchar(b << 4 | (a=C) >> 2);
> if (n-- > 0) putchar(a << 6 | C);
> }
> }
> exit(0);
> }
> EOF
> cc -o unpack$$ unpack$$.c
> rm unpack$$.c
> cd $pwd
> unpacker=/tmp/unpack$$
> fi
> rm -f /tmp/uud$$
>
> echo x - 03h802f '[non-ascii]'
> $unpacker <<'@eof'
>
> Name: 03h802f
> Part 1.2 Type: unspecified type (application/octet-stream)
> Encoding: x-uuencode
>
> @eof
> set `wc -lwc <03h802f`
> if test $1$2$3 != 292311856
> then
> echo ERROR: wc results of 03h802f are $* should be 29 231 1856
> fi
>
> chmod 660 03h802f
>
> rm -f /tmp/unpack$$
> exit 0
|
