What is quickest way to create a copy of a databas

We have a need to create a copy of a database as quickly as possible. This database copy would be used for month end reporting needs, so would need to be created monthly - but would need to be available within a few hours of when we do the cut off. We cannot use a replication server because of budget constraints. Backups/restores would take 15-20 hours. We have tried using the unix "dd" command to create a bit copy of our database and have been able to copy about 200Gb in 2 hours. The problem is, when we brint the new database up, an onstat shows that the engine thinks it is still pointing the to links for the drives for the original instance, even though we have configured the new instance to use different links. Does anyone have a way to update the shared memory to correct this? Is it possible? Does anyone have another way to do this? We are running hpux 11.0 IDS 7.31

Anthony, The whole idea behind 'links' is that you can direct them to different devices. You just need to have your links point to the devices that you did the 'dd' to. Make sure your $ONCONFIG, $INFORMIXDIR/etc/sqlhosts, /etc/services, etc. are correct for the backup DB. GOOD LUCK!!!!! -----Original Message----- From: ANTHONY JUDISH [mailto:ajudish@lextron-inc.com] Sent: Thursday, January 22, 2004 4:32 PM To: ids@iiug.org Subject: What is quickest way to create a copy of a databas [2474] We have a need to create a copy of a database as quickly as possible. This database copy would be used for month end reporting needs, so would need to be created monthly - but would need to be available within a few hours of when we do the cut off. We cannot use a replication server because of budget constraints. Backups/restores would take 15-20 hours. We have tried using the unix "dd" command to create a bit copy of our database and have been able to copy about 200Gb in 2 hours. The problem is, when we brint the new database up, an onstat shows that the engine thinks it is still pointing the to links for the drives for the original instance, even though we have configured the new instance to use different links. Does anyone have a way to update the shared memory to correct this? Is it possible? Does anyone have another way to do this? We are running hpux 11.0 IDS 7.31 Please do not transmit orders or instructions regarding a UBS account by email. The information provided in this email or any attachments is not an official transaction confirmation or account statement. For your protection, do not include account numbers, Social Security numbers, credit card numbers, passwords or other non-public information in your email. Because the information contained in this message may be privileged, confidential, proprietary or otherwise protected from disclosure, please notify us immediately by replying to this message and deleting it from your computer if you have received this communication in error. Thank you. UBS Financial Services Inc. UBS International Inc.

ANTHONY JUDISH wrote > We have a need to create a copy of a database as quickly as > possible. This database copy would be used for month end > reporting needs, so would need to be created monthly - but > would need to be available within a few hours of when we do > the cut off. We cannot use a replication server because of > budget constraints. Backups/restores would take 15-20 hours. > We have tried using the unix "dd" command to create a bit > copy of our database and have been able to copy about 200Gb > in 2 hours. The problem is, when we brint the new database > up, an onstat shows that the engine thinks it is still > pointing the to links for the drives for the original > instance, even though we have configured the new instance to > use different links. > Does anyone have a way to update the shared memory to correct > this? Is it possible? > Does anyone have another way to do this? > > We are running hpux 11.0 > IDS 7.31 > If you can manage to get all your data in dbspaces other than root, you could have a duplicate root dbspace that points to your dd'd chunks. Your databases would all have to be created in these chunks as well as all data and indexes. Never tried it of course :-) Colin Bull c.bull@videonetworks.com

