SWITCHING ENVIRONMENTS WITH OFFLINE.ENV 2

[benbotektips]

I have a unix box with Oracle 7.3 & 8i loaded under directories /u and /u01. I'm upgrading to 8i, & need to test scripts working on 7.3 on 8i. In a script, there's a line that looks exactly like this:
. offline.env
right before it calls another script to load tables.
There's a file 'offline.env', in the same directory as the calling and called script , which has the new key variables (oracle_home, sid, etc.), and is supposed to switch the environment (and tabled update via the script) to 8i. Problem is, the script runs, control totals match, it looks like everything worked - and the tables don't get populated in 8i.
I got the 8i tables populated by changing the key variables in the database name home directory .profile file, but my boss isn't happy with this. He's positive offline.env is supposed to switch environments in mid-script, and won't allow the permanent change to the home directory .profile file.
I've never heard of 'offline.env', I can't find any documentation on the web, and my boss is pissed.
Can anyone think, is there another file or variable that will allow u to invoke it in a script, to have the script operate on the specificed environment? Any documentation on this 'offline.env' command? I tried putting the 'offline.env' line in the called script, but this generated errors. In general, how do I keep 2 environments on one box, and allow scripts to switch at will to which database is operates on?

 

[hallux]

What you are doing with offline.env (which I have never seen or heard of before) is "sourcing" the file, pulling in environment variables. That's why it fails when you try to execute the file in the script, it is intended to be sourced.
Good luck and you may choose to post this question in the Oracle forum, they probably deal with this kind of problem all of the time.
-Hallux

 

[bi]

It may be the way the offline.env file is written or the way it is being called. I have a script a DBA left behind that seems to allow changing environments in midscript.

Here is how it is set up:

There is a file named oracle.env -- which could be equivalnet to your offline.env file. This file expects a variable to be passed to it -- the name of a SID on the system or the version of Oracle that is being invoked. Then, in a file named for the SID, or the Oracle version, there are two lines: . oracle.env 816\cd $ORACLE_HOME or . oracle.env 817\cd $ORACLE_HOME or . oracle.env mysid\cd $ORACLE_HOME.

The oracle.env, 816, 817, and mysid files are all in the Unix home directory of user oracle.

In a script that runs in both an 816 and an 817 environment, you can switch environments by typing the following:

. $HOME/816 #for an 816 environment, but no SID is expressed

. $HOME/817 #for an 817 environment, but no SID is expressed

. $HOME/mysid #for the correct Oracle env. and a SID. The script gets the correct Oracle version from the oratab.

Another suggestion:
Your boss (and others) might not like this suggestion but it might work: set up two users with the same UID and GID, but different home directories and therefore different .profiles.

For example, you could have ora7 with an Oracle 7 environment and ora8i with an 8i environment. Both would have the same UID. A lot of DBAs don't like this for some reason, but I find it makes for fewer mistakes: if you're logged in as ora8i, you know you are dealing with the 8i environment and you don't have to invoke a separate environment file. This would require, however, an su - ora8i -c, which I believe only root can do without having to supply a password. So root would have to be the user executing the script. Your boss might not like that, either.

Some Unix OS flat don't let you use their sys management interface to create another user with the same UID, but you can edit the /etc/passwd file to create one.

Another alternative might be to "manually" export the new environment variables in your script (rather than calling offline.env or putting it into your script) before you issue the commands that need to be executed in the new environment.

 

[benbotektips]

Thanx for the responses. The dba explained that he had to activate the target environment variables in the system directories. Sounds similar to bi's email. It works, The script switches environments for the script, from Oracle 7.3 to 8i