Thanks to everyone to replied to this! Especially LJ and Misi, for pointing me towards RRR|Chive, which is a great utility.
It's definitely looking like I will be doing the tedious route, so I will now spend my time importing, fixing, and testing. Hopefully my eyes won't cross and my hair doesn't fall out before I'm done. :) Thanks again! -Paul -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Misi Mladoniczky Sent: Friday, September 18, 2009 10:23 AM To: arslist@ARSLIST.ORG Subject: Re: Major 6.3 Migration Project Hi, A good thing with RRR|Chive, or rather the ARAPI, is that it will handle the character conversion automatically. Another thing with an upgrade, is that it usually brings havoc to the layout of forms it changes. Therefore I think it best to use the forms supplied with the new version, and then customize them to your need. In most cases, I think that you have to change the prmissions of some forms and possibly fields. You may want to hide a couple of system-forms and you may want to mess around with permissions on the User-form to suit your needs. Using a def-file to migrate the application is good. You will then "clean" your possibly very old applications to fit into the new version. If you do a db-copy/upgrade, you may be left with a lot of historical errors caused by ARAdmin-bugs or version incompatibilities. By using the SYNC-mode of RRR|Chive, you can run your new system parralel and do testing/restoration on the new system until you are satisified. Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. * RRR|Translator - Manage and automate your language translations. Find these products, and many free tools and utilities, at http://rrr.se. > Assumptions I am making: > - You are running custom applications (not sla, itsm, cs, crm, etc.) > - You do not have any external api's (plugins, external binaries > compiled for Solaris) on the ar servers > - > > I would go with something along these lines: > > 1. Build the new 7.5 servers: > 1. Install the prerequisite software (db client, java, etc.) > 2. Install ARS 7.5, point it at an empty database that uses the > AL32UTF8 character set > 1. Install subsystems in use (email, approval, etc.) > 3. [1] Manually apply your form/field/permission changes to the core > forms and grab a def > 4. [2] You will need a load balancer, get it set up properly, get > the server group set up properly > 2. Migration preparation > 1. Install the 64-bit 10g oracle client on the old arserver(s) > 2. Empty the contents of the new db instance > 3. Migration: > 1. Upgrade the existing 6.3 server to 7.5 > 1. Perform a minimal installation (ARServer only) > 2. Stop AR on the new and old servers > 3. Convert the db character set/transport the data > 1. Empty the temp new database with AL32UTF8 character set > 2. Exported (exp utility) the data from original database (source) > with the source character set > 3. Copy the dump to the new server > 4. Import (imp utility) the data into the new > database(destination) with character set AL32UTF8 > 4. Perform the upgrade installer for other core ar components > (email, fb, approval, etc.) > 4. Post-migration > 1. Set up oracle data guard > > Footnotes: > 1. A better option would be to update your applications so they do not > rely on (any) changes to the core forms prior to the migration. > 2. Load Balancer: You will require a hardware load balancer (BigIP, > etc.) in front of the ARServers: > - Enable session persistence based on the source ip address > > Special Notes: > 1. Do perform this operation in a non-production environment prior to > upgrading production and verify it works. Also, during this time, if > you run into workflow problems, generate the defs necessary to apply > to an upgraded system so that you can use them during your upgrade. > > Server Groups: Server groups will make the following operations > easier, but is not required to run an HA arrangement with AR: > - Object cache synchronization across all nodes > - Subsystem failover between nodes (e.g., escalations) > > DR Failover: There are many approaches to this; the choice usually > depends on the size of your wallet and the practices currently > implemented for dr: > - Using Oracle DG, the db should be available at the time you need to fail > over > - You should be able to image the AR VM's in the DR with a near mirror > image of the production hosts (hostname can/may vary) > - This can be done on the fly during a dr or maintained separately > - You will need to create a runbook of the operations required to > perform a failover in the event you do not have any type of automated > failover in place. Tasks would include things like: > - dns changes > - fail over db to standby server > - bring up ar servers > > Axton Grams > > The opinions, statements, and/or suggested courses of action expressed > in this E-mail do not necessarily reflect those of BMC Software, Inc. > My voluntary participation in this forum is not intended to convey a > role as a spokesperson, liaison or public relations representative for > BMC Software, Inc. > > > On Thu, Sep 17, 2009 at 7:05 PM, Paul Blasquez <pblasq...@equinix.com> > wrote: >> ** >> Hello, >> >> I have been tasked from moving our current production installation to a >> more >> robust/modern installation. Any and all help would be appreciated! >> >> Currently: >> >> -AR System 6.3 custom server (with modifications to forms User and AR >> System >> Email Messages) >> -Oracle 9iR2 non-unicode >> -Solaris 9 >> -Application and Database reside on the same machine >> >> Goal: >> >> -AR System 7.1 or 7.5 (With form modifications intact) >> -Oracle 11g unicode >> -Linux Redhat 5 >> -Application and Database on different machines >> -Disaster Recovery (DR) backup site (Using Oracle log-shipping) >> -Local High Availibility (HA) backup server (server groups?) >> >> I have at my disposal 4 Virtual Machines (VMs) to do development and >> testing, with an additional 2 VMs and 2 dedicated servers (for the DBs) >> reserved for the final production installation. (Please note that there >> will be Midtier servers involved in all of this, but their deployment is >> trivial so I'm not including them here.) >> >> From my point of view I see that multiple operations must occur for this >> migration to be successful (in no particular order): >> >> 1) The Oracle 9iR2 DB >> -Must be upgraded to 11g >> -Must be translated into Unicode >> -Must be moved from the Solaris 9 machine to the Linux RH5 machine >> >> 2) The current 6.3 installation >> -Must be upgraded to 7.1 or 7.5 >> -Must be configured for server groups >> -Must be moved from the Solaris 9 machine to the Linux RH5 machine >> -Must begin connecting to the DB remotely instead of locally >> >> 3) The finished AR System 7.x installation and Oracle 11g DB >> -Must begin log shipping (Data Guard) to the second DB >> -Must have a method for failing over to the second site >> -Must have a method for local server group failover (load >> balancer/quick >> TTL DNS) >> >> If you have completed any one of these tasks before, *please* share with >> me >> your experience and what you would recommend for my situation! I would >> save me hours of researching dead-ends! >> >> >> Finally, I would like input on what would be the correct order to >> complete >> all of these tasks, so that the cutover would be as smooth as possible >> with >> the least downtime possible. So far, I have tested the following >> scenario >> in Dev/Test: >> >> Fresh installation of 7.1/7.5 >> -DEF import of workflow >> -ARX import of data >> >> This method seems stable but tedious, as there are many import errors I >> would need to repair. This would be the method I would fall back on if >> there were no more clever/sophisticated way to upgrade. >> >> >> Again, ANY input at all would be GREAT, as of course this project is on >> a >> tight timeline. THANK YOU to anyone who responds! >> >> ____________ >> Paul Blasquez >> Senior Network Engineer/Remedy Developer >> >> >> _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers >> Are"_ > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" > > -- > This message was scanned by ESVA and is believed to be clean. > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
