Fast Copy an instance

I know this is a silly question but I support a client remotely who is using 7.30 and I want to use HPL to export databases but they have created a monster with tables in multiple dbspaces and they didnt install any X software for the ipload. How can I populate the database manually and can I use the onpload with the correct flags to get the result seeing as how it overrides the settings anyway. Also onunload is intelligent enough to put indexes in other dbspaces why not the tables. I wrote a simple perl script to modify object ownership which works well but it still sticks all the tables in the same place and yet the indexes go where there supposed to. All I need to do is create a test system quickly same a the original but with different name and object ownership to match. I have exactly the same dbspaces for both just on a different file system ( yes they are using cooked files ). Lastly you can copy databases in oracle with a simple cp command and just by changing the control file bring it up as a different instance eg a copy of a production database to test when will we get the same functionality. Its so easy to snap up a clone and copy the file system in 10 minutes you have a new database fully populated as opposed to hours for dbimport/dbexport. Greg E

No the test system is on the same box under a different name

No chance of being able to restore an ontape archive, then? That's what I'm doing right now, restoring a production archive to my test system. Identical logical setup, no problems for 3 years now. John Carlson Informix DBA WHSmith USA Greg Elphick wrote: > > I know this is a silly question but I support a client remotely who is > using 7.30 > and I want to use HPL to export databases but they have created a > monster with tables in multiple dbspaces and they didnt install any X > software for the ipload. How can I populate the database manually and > can I use the onpload with the correct flags to get the result seeing as > how it overrides the settings anyway. > > Also onunload is intelligent enough to put indexes in other dbspaces why > not the tables. I wrote a simple perl script to modify object ownership > which works well but it still sticks all the tables in the same place and > yet > the indexes go where there supposed to. All I need to do is create a test > system quickly same a the original but with different name and object > ownership to match. I have exactly the same dbspaces for both just on a > different file system ( yes they are using cooked files ). > > Lastly you can copy databases in oracle with a simple cp command and > just by changing the control file bring it up as a different instance eg > a copy of a production database to test when will we get the same > functionality. Its so easy to snap up a clone and copy the file system > in 10 minutes you have a new database fully populated as opposed to > hours for dbimport/dbexport. > > Greg E

Greg Elphick wrote: [SNIP] > > Lastly you can copy databases in oracle with a simple cp command and > just by changing the control file bring it up as a different instance eg > a copy of a production database to test when will we get the same > functionality. Its so easy to snap up a clone and copy the file system > in 10 minutes you have a new database fully populated as opposed to > hours for dbimport/dbexport. Oh, don't get me started on THAT subject. Because then I'd have to point out that the d**ned Oracle instance only handles a single database, umm like Informix SE (16 year old technology), and does not keep track internally of its files, like Informix SE, and that like Informix SE it has so little intrinsic intelligence that you can fool it this way. I'd be tempted to rant about how Oracle is outdated technology with tons of new features plugged into it so it can do fragmented tables (pioneered by Informix IDS), parallel queries (pioneered by Informix IDS), and object data types and user defined data types (pioneered by Informix Universal Server). Sort of like attaching a coffee maker, warp drive unit and ion drive to a Volkswagon Beetle to create a starship with coffee service! But I'm not going to go there because I'm feeling charitable today. Really if this is the important feature you miss from Oracle, just downgrade to Informix SE. Art S. Kagel

"Art S. Kagel" <kagel@bloomberg.net> writes: > Greg Elphick wrote: > [SNIP] > > > > Lastly you can copy databases in oracle with a simple cp command and > > just by changing the control file bring it up as a different instance eg > > a copy of a production database to test when will we get the same > > functionality. Its so easy to snap up a clone and copy the file system > > in 10 minutes you have a new database fully populated as opposed to > > hours for dbimport/dbexport. > > Oh, don't get me started on THAT subject. Because then I'd have to point > out that the d**ned Oracle instance only handles a single database, umm > like Informix SE (16 year old technology), and does not keep track > internally of its files, like Informix SE, and that like Informix SE it > has so little intrinsic intelligence that you can fool it this way. I'd > be tempted to rant about how Oracle is outdated technology with tons of > new features plugged into it so it can do fragmented tables (pioneered by > Informix IDS), parallel queries (pioneered by Informix IDS), and object > data types and user defined data types (pioneered by Informix Universal > Server). Sort of like attaching a coffee maker, warp drive unit and ion > drive to a Volkswagon Beetle to create a starship with coffee service! > But I'm not going to go there because I'm feeling charitable today. > > Really if this is the important feature you miss from Oracle, just > downgrade to Informix SE. Shouldn't this be crossposted to c.d.o? I _do_ see the logic in Oracle on NT though... Thomas;)