01-24-2008 10:17 AM
Solved! Go to Solution.
01-24-2008 10:33 AM
01-24-2008 12:45 PM
Since you didn't say what kind of database file:
I'd add that you can verify an Oracle database file with the Oracle command "dbv".
It's been an awfully long time, but I seem to remember that a command line tool exists for Informix as well.
01-24-2008 02:21 PM
Of course, before doing this, do an ls -l on each of the files. If the sizes differ the files must be different and the ls -l will be many orders of magnitude faster than a cksum.
The cp command will suffice for making identical copies of a file although identical may not actually be identical --- but the files will not be significantly different. Consider the case of a sparse original file. For example, suppose a 512-byte block of data is written at offset 0, then an lseek is done to offset 999512 and a second 512-byte block of data is written. This is a sparse file because the "missing" space is never actually allocated until actualk data are written. When a file with "holes" is read, those missing spots are silently and invisibly filled in with ASCII NUL's. When the original spare 1MB file is read via the cp command (or any other command), the destination file is filled with actual ASCII NUL's so that the "holes" are filled. In this case, the two files are fundamentally very different but yet perfectly equivalent and no utility (including the database or cksum) can distinguish them. With any luck, I have now throughly confused you.
01-24-2008 03:21 PM
If I can explain a little more about what A. Clay is referring to:
What A. Clay is referring to is Oracle TEMP files. These are database files of type "TEMP" (as opposed to files that merely just use as a temp destination). These are sparse data files, will do exectly what he is describing. Their size probably won't look right to you.
HOWEVER, it should be OK, because Oracle TEMP files don't travel well, and if you are copying a database to another or new location - they should be recreated from scratch (via a standard script) and not copied. You'll be able to bring the system up with those temp files, but you'll start having problems.
The point being, if you are moving Oracle data from system to system, you're going to have issues with sizing on files, but then again, there's not much point in moving temp files anyway, all the stuff in there is truly temp anyways, and the contents of files make no logical sense to another database instance in another state.
01-24-2008 03:26 PM
You essentially have the same question posted in:
Please take a minute to evaluate the responses therein, too. Thanks.
01-24-2008 07:13 PM
Would that be Oracle? MyQSL.
Copy within the same box? Over the network?
Is (time) consistency between files an issue?
>> What is the best way to make a database file a copy?
Define 'the best'. It depends!
Speed? Quality? Assists? Distance?
IMHO the best way is to tell mirroring hardware to split of a clone.
Think "Business Copy".
The next best way is to tell mirroring software to take a snapshot/clone.
But with a Wide area network incolved, the best way might be NOT to make a copy but to be able to re-create on the other side:
- script empty create
- export | comress | transfer | Decompress | import
- build index and/or analyze.
Finally... Don't underestimate the bandwidth of a stationwagon (ok, fedx box ;-) loaded with tapes.