Installing EBS on Linux Part 3, companion

This is a companion piece to my third guest post on the ORACLENERD blog about installing Oracle E-Business Suite. I'll try to address questions and errata from that post here, rather than repeatedly asking Chet to tweak his blog just because I was unclear or incorrect. ;-)

What is it with you Linux nerds and your love affair with the command line? Can't I do all this stuff from a GUI?

Well, you could use Enterprise Manager's database control or Grid Control to stop and start the database, and the OAM utility (see the next post in the ORACLENERD series) will allow you to stop and start some services from the GUI. But for the most part, no, you're going to need the command line to perform a lot of the EBS maintenance and administration functions.

Back up the database? It's 200GB. Do you think I'm made of storage or something?

Let's think about this a different way. If you lose the database to corruption or user error, you'll have to reinstall your Apps instance from scratch. If you have that much time on your hands, well, I just moved, and could use some help unpacking. C'mon over. 200GB is a lot of space, but RMAN compressed backups must employ some sort of magical fairy-dust algorithm, because my full compressed backup of the database weighed in at a mere 22GB. That's nearly a 90% compression rate, and smaller than most iTunes libraries. Besides, you weren't just going to keep the EBS install media around forever, were you? Once you free up the space consumed by your staging area, you could fit two backups on that disk. Oh, the luxury!

Okay, smart guy, I'm not a DBA, and now you're telling me I need to learn RMAN in addition to all this other stuff?

Well, yeah. but I'll help you cheat ahead. Here's a very quick RMAN backup script that you can run to back up the the database "cold," i.e. after you've shut it down, then re-mounted it (i.e. 'startup mount,' not 'startup'). I'll assume that you haven't enabled ARCHIVELOG mode yet. If you have, then you probably already know enough DBA-fu to write your own RMAN scripts, too. ;-)

run {
allocate channel d1 device type disk format '/u02/backup/R12VIS/%U';
backup as compressed backupset filesperset 1 database;

Change the directory in the quoted section after 'format' to match whatever directory you've designated as your backup directory, but keep the %U. Save the script, and then, as the oracle software owner, run rman target / @your_script_name . Then go out and run some errands or something; taking a compressed backup of 200GB is going to take a while. :)

Why should I use the and scripts instead of stopping and starting database services the normal way (i.e. lsnrctl and sqlplus)?

Good question. Frankly, I don't use the EBS-supplied scripts for those tasks very often; I prefer the old-school manual method. One advantage to using the scripts, however, is that it makes scripting automated shutdown and startup of the database and listener pretty easy, complete with exit codes so you can relax or panic based on the outcome of the process. If you are going to use, however, be aware that it's configured to use the old-style pfile (init.ora) rather than an spfile when starting the database. Ben Prusinski wrote a blog post recently that covers this limitation (and a workaround) in detail.

Um, yeah, so what's a concurrent manager, and why do I care?

Concurrent managers are the internal job-control mechanism for EBS, a collection of processes spawned for handling reports and tasks that are better suited to batch processing, or that will take longer than a reasonable UI refresh will permit. In real life, you care because you can be very granular about allocation of the Apps system's resources, assigning work shifts, priorities, and dependencies to different concurrent programs (DBAs will immediately think DBMS_SCHEDULER, but it doesn't use those mechanisms). In the case of our little test system, you care because they'll use up a lot of resources on in the Vision instance, since the out-of-the-box configuration of Vision runs a lot more concurrent processes than are really necessary for a single-user system.

I just want to explore the EBS UI a bit, and would like to avoid the overhead of running the concurrent managers. Can I feed flags to to only start the bits that I want?

Not exactly, but you can run the individual component scripts invoked by, omitting the script ( that starts the concurrent managers. In fact, running the following two commands will get the web and forms interfaces up and running well enough for purposes of most experimenting:

  • start
  • startall (not start)

Keep in mind, however, that some aspects of the EBS system rely on frequently-running concurrent programs to function properly. Furthermore, if the CMs are down for too long, all those previously-scheduled jobs will stack up, and the next time you do start them, you can expect your system to get slammed for a while.

Post a Comment

Your email is never published nor shared. Required fields are marked *