Hi Seema, I'll repurpose a message I sent to another list... I think it's relevant, let me know if it helps.
Approach 1) One approach that might work reasonably well is to set up prebuilt-table snapshots on the 8i instance based on the 7 tables. You would have to verify that this works, but I think it might. If it does, once the snapshots are set up, and refreshing every ten minutes or so, you could halt work on the 7 database, refresh one last time, drop all the snapshots on the 8i database, and cut over (switch IP addresses if necessary, etc.) The things that can often cause this approach to fail, however, are (1) version incompatibiliy; i.e. can't do snapshot replication from 7 to 8i, and (2) inadequate horsepower on the v7 machine to sustain both the snapshot log maintenance, the snapshot refresh work, and the regular workload. If you can work through those problems, however, you can cut downtime to under 15 minutes with this method. Approach 2) Import/Export, but with a twist or two. The fun thing about this approach is that it can be highly rehearsed and tuned ahead of time. An export is essentially a read of the database coupled with a write to disk. Then you'd normally have to copy that file over to the target server, and then you'd have to read it from disk and write it to the database. That's extremely inefficient and you'd want to avoid that. Instead, set up some named pipes on the fastest server (mkfifo on sun, mknod on tru64, if I remember correctly). Then, export from the source server into the named pipe (over sql*net). Then, import from the same named pipe into the target database. Presto! The network bandwidth, the read from the source db, and the write into the target db are all done simultaneously. Now, on to tuning this approach. This will require some trial and error. Begin by separating the data from the metadata (i.e. begin with a rows only export.) This will allow you to slam the data in just as fast as it comes out. Then, build an indexfile with the metadata export (rows=n), and massage it until you like it. Run it in a session with an absurdly large sort_area_size (3G is not out of the question, alter session set sort_area_size = 3000000000). The indexes should come out like popcorn. Finally, parallelize all of this so you're running three or more exports (to three different pipes of course), three imports, and finally three or more index builds simultaneously. Hand-tune these to go from and to different disks. With this approach, you could probably achieve downtime under 60 minutes. Both of these approaches would also benefit from a process of identifying tables that are essentially static or read-only, and moving those over ahead of time to cut them out of the final cutover. Hope this helps get the conversation going, remember to hire Pythian if you need help! Paul --- www.pythian.com -- [EMAIL PROTECTED] -- 877-PYTHIAN Smarter than adding another team member, Pythian has new services for supplementing DBAs: get our help with monitoring, 24x7 on-call, daily verifications, storage management, performance and more. ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Friday, March 01, 2002 3:48 PM Hi I want to switch from one server to another serevr with minimun down time of site.I am using export/import because removal of fragmentation. The folowing is my idea -export consistent=y on server1 -Ftp export files into serevr2 -Drop fragmenetd tablespace and recreate it -run import at schema level on server2(IMPORT is taking too much time) -Point the site to server2 But I am worry about those data which will loss during ftp time and import time.How to sync both server at particular time keeping in view with less down time of site. Can Incremental export/import help us to minimize the site down? Let me suggest please. -sEEMA _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Seema Singh INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Paul Vallee INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
