Path: news.easynews.com!easynews!hub1.nntpserver.com!telocity-west!TELOCITY!news-out.spamkiller.net!propagator2-maxim!propagator-maxim!news-in.spamkiller.net!news02.tsnz.net!newsfeed01.tsnz.net!newsfeeds.ihug.co.nz!lust.ihug.co.nz!ihug.co.nz!not-for-mail From: "Howard J. Rogers" Newsgroups: comp.databases.oracle.server Subject: Re: URGENT: Need to move TS from ufs to vxfs file system Date: Fri, 5 Apr 2002 13:56:08 +1000 Organization: ihug ( New Zealand ) Lines: 82 Message-ID: References: <3CACC182.BC16EA61@exesolutions.com> <%A3r8.52112$DE4.6755@afrodite.telenet-ops.be> NNTP-Posting-Host: p494-tnt8.syd.ihug.com.au X-Trace: lust.ihug.co.nz 1017979048 23729 203.173.148.240 (5 Apr 2002 03:57:28 GMT) X-Complaints-To: abuse@ihug.co.nz NNTP-Posting-Date: Fri, 5 Apr 2002 03:57:28 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xref: easynews comp.databases.oracle.server:142112 X-Received-Date: Thu, 04 Apr 2002 20:55:13 MST (news.easynews.com) As I said, it makes no difference how you did it, so long as you did it. It also shouldn't matter whether you copied or moved the file. As I hope you demonstrated by testing the procedure on the play tablespace. So that worked, but the real file doesn't. Mmmm. You're also correct that an Oracle block is an oracle block, so that shouldn't be it. The change in O/S block size could be an issue, since an Oracle block is really just a logical collection of O/S blocks: at the end of the day, it's what it gets physically stored at that's important, and that's the O/S block size. So long as the Oracle blocksize is a multiple of the O/S one, though, it shouldn't matter. And again, the fact that you performed the test successfully by transferring one file across and it working OK indicates that the problem probably lies elsewhere (otherwise the test wouldn't have worked either, would it?!). I suggested you should run dbv against the real file (db verify), to check for corruption. I ruled that out because I assumed you'd copied the file back, but since you point out that you didn't need to do that (because the original was still in situ after the first copy), I'd still suggest a quick dbv file=path_and_name_of_veritas_file blocksize=8192. The report is measured in "pages" (which just means Oracle blocks), and it gives us some assurance that the copy is clean. The only other thing I can think of right now is: how big is this file? Perhaps there are issues with filesizes on Veritas (I'm scraping the bottom of the barrell here, can you tell?) Let us know about dbv. Regards HJR -- ----------------------------------------------- Resources for Oracle : http://www.hjrdba.com =============================== "Larry" wrote in message news:a1238369.0204041910.2ee129e1@posting.google.com... > Howard et. al., > > Thanks for the feedback. > > 1. I mistyped my note. I ran this command: alter database rename > file 'xxxxx' to 'yyyyy'. > > 2. To "undo" what I did, I did NOT need to copy or move the file back > (at the OS level). It was still in the original location. But I did > use the alternate technique of taking the TS offline, and changing the > filename back that way so as to keep the instance online. Once done, > I could query the tables in that TS again. > > 3. I tested this TS relocation scenario with a play TS and a simple > three row table. It worked just fine when I copied the datafile to > the veritas file system. So I figured I was good to go with my real > TS. Only difference is that my real TS supports an Intermedia (CTX) > database. But isn't a database block just a database block, > regardless of what is in it? > > 4. My Oracle blocksize is 8192. UFS uses a blocksize of what, 512? > Veritas uses something different from ufs. But I've been told this > doesnt matter, since Oracle is concerned not about the file system > blocking, but the internal blocking. > > 5. Is it OK to COPY the datafile, as opposed to MOVE the datafile? > Is there any real difference. I mean, a unix cp command creates an > exact copy, right? > > 6. Oh yes. I did verify everything by checking the file names in the > v$datafile view. > > 7. File permissions. I checked. Both the original and the copied > datafiles have the same unix rwx permissions. Both are owned by the > oracle account. > > Any thoughts? > > Thanks to all, > Larry