Anthony I assume you were considering HDR which needs to be run between independant, but almost identical, machines. Have you considered Enterprise Replication which can be run between two Database Servers on the same machine. This has the advantage over "dd" of being totally up to date all the time, fully automatic and you only need to replicate the specific tables in which you are interested. Keith -> -----Original Message----- -> From: ANTHONY JUDISH [mailto:ajudish@lextron-inc.com] -> Sent: Thursday, January 22, 2004 9:32 PM -> To: ids@iiug.org -> Subject: What is quickest way to create a copy of a databas [2474] -> -> -> We have a need to create a copy of a database as quickly as -> possible. This database copy would be used for month end -> reporting needs, so would need to be created monthly - but -> would need to be available within a few hours of when we do -> the cut off. We cannot use a replication server because of -> budget constraints. Backups/restores would take 15-20 hours. -> We have tried using the unix "dd" command to create a bit -> copy of our database and have been able to copy about 200Gb -> in 2 hours. The problem is, when we brint the new database -> up, an onstat shows that the engine thinks it is still -> pointing the to links for the drives for the original -> instance, even though we have configured the new instance to -> use different links. -> Does anyone have a way to update the shared memory to -> correct this? Is it possible? -> Does anyone have another way to do this? -> -> We are running hpux 11.0 -> IDS 7.31 -> ******************************************************************************** ** This message is sent in strict confidence for the addressee only. It may contain legally privileged information. The contents are not to be disclosed to anyone other than the addressee. Unauthorised recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission. This footnote also confirms that this email message has been swept for the presence of computer viruses, however we cannot guarantee that this message is free from such problems. ******************************************************************************** **

Make a restore using the tape of the day before the cut. Wait at the prompt "Restore logical logs" until the cut and then you only have to restore the logs.... You can also use a level 1 backup to get your restore upto date. rgds /Arthur ----- Original Message ----- From: "ANTHONY JUDISH" <ajudish@lextron-inc.com> To: <ids@iiug.org> Sent: Thursday, January 22, 2004 10:32 PM Subject: What is quickest way to create a copy of a databas [2474] > We have a need to create a copy of a database as quickly as possible. This database copy would be used for month end reporting needs, so would need to be created monthly - but would need to be available within a few hours of when we do the cut off. We cannot use a replication server because of budget constraints. Backups/restores would take 15-20 hours. > We have tried using the unix "dd" command to create a bit copy of our database and have been able to copy about 200Gb in 2 hours. The problem is, when we brint the new database up, an onstat shows that the engine thinks it is still pointing the to links for the drives for the original instance, even though we have configured the new instance to use different links. > Does anyone have a way to update the shared memory to correct this? Is it possible? > Does anyone have another way to do this? > > We are running hpux 11.0 > IDS 7.31 > >

ANTHONY JUDISH <ajudish@lextron-inc.com> wrote:We have a need to create a copy of a database as quickly as possible. This database copy would be used for month end reporting needs, so would need to be created monthly - but would need to be available within a few hours of when we do the cut off. We cannot use a replication server because of budget constraints. Backups/restores would take 15-20 hours. We have tried using the unix "dd" command to create a bit copy of our database and have been able to copy about 200Gb in 2 hours. The problem is, when we brint the new database up, an onstat shows that the engine thinks it is still pointing the to links for the drives for the original instance, even though we have configured the new instance to use different links. Does anyone have a way to update the shared memory to correct this? Is it possible? Does anyone have another way to do this? We are running hpux 11.0 IDS 7.31 --- Anthony, My understanding is that when you use dd the links path must remain the same, reason being that the dbspace definition is maintained in the reserve pages. If you use dd on a storage array and then point a new instance on a seperate machine to the copyed data, using the same device paths in the new instance, then you could make this method work. Pesonally I use a process that copies mutiple tables at a time with no logging (RAW target tables), no indexes or constraints and exclusive locks (on the souce tables). This process allows me to copy and rebuild our databases rather quickly. Another option that might be a viable solution is to use HPL. It is cumbersome to set up but once you have it set up it works great. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/

Hi bro, i'll tell you about our experience ids 9.40 linux on intel DB size, about 100 GB (half of yours) we backup our DB to disk daily (before sending to tape) by means of ontape + gzip. no downtime at all. backup time: less than 3 hours not pretty often, we have to restore the DB. restore time: LESS THAN 40 MINUTES believe it or not. the restores take place in a spare server. do the math. Be carefull not to screw up your source DB when changing links. seems pretty dangerous. Links work great, but may become a nigthmare. AFAIK the data paths are hardcoded within rootdbs an there's NO way it can be changed unless you export & import your DB. If you're gonna restore your DB, must keep the original layout of your source DB. Hope it helps