How long would RRR|Chive take to move a 700gb db? Thanks, Axton
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 Fri, Sep 18, 2009 at 10:48 AM, Misi Mladoniczky <[email protected]> wrote: > Hi, > > Let me know off list, and I will get you the newest RRR|Chive version that > is much faster in syncing two systems. > > I would to it like this: > 1. Do a new install of the new server 7.1/7.5 > 2. Import your custom groups > 3. Import your custom forms using def-files > 4. Analyze your core form customizations (probably some > permission-settings at least) > 5. User RRR|DefHideExpandBox to get rid of the expand-box on field 2, 4 and 5 > 6. Use RRR|Chive to SYNC the data from your old production to the new > production server > 7. Test and fix > 8. Do a new RRR|Chive SYNC which will be much faster than the bulk transfer > > 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. > >> Paul, >> I would recommend a fresh install of everything in the destination. I >> recommend this because migration from version/platform will be extremely >> difficult. Particularly problematic will be your conversion from >> non-unicode to unicode....I do not believe this can be done easily...so I >> would recommend first setting up your 11G DB, then installing Remedy 7.5 >> in >> their respective environments. Then doing a selective code migration from >> existing to new. Selective in that much has changed between 6.3 and >> 7.5...I >> would avoid migrating 'core' forms, instead re-customizing them manually. >> I >> recommend 7.5 instead of 7.1 because in less than a years time 7.1 will be >> R-2, which means it will be reaching it's end of support life, best to >> migrate to current 'R' and in a years time be slightly behind the curve >> instead of significantly. Regarding data, I would suggest you look into >> 'rrrChive'...a tool produced for free from RRR and has been used by many >> on >> the list including myself successfully in the past. This will allow you >> to >> move the data you care about into your newly setup server and forms with >> relative ease. Once you have the simple system setup, then install your >> second remedy server and get server groups configured and functional. >> Regarding 'hot backup' of your data, I have never personally worked with a >> hot backup db server and associated app server....the closest I worked on >> personally was an HP HA cluster with two nodes each capable of running >> both >> db and app, but connected to a raid5 san...so if any single piece of >> hardware were to fail it would switch to the other, or in the case of >> disk, >> simply wait for the replacement to be put in. I have been involved in >> countless disaster recovery discussions, but none have ever come to >> fruition >> for me, so I fear I can't speak authoritatively on that subject. >> >> _____ >> >> From: Action Request System discussion list(ARSList) >> [mailto:[email protected]] On Behalf Of Paul Blasquez >> Sent: Thursday, September 17, 2009 6:05 PM >> To: [email protected] >> Subject: Major 6.3 Migration Project >> >> >> ** >> 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: [email protected] ARSlist: "Where the Answers >> Are"_ >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> Platinum Sponsor:[email protected] 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:[email protected] ARSlist: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
