It is currently Sat, 26 Nov 2022 05:18:43 GMT



 
Author Message
 Size difference when copying a large file in solaris
Hi, Im trying to take a database backup. one of the files is 26 GB. I
am using cp -pr to create a backup copy of the database. after the
copying is complete, if i do du -hrs on the folders i saw a difference
of 2GB.

The weird fact is that the BACKUP folder was 2 GB more than the
original one!

when i did du -hrs * inside each of the 2 folders and compared the
output, i found the culprit. it was a file temp.dbf which was 26 GB on
the source(original) folder and 28 GB in the BACKUP folder. I tried the
copy procedure twice and I am getting the same result.

does anyone have any explanation for this. please let me know. I want
to make sure everything is right here in the copy.

PS:- Solaris SPARC 32 BIT.

Thanks



 Thu, 20 Nov 2008 07:07:36 GMT   
 Size difference when copying a large file in solaris

Is that all? Well 1 byte is bad enough : <
Copying database files with cp. I'd use another tool like star.
Unless the db app has its own backup tools...
Then Id use them.

One way to find out is to test the results...
Im guessing that  temp.dbf  got some holes filled.
And is useless.

Ancient. Possibly.  So no OS version or platform or what database you
are
trying to "take".. Hard to assist here : >



 Thu, 20 Nov 2008 07:38:51 GMT   
 Size difference when copying a large file in solaris

Probably correct guess.

Why? What do you think "holes" are?

The back-up is probably just fine, but the only way to be really
sure is to restore from it and see whether it works.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.



 Thu, 20 Nov 2008 08:17:49 GMT   
 Size difference when copying a large file in solaris
I don't believe in the "holes" theory.  2GB of "holes" is way too many
"holes".  Perhaps the database was in use, so you would never get a true
bit-for-bit copy.  Since you are dealing with very large file, I am
hesitant to suggest you to try something... as it will take a long time
to accomplish.

(1) Run md5sum on the database file, then immediately run it one more
time.  If the 2 md5sum(s) are different, your database file changed
between the two runs.  That means you have to accept the fact that you
are not going to get true bit-for-bit copy.

(2) Shutdown the database, then repeat experiment (1).  The 2 md5sum(s)
should be the same.  If not, I don't know how to explain the difference.
  If they are the same, that means you should shutdown the database to
copy the database file.  However, there are better ways to backup the
database without shuting it down.  Are you using mysql?  Have you heard
of mysqldump or something equivalent for whatever database you are
using?  You can dump one database record at a time - with 26GB of data,
it's going to take a while...



 Thu, 20 Nov 2008 12:09:43 GMT   
 Size difference when copying a large file in solaris
In article <1149376056.707682.320...@i39g2000cwa.googlegroups.com>,

Database files have holes inside.

Use star -copy -sparse

--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
      j...@cs.tu-berlin.de                (uni)  
      schill...@fokus.fraunhofer.de       (work) Blog: http://schily.blogspot.com/
URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily



 Thu, 20 Nov 2008 18:53:58 GMT   
 Size difference when copying a large file in solaris

Not all. Oracle datafiles are pre-allocated.

--
Daniel



 Thu, 20 Nov 2008 21:26:21 GMT   
 Size difference when copying a large file in solaris
Are you sure the database is closed or datafiles in hot backup mode?

Also, you're clearly not a dba because if you were, you'd realise that
the below is probably the temp datafile for the temporary tablespace
(query dba_temp_files).  If it is you can just drop and recreate the
file when you restore.  Oracle's RMAN doesn't backup the temporay
datafiles during a full backup, so you needn't worry about it either.

To sum up, get your dba to backup the database.



 Fri, 21 Nov 2008 16:06:50 GMT   
 Size difference when copying a large file in solaris
Thanks.

Also,

It doesn't matter who the dba is. I know I can drop temp tablespace and
recreate it in the backup database. My question was regarding du not
showing proper sizes, and obviously was concerned with the 2 GB
difference. Anyways, I got it running way before you replied. But still
I want to thank you for the suggestion, despite the attitude you threw
at me.



 Sat, 22 Nov 2008 09:49:54 GMT   
 Size difference when copying a large file in solaris
In that case I look forward to reading what the actual problem was,
when you get round to posting it.


 Sat, 22 Nov 2008 18:01:31 GMT   
 Size difference when copying a large file in solaris

One or two would be better?

That may be true, but should not affect the size of the copy (unless the
source file is shrinking rather than just changing).

True, but has nothing to do with the size of the copy.  A DB file in hot
backup mode may be changing, but still be valid for recovery.

--
Darren Dunham                                           ddun...@taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >



 Sun, 23 Nov 2008 03:01:36 GMT   
 
   [ 10 post ] 

Similar Threads

1. Size difference when copying LARGE file

2. File size wrong, can't copy large file

3. Why the difference in block size after copy?

4. File size difference when nulling a file

5. Enable Large File Size in Aix file system

6. Difference between copy to and copy from nfs mounted disk

7. Large IO handling on Solaris and AIX difference?

8. cp/uncompress: difference file sizes when repeated

9. understanding GPG sig file size differences


 
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software