- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: copying .dbf files
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-17-2006 05:51 PM
тАО01-17-2006 05:51 PM
I'm trying to migrate some oracle filesystems from an sc10 to lvol on xp512. I'm seeing some unexpected behavior when I use the copy command. Note that the database is down at this time. The /nise3 filesystem is sitting on an SC10 and the /nise3_bak filesystem is sitting ldev from an xp512 array.
# cp -p -r /nise3/* /nise3_bak
nistdb2 /nise3/wfm>ll /nise3/wfm
total 6385968
-rw-r----- 1 oracle dba 52436992 Jan 17 22:19 cwmlite01.dbf
-rw-r----- 1 oracle dba 52436992 Jan 17 22:19 dysys01.dbf
-rw-r----- 1 oracle dba 52436992 Jan 17 22:19 example01.dbf
-rw-r----- 1 oracle dba 524296192 Jan 17 22:19 system01.dbf
-rw-r----- 1 oracle dba 524296192 Jan 17 22:19 temp01.dbf
-rw-r----- 1 oracle dba 3145736192 Apr 27 2005 temporary01.dbf
-rw-r----- 1 oracle dba 20979712 Jan 17 22:19 tools.dbf
-rw-r----- 1 oracle dba 20979712 Jan 17 22:19 users.dbf
nistdb2 /nise3/wfm>ll /nise3_bak/wfm
total 8581264
-rw-r----- 1 oracle dba 52436992 Jan 17 22:19 cwmlite01.dbf
-rw-r----- 1 oracle dba 52436992 Jan 17 22:19 dysys01.dbf
-rw-r----- 1 oracle dba 52436992 Jan 17 22:19 example01.dbf
-rw-r----- 1 oracle dba 524296192 Jan 17 22:19 system01.dbf
-rw-r----- 1 oracle dba 524296192 Jan 17 22:19 temp01.dbf
-rw-r----- 1 oracle dba 3145736192 Apr 27 2005 temporary01.dbf
-rw-r----- 1 oracle dba 20979712 Jan 17 22:19 tools.dbf
-rw-r----- 1 oracle dba 20979712 Jan 17 22:19 users.dbf
nistdb2 /nise3/wfm>du -ks /nise3/wfm/*
51208 /nise3/wfm/cwmlite01.dbf
51208 /nise3/wfm/dysys01.dbf
51208 /nise3/wfm/example01.dbf
512016 /nise3/wfm/system01.dbf
512016 /nise3/wfm/temp01.dbf
1974352 /nise3/wfm/temporary01.dbf
20488 /nise3/wfm/tools.dbf
20488 /nise3/wfm/users.dbf
nistdb2 /nise3/wfm>du -ks /nise3_bak/wfm/*
51208 /nise3_bak/wfm/cwmlite01.dbf
51208 /nise3_bak/wfm/dysys01.dbf
51208 /nise3_bak/wfm/example01.dbf
512008 /nise3_bak/wfm/system01.dbf
512008 /nise3_bak/wfm/temp01.dbf
3072016 /nise3_bak/wfm/temporary01.dbf
20488 /nise3_bak/wfm/tools.dbf
20488 /nise3_bak/wfm/users.dbf
nistdb2 /nise3/wfm>
I'M ALSO SEEING THIS BEHAVIOR ON ANOTHER FS THAT I'M TRYING TO COPY - NAMELY /nise19 to /nise19_bak.
nistdb2 />ll /nise19/dbfiles/lns
total 40960256
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP34.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP35.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP36.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP37.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP38.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP39.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP40.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP41.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP42.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP43.d
bf
-rw-r----- 1 oracle dba 2147491840 Nov 3 2003 dynidx33.dbf
-rw-r----- 1 oracle dba 2147491840 Nov 3 2003 dynidx34.dbf
-rw-r----- 1 oracle dba 2097160192 Nov 3 2003 staidx02.dbf
nistdb2 />ll /nise19_bak/dbfiles/lns
total 53444960
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP34.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP35.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP36.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP37.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP38.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP39.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP40.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP41.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP42.d
bf
-rw-r----- 1 oracle dba 2097160192 Dec 12 13:11 CITY_DATA_TBLSP43.d
bf
-rw-r----- 1 oracle dba 2147491840 Nov 3 2003 dynidx33.dbf
-rw-r----- 1 oracle dba 2147491840 Nov 3 2003 dynidx34.dbf
-rw-r----- 1 oracle dba 2097160192 Nov 3 2003 staidx02.dbf
nistdb2 />du -ks /nise19_bak/dbfiles/lns/*
2048016 /nise19_bak/dbfiles/lns/CITY_DATA_TBLSP34.dbf
2048016 /nise19_bak/dbfiles/lns/CITY_DATA_TBLSP35.dbf
2048016 /nise19_bak/dbfiles/lns/CITY_DATA_TBLSP36.dbf
2048008 /nise19_bak/dbfiles/lns/CITY_DATA_TBLSP37.dbf
2048008 /nise19_bak/dbfiles/lns/CITY_DATA_TBLSP38.dbf
2048016 /nise19_bak/dbfiles/lns/CITY_DATA_TBLSP39.dbf
2048016 /nise19_bak/dbfiles/lns/CITY_DATA_TBLSP40.dbf
2048008 /nise19_bak/dbfiles/lns/CITY_DATA_TBLSP41.dbf
2048008 /nise19_bak/dbfiles/lns/CITY_DATA_TBLSP42.dbf
2048016 /nise19_bak/dbfiles/lns/CITY_DATA_TBLSP43.dbf
2097168 /nise19_bak/dbfiles/lns/dynidx33.dbf
2097168 /nise19_bak/dbfiles/lns/dynidx34.dbf
2048016 /nise19_bak/dbfiles/lns/staidx02.dbf
nistdb2 />du -ks /nise19/dbfiles/lns/*
2048016 /nise19/dbfiles/lns/CITY_DATA_TBLSP34.dbf
2048016 /nise19/dbfiles/lns/CITY_DATA_TBLSP35.dbf
2048016 /nise19/dbfiles/lns/CITY_DATA_TBLSP36.dbf
2048008 /nise19/dbfiles/lns/CITY_DATA_TBLSP37.dbf
2048008 /nise19/dbfiles/lns/CITY_DATA_TBLSP38.dbf
2048008 /nise19/dbfiles/lns/CITY_DATA_TBLSP39.dbf
2048008 /nise19/dbfiles/lns/CITY_DATA_TBLSP40.dbf
2048008 /nise19/dbfiles/lns/CITY_DATA_TBLSP41.dbf
2048008 /nise19/dbfiles/lns/CITY_DATA_TBLSP42.dbf
2048008 /nise19/dbfiles/lns/CITY_DATA_TBLSP43.dbf
8 /nise19/dbfiles/lns/dynidx33.dbf
8 /nise19/dbfiles/lns/dynidx34.dbf
8 /nise19/dbfiles/lns/staidx02.dbf
nistdb2 />
DOES SOMEONE KNOW WHY THE LONG LISTING SHOWS THE SAME FILE SIZE - BUT WHEN I DO A "DU" I SEE A HUGE DIFFERENCE BETWEEN THE SIZE OF THE /nise3/wfm/temporary01.dbf and /nise3_bak/wfm/temporary01.dbf files?????
AM I DOING SOMETHING WRONG? I'M NOT A DBA, BUT JUST TRYING TO RECREATE THE FILESYSTEMS ON A SEPARATE SET OF DEVICES.
ANY IMPUT WILL BE GREATLY APPRECIATED!
THANKS!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-17-2006 06:08 PM
тАО01-17-2006 06:08 PM
Re: copying .dbf files
if your question is why du size is different from list directory size, refer to this kb:
http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000080063060
regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-17-2006 06:50 PM
тАО01-17-2006 06:50 PM
Re: copying .dbf files
i think the above replies clarifies everything. However, on top of that verification when copying the files, i would also check the datafile size invidually. A bit of paranoia wont harm when dealing with such critical manipulations.
Dont forget to do a full backup before everything...
hope this helps too!
kind regards
yogeeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-17-2006 08:08 PM
тАО01-17-2006 08:08 PM
Re: copying .dbf files
HI,
The du command gives the number of 512-byte blocks and ll gives size in bytes.
With Regards,
SIva
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-18-2006 02:28 AM
тАО01-18-2006 02:28 AM
Re: copying .dbf files
I was using "du -ks" command with the "-k".
So I guess 2 remaining questions: Is it OK to use the "cp -p -r" command when copying over the *.dbf files given that the Database is down? Does the DBA need to do any manipulations after the filesystem move given that the mountpoints remain the same? Namely the mountpoints on the new devices will be the same as for the old. The old ones will be unmounted of course.
Thanks Again!
Vanja
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-18-2006 02:35 AM
тАО01-18-2006 02:35 AM
SolutionPatti
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-18-2006 05:05 AM
тАО01-18-2006 05:05 AM
Re: copying .dbf files
Before copying the database to a new location, it is necessary to perform
a full cold backup of the database, whilst the database is shutdown.
In order to move the database, it is necessary to create a script containing information about the files of the database. Issue a 'ALTER DATABASE BACKUP CONTROLFILE TO TRACE RESETLOGS;'
so that this will create a trace file in the trace file directory.
Copy all parameter files, controlfiles, and all files to their new location taking care to preserve ownership and permissions.
In order to establish the new database in the new location, the CREATE CONTROLFILE command.
Simon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-18-2006 05:42 AM
тАО01-18-2006 05:42 AM
Re: copying .dbf files
Of course you know that the database must be down for this to work. No alternative.
You should not be seeing temporary files.
Before doing this, take a tape backup in case the data gets corrupted.
Good Luck,
SEP
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-18-2006 07:35 AM
тАО01-18-2006 07:35 AM
Re: copying .dbf files
After you copy all the data to the new mounts on the XP, just unmount the SC10 file systems and remount the XP's as the SC10 names.
The original DBF files will still be there on the SC10 if there are any problems. Just unmount the XP and remount the SC10 to be right back where you started.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-18-2006 08:23 AM
тАО01-18-2006 08:23 AM
Re: copying .dbf files
Try this test, go into oracle and create a new 2G datafile for a TEMP tablspace. The go out to your Unix shell, and do the same, an "ll" and a "du" and compare the difference. It will be huge. This is normal for TEMPORARY data files, until the database decides to actually use all of those extents in the datafile, it will remain 'smaller' than it appears, for lack of a better description.
Doesn't matter, when you move temp tablespace files, you really should RECREATE all temporary tablespace files from scratch, in order to avoid problems later on (during a production day for example). This should be done as a matter of course, as it is quite simple and painless.