Re: [Veritas-bu] Fun with EMM internals
And I don't doubt Symantec is doing weird things with their version of the database too. But on the other hand, their "blank NBDB creation script" at /usr/openv/db/bin/create_nbdb is not a binary, so there's no reason you can't go through and look at every step they take to crush a fresh database into their own mold. I just don't know enough database stuff to understand everything it's doing. =) - John Nardello -Original Message- From: Jeff Lightner [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2008 6:06 AM To: Michael Graff Andersen; Nardello, John Cc: Veritas-bu@mailman.eng.auburn.edu Subject: RE: [Veritas-bu] Fun with EMM internals Once upon a time I worked on Andersen Consulting's Foundation CASE software that used Informix for its repository. Whenever that DB flaked out I had to use a mixed bag of Informix and AC steps to recreate the DB. Simply recreating the schema and reloading dumped data never worked which let me know they were doing something proprietary in their setup steps. Probably same for NBU and Sybase. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Graff Andersen Sent: Wednesday, July 09, 2008 6:01 AM To: Nardello, John Cc: Veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Fun with EMM internals Yes because it is actually a Symantec OEM database & not a real free ASA database according to the consulant we had out from Symantec Regards Michael 2008/7/9, Nardello, John <[EMAIL PROTECTED]>: > Has anyone had the time to look around at the various binaries included > with the internal ASA database in /usr/openv/db/bin ? In particular, > I've been playing with dbunload and was wondering if there's anyone who > knows something about ASA or Sybase who could explain why it dumps what > look like a perfectly good reload.sql command file and associated files > for the tables, but then refuses to reimport them into a clean EMM > database (without erroring out. > > Lots of "Primary key for table 'EMM_AllocationStatus' is not unique" and > such errors. > > And yes, I know support would laugh themselves silly if I tried calling > this in. > > Just thought I'd see if anyone else is out there causing trouble and had > any ideas. =) > > - John Nardello > [ Obligatory CYA - No, I did NOT tell you to go play with those commands > on your production NetBackup server. ] > > > ___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Fun with EMM internals
Once upon a time I worked on Andersen Consulting's Foundation CASE software that used Informix for its repository. Whenever that DB flaked out I had to use a mixed bag of Informix and AC steps to recreate the DB. Simply recreating the schema and reloading dumped data never worked which let me know they were doing something proprietary in their setup steps. Probably same for NBU and Sybase. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Graff Andersen Sent: Wednesday, July 09, 2008 6:01 AM To: Nardello, John Cc: Veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Fun with EMM internals Yes because it is actually a Symantec OEM database & not a real free ASA database according to the consulant we had out from Symantec Regards Michael 2008/7/9, Nardello, John <[EMAIL PROTECTED]>: > Has anyone had the time to look around at the various binaries included > with the internal ASA database in /usr/openv/db/bin ? In particular, > I've been playing with dbunload and was wondering if there's anyone who > knows something about ASA or Sybase who could explain why it dumps what > look like a perfectly good reload.sql command file and associated files > for the tables, but then refuses to reimport them into a clean EMM > database (without erroring out. > > Lots of "Primary key for table 'EMM_AllocationStatus' is not unique" and > such errors. > > And yes, I know support would laugh themselves silly if I tried calling > this in. > > Just thought I'd see if anyone else is out there causing trouble and had > any ideas. =) > > - John Nardello > [ Obligatory CYA - No, I did NOT tell you to go play with those commands > on your production NetBackup server. ] > > > ___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Fun with EMM internals
Yes because it is actually a Symantec OEM database & not a real free ASA database according to the consulant we had out from Symantec Regards Michael 2008/7/9, Nardello, John <[EMAIL PROTECTED]>: > Has anyone had the time to look around at the various binaries included > with the internal ASA database in /usr/openv/db/bin ? In particular, > I've been playing with dbunload and was wondering if there's anyone who > knows something about ASA or Sybase who could explain why it dumps what > look like a perfectly good reload.sql command file and associated files > for the tables, but then refuses to reimport them into a clean EMM > database (without erroring out. > > Lots of "Primary key for table 'EMM_AllocationStatus' is not unique" and > such errors. > > And yes, I know support would laugh themselves silly if I tried calling > this in. > > Just thought I'd see if anyone else is out there causing trouble and had > any ideas. =) > > - John Nardello > [ Obligatory CYA - No, I did NOT tell you to go play with those commands > on your production NetBackup server. ] > > > ___ > Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu > ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] Fun with EMM internals
Has anyone had the time to look around at the various binaries included with the internal ASA database in /usr/openv/db/bin ? In particular, I've been playing with dbunload and was wondering if there's anyone who knows something about ASA or Sybase who could explain why it dumps what look like a perfectly good reload.sql command file and associated files for the tables, but then refuses to reimport them into a clean EMM database (without erroring out. Lots of "Primary key for table 'EMM_AllocationStatus' is not unique" and such errors. And yes, I know support would laugh themselves silly if I tried calling this in. Just thought I'd see if anyone else is out there causing trouble and had any ideas. =) - John Nardello [ Obligatory CYA - No, I did NOT tell you to go play with those commands on your production NetBackup server. ] ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu