Forum OpenACS Development: Any info out there on moving old ACS sites to newer Oracle?

Request notifications

I have so far been unable to install Oracle 8 on RedHat Enterprise Server, and if I can't figure it out I'm going to have to take a site from 8i up to 10g.  *shudder*  This is a very old site, based on ACS 2.x and heavily customized by a number of people, so there's no way I can use any of the patches that were applied to OpenACS.  If anyone can point me at any porting documentation, something that would list the important differences, I would really appreciate it!  I haven't been able to find much so far.
Perhaps not that much help but I moved a 4.2 site from 8.1.7 to 9 without too much trouble and I'm running 5.1 on 10g now. All I did was load the data and fix what didn't compile. Most of this is because of keyword changes and package definition errors. There were not that many things and I suspect an older site would be easier. The other thing to watch out for is the performance is different. Most things are faster but a few are slower and I did not find all the slower ones until it was in production. The only way to find these is load test.
New oracle??

Export And Import, this process should not be that hard ..

Were you able to install 10g ??? if so, create a user for ACS and import the old schema into it, configure your server to read from this new database and run..

if you are facing a clear problem state it (Errors).

Barry, please post about or submit patches for any of the performance problems you found or addressed. Getting these sorts of things back in is tremendously important since tracking down and fixing these things is sometimes pretty hard.
I didn't find any performance problems in the core. There was a problem that causes 9i to quit, but in the forums somewhere. I think it's a view that joins against null in some weird way. That would be in a 4.2 upgrade.

I had about 5 problem queries out of thousands, but until I fixed them the site was almost unusable with more than a few people. I didn't really find any pattern either. One was something like

select stuff from table
select stuff from dual
The dual apparently confused it. I did notice there is a dual optimizer in 10g


Moving to 9i wasn't difficult? Isn't it that all the references to "new" when creating packages and so on, need to be changed? Or it's almost an out-of-the-box migration ... ? I am curious ... :)

I also have a OACS 5.1 running on 10g on a clone of RHEL 3.0 ... I noticed that the web interfaces for the DB administration is taking almost 800MB of RAM !!! I can shut it down and then my server, which only has 1GB RAM becomes quite usable again ... I am not sure if that is actually something I should not do, because it might be stopping all the new features of 10g (like self diagnosis and almost self tuning thingies)



There is a sql compatibity setting in 9i and I set it to 8.1.7. If you do that the new/delete stuff is not a problem. Depending on what your goals are this may or may not be a good idea.

I run 10g on an Sun X1 with 768meg of ram no problem. It appears java is taking about 350meg but the RSS is only 61meg. Oracle has 400meg and uses pretty much all of it. Someday I'd like to benchmark Linux/Intel vs Solaris/Sparc. I know that's hard to belive, but my gut feeling is Solaris/Sparc has a better price/perforance ratio. Has anyone tried this with OpenACS?

Posted by Andrew Piskorski on
Barry, there's a reason nobody in the HPC cluster/Beowulf world (that I've ever heard of) uses Sparc hardware at all anymore: Those folks are very sensitive to cost/performance, and for some years now Sun hardware has sucked in that regard. Probably since at least 2000, maybe earlier. The same basic effect appears to apply to everyone running web and database servers as well.

There's also no indication that any of this is going to change soon, Sun hasn't been putting much money into Sparc development for years now, etc. In fact, the smart bet is that both the raw performance and price/permance lead x86 has over Sparc will steadily increase, not decrease. IBM's Power and PowerPC chips are the dark-horse contender here (behind AMD and Intel, of course), Sun's Sparc chips aren't even in the race anymore, and haven't been for years. Most likely they never will be again, either.

(For massive 64+ CPU SMP boxes, the story might be different, but that's an entirely different game, and I don't know the score there. Very few such machines are sold anyway, as they are very expensive.)

Thus I would be extraordinarily surprised if you can actually show that Solaris/Sparc gives you a better price/performance ratio than x86/Linux. But if you can, I'd be interested to hear it.

9: ACS 2.x (response to 1)
Posted by Andrew Piskorski on
ACS 2.x, my god. You should maybe get Nuno (he's at Red Hat) to upgrade it for you. A long time ago, he upgraded the Muniversal site from ACS 1.x all the way to 3.2! :) Not an easy task though, and it took quite a while. Hm, and I think there was some sort of technical reason we stayed at 3.2 from then, I don't remember what though. So on second thought...
I've only got one example and there are lots of variables. I was running a pretty active site with 4 front end webservers and 1 NT database box with 2x2.5 Xeons and 2gig memory . We decided to switch to a 4x1.25 Sparc with 16gig and fibre channel (Apple xRaid). Due to the budget, the upgrade path included switching to a 2x1.0 Sparc 4gig memory box. The reason for the upgrade was the NT box needed more disk, it was too slow at times and it's 2gig memory limits were a problem.

The upgrade required running on the 2 processor Sparc box for 3 months and I was concerned that this would be a problem. Much to my surprise it turned out to be faster and more stable than the NT box.

As I said there are lots of variables. The Sparc box had more memory but being 64bit it could make use of it. It also had the xRaid drive verses 12 10k scsi drives. I also suspect that Solaris is more stable than NT. Finally it was Oracle 8i on NT vs Oracle 9i on Solaris.

Perhaps this is more a 64 vs 32 bit difference. I'm sure on 32bit arithmatic an x86 would run circles around Sparc, but if you've got a 4gig dataset and the x86 has disk access and the Sparc does not, the Sparc will win every time. That combined with the fact I can buy a 1u new Sparc box for $999 leads me to believe that the price/performance is better for this kind of application at this time, although my guess is when the AMD 64bit chip becomes well supported this will no longer be the case.