Re: mksysb failure additional questions

From: Green, Simon (SGreen@KRAFTEUROPE.COM)
Date: Tue Sep 24 2002 - 11:05:58 EDT


You're worrying about nothing.

This _is_ telling you that some files which were present when the mksysb
started, and determined what to back up, had been deleted by the time the
mksysb got to them. It is common on any system that is not idle. It's
often print files, or temporary logs, so you find it for /tmp and /var
files. There should be messages - possibly in stderr, rather than stdout -
which tell you which specific files were not backed up.

The message...
31776 of 37047 files (85%)..........................
...is at 85%; just a progress message and does not indicate the end of the
backup. It doesn't produce another message on reaching 100%. 31776/37047 ~
0.85.

Some types of file cannot be backed up, and will cause mksysb to fail. This
includes some types used by databases. Also, you may not be able to restore
database files correctly from a mksysb/savevg. Always use the correct tool,
as recommended by the database supplier, for backup and recovery.

Backing up open files may produce inconsistent results. For simple flat
files this is not usually a problem: each individual file is backed up OK.
The problem comes when an application is updating two files concurrently.
The backup works sequentially so the files may be out of step, rendering
them useless to the application. This is particularly relevant for database
management systems, such as Oracle.

Simon Green
Philip Morris ITSC Europe

AIX-L Archive at http://marc.theaimsgroup.com/?l=aix-l&r=1&w=2
AIX FAQ at http://www.faqs.org/faqs/aix-faq/

N.B. Unsolicited email from vendors will seldom be appreciated.

> -----Original Message-----
> From: Dave.Zarnoch@SUNGARD.COM [mailto:Dave.Zarnoch@SUNGARD.COM]
> Sent: 24 September 2002 14:16
> To: aix-l@Princeton.EDU
> Subject: mksysb failure additional questions
>
>
> Del and Folks,
>
> Yes, I did check the archives and didn't see anything that
> was related.....
>
> The way I see it:
>
> There is a directory /opt/oracle that is 4GB
>
> 1 - If I exclude /opt/oracle, how confident are we that TSM
> backed up all
> the files?
>
> Here's an observation from an admin:
>
> It just means that some files were open, and whats on the tape may not
> match what was on the system. Unless you shutdown all
> applications, you
> will get this message. Shouldn't be a message.
>
> Could this mean that some Oracle files were open and not
> backed up by TSM
> as well?
>
> 2 - Another observation:
>
> Odds are it is files that were removed ( tmp files etc ) that
> were removed
> between time the list of files to be backed up was created
> and the files
> were actually being backed up.
>
> This doesn't seem likely given the difference in files:
>
> 31776 of 37047 files (85%)..........................
> 0512-003 mksysb may not have been able to archive some files.
> The messages displayed on the Standard Error contained additional
> information.
>
> 5271 files removed between creating the list and the actual backup?
>
> 3 - Block count is incorrect...
>
> Dunno, I'm set at 1024 which all my other mksysb are set at
>
> 4 - I think that we ran out of tape.....
> Unfortunately, the drive is a DDS2 which appears to only
> handle 4GB
> If this is true, and we decide to exclude
> /opt/oracle.....Refer to #1
> above
>
>
> Thanks!
>
> Dave Zarnoch
> UNIX Systems Engineer
> SunGard eSourcing
> 600 Laurel Oak Rd.
> Voorhees, NJ 08043
> Dave.Zarnoch@sungard.com
>
>
>
>
> Original email:
>
> Folks,
>
> We just started the initial mksysb of one of our servers
>
> We are using a DDS2 120m tape drive and tape
>
> Here's the filesystems in rootvg:
>
> Filesystem 1024-blocks Used Available Capacity Mounted on
> /dev/hd4 32768 9332 23436 29% /
> /dev/hd2 786432 529908 256524 68% /usr
> /dev/hd9var 458752 20772 437980 5% /var
> /dev/hd3 131072 13384 117688 11% /tmp
> /dev/hd1 32768 11916 20852 37% /home
> /dev/lv00 1015808 623692 392116 62% /scs
> /dev/lv01 14352384 3941976 10410408 28% /opt/oracle
>
> Oracle processing is up.
>
> Here's the end of the mksysb results:
>
> 21561 of 37047 files (58%)..............................
> 31776 of 37047 files (85%)..........................
> 0512-003 mksysb may not have been able to archive some files.
> The messages displayed on the Standard Error contained additional
> information.
>
> I researched and found that a DDS2 tape should handle:
>
> 4GB with no compression
>
> 8GB with compression
>
>
> According to SMIT, the tape drive is using compression
>
> Can this be as a result of a bogus compression configuration
> or that the
> Oracle
> databases were up during the mksysb?
>



This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 22:16:13 EDT