RE: Clarfication on reorg of critical dbspace...

Posted in 2003

Rajasekaran, Rajesh — Wed, 30 Jul 2003 15:10:31 -0500 — source: Usenet: comp.databases.informix

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C356D6.A0C34E10 Content-Type: text/plain; charset="iso-8859-1" Hi, Thanks. But u know what our layout will still have one more issue with this. Since we use offsets in our chunk distribution, like the sample layout explained below /informix/PRD/sapdata/physdev1/data1 --:> /dev/vx/rdsk/sapdg1/infdbv001 -- > rootdbs of size 100 MB (different offset) /informix/PRD/sapdata/physdev1/data1 --:> /dev/vx/rdsk/sapdg1/infdbv001 -- > datadbs of size 1.5 GB (another offset) Even if i restore to a different physical location, the new INFDBV volume does have the datadbs data due to a single volume distributed across multiple chunks. The new volume which will be having is on RAID1 and out datadbs will be on RAID 5. We are trying to upgrade our storage and the whole box. Iam defining all the Informix volumes on the new storage array with RAID5 layout for our DB data. But for the critical dbspace, iam created the Informix volumes on the internal disks and not on the storage array with RAID1 layout. With this in mind, I have a question regarding the DB Mirroring option to resolve the issue. Once i restore the data (everything will go to new array), i define DB mirroring for critical dbspaces to another location say RAID1 disks. After mirroring is done, if i reassign my mirror path as primary path and take out mirror path in the onconfig, Will that work without any issues ? Does the system catalog still contain the old primary path somewhere ? Thanks Rajesh Rajasekaran Informix Database Administrator Forest Pharmaceuticals Inc. (314) 493-7073 rrajasekaran@forestpharm.com -----Original Message----- From: briceavila@hotmail.com [mailto:briceavila@hotmail.com] Sent: Wednesday, July 30, 2003 1:40 PM To: informix-list@iiug.org Subject: Re: Clarfication on reorg of critical dbspace... How about restoring the rootdbs to a different location? Another thought: mirror the rootdbs, and then break the mirror. I don't like this suggestion so much as it makes the old original references dangling out in the ether forever. Hope these suggestions help. Brice Avila Minneapolis, Minnesota "Rajasekaran, Rajesh" <RRajasekaran@forestpharm.com> wrote in message news:<bg8jq6$qod$1@terabinaries.xmission.com>... > This message is in MIME format. Since your mail reader does not understand > this format, some or all of this message may not be legible. > > ------_=_NextPart_001_01C3569F.0B53DCA0 > Content-Type: text/plain; > charset="iso-8859-1" > > Hello all, > > I have this requirement of moving the critical dbspace's data onto a > different physical device. I know the reorg. can be done for physdbs and > logdbs. Is there any way to reorg the Rootdbs ? Does Informix allow the > admin user to perform the reorg of rootdbs like any other dbspace ? > > Any suggestions are greatly appreciated. > > Rajesh Rajasekaran > Informix Database Administrator > Forest Pharmaceuticals Inc. > (314) 493-7073 > rrajasekaran@forestpharm.com > <SNIP> ------_=_NextPart_001_01C356D6.A0C34E10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2653.12"> <TITLE>RE: Clarfication on reorg of critical dbspace...</TITLE> </HEAD> <BODY> Hi,     Thanks. But u know what our layout will still have = one more issue with this. Since we use offsets in our chunk distribution, like = the sample layout explained below /informix/PRD/sapdata/physdev1/data1 --:> = /dev/vx/rdsk/sapdg1/infdbv001 -- > rootdbs  of size 100 MB = (different offset)  /informix/PRD/sapdata/physdev1/data1 --:> = /dev/vx/rdsk/sapdg1/infdbv001 -- > datadbs  of size  1.5 = GB (another offset) Even if i restore to a different physical location, = the new INFDBV volume does have the datadbs data due to a single volume = distributed across multiple chunks. The new volume which will be having = is on RAID1 and out datadbs will be on RAID 5. We are trying to upgrade our storage and the whole = box. Iam defining all the Informix volumes on the new storage array = with RAID5 layout for our DB data. But for the critical dbspace, iam = created the Informix volumes on the internal disks and not on the = storage array with RAID1 layout. With this in mind,  I have a = question regarding the DB Mirroring option to resolve the = issue. Once i restore the data (everything will go to new = array), i define DB mirroring for critical dbspaces to another location = say RAID1 disks. After mirroring is done, if i reassign my mirror path = as primary path and take out mirror path  in the onconfig, Will = that work without any issues ? Does the system catalog still contain = the old primary path somewhere ? Thanks Rajesh Rajasekaran Informix Database Administrator Forest Pharmaceuticals Inc. (314) 493-7073 rrajasekaran@forestpharm.com -----Original Message----- From: briceavila@hotmail.com [<A = HREF=3D"mailto:briceavila@hotmail.com">mailto:briceavila@hotmail.com</A>= ] Sent: Wednesday, July 30, 2003 1:40 PM To: informix-list@iiug.org Subject: Re: Clarfication on reorg of critical = dbspace... How about restoring the rootdbs to a different = location? Another thought: mirror the rootdbs, and then break = the mirror. I don't like this suggestion so much as it makes the = old original references dangling out in the ether forever. Hope these suggestions help. Brice Avila Minneapolis, Minnesota "Rajasekaran, Rajesh" = <RRajasekaran@forestpharm.com> wrote in message = news:<bg8jq6$qod$1@terabinaries.xmission.com>... > This message is in MIME format. Since your mail = reader does not understand > this format, some or all of this message ma

RE: Clarfication on reorg of critical dbspace...

Related threads

Your privacy choices