Re: Making a copy of a database

Ian Goddard (igoddard@netcomuk.co.uk) wrote: : Reposting article removed by rogue canceller. : trubyn@aol.com wrote: : > : > Can anyone suggest a technique for copying an OnLine database to the : > same server? : > : > An archive attempts to restore to the dbspace - I don't know if this : > can be overridden. : > : > A tbunload/tbload is OK, but the copy database will have been re-blocked : > and defragmented, and therefore not an exact physical copy of the : > original. : Is this correct? It certainly applies to dbexport/import. As far as I : can recall (without finding tfm to r) tbunload/load requires the same : disk configuration. I would have assumed, then that, it is going to do a : byte by byte copy into those disks. Tbload/unload does not require the same disk configuration. It does a page by page copy, but does not retain the old extent layout, e.g. if your old table was broken into five extents of 16 pages each, the new one is not guaranteed (or even expected) to be laid out the same. : As Nils says, you can dd one disk to another but that takes time. If the : database is active the results will be inconsistent. You would need to : have the server quiescent or block off user access for the duration. : Another possibility is that you could mirror the chunks, wait for the : mirror to get up to date and then take the mirror down and use the chunks : for your new space. For safety you might still wish to have no access : when you take the mirror down, particularly if more than one chunk is : involved but it will be shorter than the time needed to do a dd. : There are problems with either a dd or the method I outlined. The root : dbspace holds housekeeping information naming the chunks which the : instance holds. Your new instance (I'm assuming you don't want to : duplicate the database into the same instance) will need a record of its : own chunks. You would need to fake this house keeping information in : some way in order to persuade the instance that the copied disks were : what it had set up. By "copying an OnLine database to the same server", do you mean copy the database to another database on the same OnLine instance, or copy the database to another OnLine instance on the same machine? Either way, it will be VERY difficult, if not impossible, and certainly not supported by Informix. Why does it need to be such an exact copy that tbunload is not acceptable? Note that dd'ing your disks will not work, because, as Ian has pointed out, the rootdbs contains the pathname of all your chunks, and there really isn't any way to "fake" this information to point to the copied disks. I can think of two (very unreliable and risky) ways in which you MIGHT be able to do this (do you think that's enough warnings ;-) , but they both depend on the original instance being set up in a certain way to begin with: 1. (This method actually would involve copying the entire instance, not just a specific database.) If you set up the original instance using all relative pathnames for your chunks (e.g. path is ./chunk rather than /dev/chunk), then you can take an archive, cd to a different directory (which contains links by the same names, but pointing to different disks) and restore it onto the same machine. This is NOT a good strategy for setting up two instances, because, among other things, you have to always be in the right directory when you start-up OnLine, and you run the risk of getting the two confused. 2. If you set up the original database so that it was created in specific dbspaces (not rootdbs), you might be able to set up a second instance, create the same dbspaces (on different disks), create a database by the same name in the same dbspace, and then dd the chunks from the original instance onto the chunks on the new instance. No guarantees, of course. For example: if your original instance was created with dbspace2 containing chunk2 and dbspace3 containing chunk3, and you did: create database stores in dbspace2; create table customer (fname ... )in dbspace3;Then create a second instance with dbspace2 containing chunk2 and dbspace3 containing chunk3, and: create database stores in dbspace2;Then if you dd chunks 2 and 3 from the original instance over the new chunks 2 and 3, you might be able to access the new stores database with all the tables in the same physical locations. Note that if you had other tables from other databases in chunk2 or chunk3, they come along for the ride, and introduce all sorts of lovely corruption into the new instance unless you repeat this exercise for all databases. June ---- June Tong Informix Software ---- ---- Senior Consultant (415) 926-6140 ---- ---- International Support junet@informix.com ---- ---- Location-du-jour: Menlo Park ---- * * Standard disclaimers apply * - Please do not send me requests/questions by mail. When I have the knowledge - and time permits, I try to answer questions on comp.databases.informix, but - travel schedule, time, and volume make responding to personal requests - difficult and often slow. Please call your local Informix Technical Support - organization for assistance with technical issues.