Fred, I also have experience with previous versions allowing an upgrade of the DB on new hardware....but when I did the 8.1 upgrade here on our Dev system...I had to first install 7.5 (our current version) in 'upgrade' mode on a restore of the db, then run the 8.1 installer to get it upgraded
Susan, One thing you MAY try is to do a NEW install of 8.1 into a 'dummy' db, then once you have 8.1 installed, shut it down, delete the DB, restore your actual DB, and then do an upgrade of that DB...it 'should' work, but untested by me at this point (although I suspect it'll be tested in a month or so when I do our Prod app server installs :) On Tue, Jun 25, 2013 at 9:32 AM, Grooms, Frederick W < [email protected]> wrote: > ** > > Hmmm… I know when I did Solaris SPARC 7.1 to Linux i386 7.6 the > installer did a new install of the ARS binaries, but an upgrade on the > database.**** > > ** ** > > Fred**** > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Susan Palmer > *Sent:* Tuesday, June 25, 2013 10:24 AM > > *To:* [email protected] > *Subject:* Re: Moving from Solaris to Linux**** > > ** ** > > ** **** > > Misi/Fred,**** > > **** > > Yes, I given the lecture of proper programming practices regarding table > ID's but they choose to continue to do it. You can all read my mind on > what I would be saying to them ... lol **** > > **** > > We are using a temporary server place to try this all out.**** > > **** > > Fred, your sequence of events is what we originally tried. But the > upgrade 8.1 did not like the fact that 7.5 wasn't there first and we had > to do several lib additions etc to get past that, but could never get a > successful 8.1 install. Support said 7.5 has to be there first. This is > where we left off when we couldn't get past the 10g client issue.**** > > **** > > Thanks for the thoughts...**** > > **** > > Susan**** > > ** ** > > -----Original Message-----**** > > On Tue, Jun 25, 2013 at 9:49 AM, Misi Mladoniczky wrote:**** > > Hi, > > I know of no good way to do that, except importing the forms in such an > order > that the numbers stay the same. Maybe a tool can be created for that... > > In any event, it seems wrong to build stuff that depends on the table > numbers. > You should try to use the database-Views, the API or similar to access > stuff > from remote systems. A migration such as that is a good time to clean up > your > environment ;-) > > In any event, I guess you can use RRR|Chive to minimize downtime even if > you > work on an upgraded database. > > You might have a temporary linux system where you install 10g and then > upgrade > everything. When you have a db-dump of the upgraded system, you can start > over > again with a fresh linux, version 11g and install 8.1 against that db-dump. > > Best Regards - Misi, RRR AB, http://rrr.se**** > > ** ** > > ** ** > > -----Original Message-----**** > > > Hi Misi, > > > > The last time we did that process we imported forms/objects to the new > > server and did use rrrChive for the data. The issue was that the forms > > changed table ID on the new server which caused issues with other > programs > > accessing Remedy. Is there a way to get the forms over there without > > changing table ID's? > > > > Thanks, > > Susan > >**** > > ** ** > > -----Original Message-----**** > > > On Tue, Jun 25, 2013 at 9:11 AM, Misi Mladoniczky wrote: > > > > >> Hi, > >> > >> I would do a fresh install of version 8.1 on Linux, and then migrate > >> definitions and data over. > >> > >> Probably using RRR|Chive for the data part. > >> > >> This would make it possible to keep the outage down to a single hour or > so > >> during the final delta-sync and switch. > >> > >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP > 2011) > >> > >> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11/12): > >> * RRR|License - Not enough Remedy licenses? Save money by optimizing. > >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy > logs. > >> Find these products, and many free tools and utilities, at > http://rrr.se. > >> > >> > Hi Everyone, > >> > > >> > Our current environment is Solaris 10 with Oracle 10g non-unicode and > ARS > >> > 7.5P4. We are trying to move to a Linux CentOS release 6.4 Final (Red > >> Hat > >> > Linus 6.4) with Oracle 11g unicode and ARS 8.1. These are VM > instances. > >> > > >> > We are finding the Linux box does want Oracle 10g. Since we are > moving > >> to > >> > a new server we wanted to do fresh installs at the 10g level and do an > >> > import of our database, then proceed with the oracle upgrade and ARS > >> > upgrade. > >> > > >> > So we thought we would start with an 11g db on the linux box and go > from > >> > there but when we tried the 7.5 install it said it wouldn't work on > 11g. > >> > When I check the compatibility chart it indicated 10g or higher for > 7.5. > >> > > >> > So the basic steps we'd like to do: > >> > Install 11g on the linux server. > >> > Export 10g from current server and import it into 11g. > >> > Install ARS 7.5 (we received an error at this point saying it > wouldn't > >> > work on 11g ???) > >> > Install ARS 8.1 > >> > > >> > Has anyone done something similar? Is there something wrong with our > >> > approach? > >> > > >> > Appreciate any feedback you can provide. > >> > > >> > Thanks, > >> > Susan > >> > > >> > Susan Palmer > >> > ShopperTrak > >> > 233 S Wacker Drive 41st floor > >> > Chicago, IL 60606 > >> > 312-529-5325 > >> > [email protected] > ** > ****** > > ** ** > _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
