Summary! In case someone else is fighting with the same problems I thought I'd share my conclusion with you.
I've decided not to resize the LUNS / file systems at all as Solaris 8 is quite restrictive with LUN resizing. I've overcome the need for resizing them with a bit of thinking. Given the variables (Sol8, EVA, VVM5, Oracle9i, Tape / EVA backups and most importantly, our needs) I've come to a conclusion that: 1. If we need more space for the growing data I'll just create another file systems to their own groups, for example DATA01 and DATA02 to data01dg and data02dg etc. Also for some reason distributing data / arch / redo files to separate file systems a bit improves the performance of our application. 2. With the practice mentioned above I only need to resize (shrink) a disk when the data doesn't grow anymore and this happens only once a year when the year is closed. I can do this by calculating the space needed for the data and creating a new file system for it, move the data on the new disk and destroy the old one. As simple as that. No need to fiddle with temporary disks and the one-lun-per-diskgroup is safe (no concat file systems). The only single point of failure is the SAN and with its three-level internal data protection the only reasonable threat is the complete destruction of it. Br, Jarkko -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Dunham Sent: lunes, 09 de abril de 2007 19:18 To: [EMAIL PROTECTED] Subject: Re: [Veritas-vx] resizing a device > Dangerous because I destroyed one file system because of this :)! Well, > with the help of Veritas support in Germany we were able to restore the > other part of the concat and thus restore the file system intact. > > Perhaps mixing the id's is a feature that occurs with EVA. When I move a > disk between servers the id doesn't necessarily stay the same. It depends on exactly which one we're disucssing, but the diskid used by VxVM is generated on the server and written to the disk as normal data. Unless the EVA is modifying disk data (it shouldn't), then the ID must stay the same as a LUN is migrated. If this isn't happening, then it's a serious bug. If you can reproduce this, I'd open a support case with Symantec about it. > Moreover > if I present a new disk to the server it might go over the id of the > "move disk". Sometimes this causes VVM to recognize the disk as "already > initialized" and at times it's even unable to put the disk to a new disk > group; it can only be used as a backup disk for some other disk. This > requires quite a lot of fiddling (offline, rm, online, scandisks and > whatnot) to get everything right. If the new LUN from the EVA doesn't clear the data, then you'll have to do that. That would be the same as re-using a physical disk. It still has the old VxVM signature, so it needs to be re-initialized. I can't see any reason that offline/scandisks should be necessary. (unless the problem with the diskids from earlier is involved). You're not doing any internal copying with the EVA are you? Just moves? Copying the LUN that holds the ID would make the ID non-unique. That could cause issues. > If I go on with the temp disk plan when resizing disks, any idea how big > the temp disk must be? At least privlen? Basically, yes. It needs to be initialized to have a private region that is sufficient to hold the entire diskgroup while the other LUN is offline. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > _______________________________________________ Veritas-vx maillist - [EMAIL PROTECTED] http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx __________________________________________________________________________ La informacion incluida en el presente correo electronico es CONFIDENCIAL, siendo para el uso exclusivo del/os destinatario/s arriba mencionado/s. Si usted recibe y lee este correo electronico y no es el destinatario senalado, el empleado o el agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicacion por error, le informamos que esta totalmente prohibida cualquier divulgacion, distribucion, uso o reproduccion del mismo, y le rogamos que nos lo notifique inmediatamente respondiendo al mensaje original a la direccion arriba mencionada y eliminando el mensaje a continuacion. The information contained in this e-mail is CONFIDENTIAL and is intended only for the use of the addressee named above.If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, or you have received this communication in error, please be aware that any diffusion, distribution or duplication of this communication is strictly forbidden, and please notify us immediately by return to the original message at the address above eliminating it afterwards. _______________________________________________ Veritas-vx maillist - [EMAIL PROTECTED] http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
