Re: managing two instances on same server

In article <86qlig$2h1$1_at_nnrp1.deja.com>,   chrisoc_at_ans.net wrote:
> I have a concern right at the point of creating
> the new instance from a script, because our
> standard creation script alternates between
> "internal" and "system" connections.
> It hails from the v7 and v8.0 days.
>
> First as "internal" you startup nomount with
> the new profile. Then disconnect-reconnect as
> internal. Then create database (blablabla) and
> catalog.sql.
> Then again connected as "internal" we create
> the system rbs, online it, then the rbs tblspace
> and the temp one, the rbs segments, and quotas
> are given to sys and system on temp.
> THEN you finally get to connect as system/manager
> to run catdbsyn. Going back to "internal" you run
> three sql scripts (standard, dbmsstdx, and catproc.
> You then connect as system/manager and run pupbld.sql
>
> Now all of this "internal" stuff has me thinking
> 'How can we know which instance we are working
> with?' Should I put "set instance <newname>"
> with all these, and also change to
> system/manager@<newname>? Is the instance name
> meaningful right after the startup with the new profile,
> even though there is no database created or catalogued
> yet?
>
> Chris O'Connor
>
> In article <86q6nm$mvh$1_at_nnrp1.deja.com>,
> chrisoc_at_ans.net wrote:
> >
> >
> > I want the maximum independence in taking down one
> > instance, modifying its storage etc. without affecting
> > the other one.
> >
> > If I build the second instance with entirely distinct
> > tablespaces and datafiles (including system, temp, rbs,
> > redologs) and run the catproc etc. for it, I am still
> > not certain how I will be able to connect as system or
> > sys to just that instance and manage it without
> > affecting the first one.
> >
> > Point me to a doc if the answer is complicated.
> >
> > Thank you,
> > Chris O'Connor
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>

--
You'll find that all of the scripts Oracle supplies assume the concept of one database per machine, or at least a "default" database specified by an environment variable or registry setting. If you run multiple sids on a box, you WILL have to allow for that ("change the way you work"). The fact that your scripts switch between logging on as SYS or INTERNAL and SYSTEM is not really the issue. Those are just userids with particular privileges -- they have nothing to do with how connect strings are resolved.

You have to decide if your modus operendi will be to always use a full connect string ("CONNECT user/pswd_at_alias") or set the default sid before connecting. FWIS, we choose to use the full connect string. If you choose to use the "default sid" environment variable, just keep in mind that this is an OPERATING SYSTEM variable used by any process running as a child to the level at which it was set. In other words, if you set it with the registry, it will be set for ALL processes running on that box. If you open a command prompt session and set the environment variable there, it will be available to all processes run FROM THAT SESSION. This means that if you open a command prompt and set the variable, you will not have to set it specifically for each script you run from that command prompt.

SVRMGR vs. SQL*Plus is not an issue in this question.

Ed Stevens
(Opinions are not necessarily those of my employer)

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Fri Jan 28 2000 - 08:24:15 CST