Ryan, Oracle can certainly transport more than one datafile at a time. I'm not sure what you mean by "the datafiles need to be 'atomic' to be transported", but it is certainly a limitation of the application logic, not Oracle. You could transport every single PERMANENT tablespace in a database (except SYSTEM) in a single TTS operation, regardless of how many datafiles were involved in each tablespace or in the database. Perhaps the person working on the application has gotten off on the wrong foot and needs to add some real-world considerations to it?
With regards to datafile sizes, just because you can create ultra-large datafiles doesn't mean you should. Doing so means letting yourself in for some really painful downstream after-effects, I think. My personal preference is a max datafile size of 2G, 4G, or 8G regardless of 32-bit, 64-bit, or large files capabilities. YMMV... For reasons why, think about it from the backup/restore perspective. Which database can be backed up or restored faster: one with 100 2Gb datafiles or one with 2 100Gb datafiles? Datafile management is just like extent management. As Roger Waters said, "All in all, they're all just bricks in the wall"... :-) Just my $0.02... -Tim > One of the guys here did some research and found that > files over 32GB can cause data dictionary corruption. > anyone have problems with this? we are using an automated > transportable tablespace process with alot of logic and > between many instances and servers. > we would prefer not to complicate the logic by having to > introduce additional tablespaces to transport(cant do > multiple datafiles in one tablespace because the datafiles > need to be atomic to be transported). > so anyone use datafiles larger than 32GBs. What happened? > I know most of you dont, but we are in a unique situation. > > -- > Please see the official ORACLE-L FAQ: > http://www.orafaq.net -- > Author: <[EMAIL PROTECTED] > INET: [EMAIL PROTECTED] > > Fat City Network Services -- 858-538-5051 > http://www.fatcity.com San Diego, California -- > Mailing list and web hosting services > ---------------------------------------------------------- > ----------- 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.net -- Author: Tim Gorman INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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).
