Re: creating a connection to Oracle 7.3 from Oracle 9i

"Edwinah63" <edwinah_at_customercare.com.au> wrote in message news:d714e824.0210202234.ceda1e4_at_posting.google.com...
> Hi to everyone who replied
>
> many thanks, i appreciate you taking time to answer my questions.
>
> my next question is this what is a "repository" (outside of the
> definition in the glossary)? what is it real life purpose?

Get something very clear in your head. Oracle Enterprise Manager is a GUI tool used to administer databases. It's not the only tool that can do the job, nor necessarily the best one: everything you can do with OEM can be done using the command line tool sqlplus.

So why would you use OEM instead of sqlplus? Well, first it's a GUI, and for some people (particularly those coming from a Windows-centric background) if it doesn't have a GUI, it can't be any good. Secondly, being a GUI, it makes things like scheduling jobs and setting events a piece of cake ('click this, click this, click OK'), whereas you'd need to type for a month of Sundays in sqlplus to achieve the same thing. Third, and most fundamentally, it divorces you from the need to have a direct connection to the database you are administering in order to do the administering: OEM can be accessed via the web, for example, and so long as you can talk to it over the Internet, and it can talk to the managed machines' Intelligent Agent, you yourself don't have to be able to talk to the managed machines. They call that the 'n tier' architecture, and means that OEM is a seriously powerful and flexible tool in its own right, not just a pretty front end to sqlplus.

Now, with that all said, you can't expect something like OEM to do its stuff on the cheap. And in particular, if you are going to be scheduling jobs and setting database events (for example), then OEM needs to have somewhere to store the details of what you're scheduling or setting: and it uses regular old tables to do that particular job. The collection of tables it uses for this purpose get given a grand-sounding name: "The Repository". But all the repository is, is a bunch of tables (and some indexes on those tables).

Now where do tables live? Yup, inside a database. So, to administer a database, OEM needs a database in which to store the details of your administration activities. Now, that database *can* be the same database as the one you're trying to administer. But that's pretty daft: if you did things this way, you'd have to have a direct connection to the database you're trying to administer, and as I said before, one of the key OEM features is that so long as you can connect to the repository database, you *don't* need to connect to the target, or real, database directly. Therefore, whilst it's possible to create the repository in the target database itself, it's rather more usual to create a second, small, database in which the repository (and not much else) lives. That second database is usually best created on your client PC, so that connecting to it is assured (unless you intend to do the 'connect over the web' sort of stuff I mentioned earlier). That way, you can easily manage the tiny repository database directly.

The Enterprise Manager Configuration Assistant, when first run, will tend to want to propose creating such a second database for you (it invokes the Database Configuration Assistant to do the actual deed). But if you've already manually created a smallish database yourself, you can always tell the EMCA to use the pre-existing database. And, if you do what you've done, which is to install and run the whole lot on the backend Oracle server itself, you can get it to create the repository within the target database. But as I said, that's not really a very good idea.... and, for one thing, you'll lose the ability to use OEM to do startups and shutdowns. It's a bit tricky to use a tool which is relying on access to a bunch of tables if those tables happen to be within the one database you've just shut down!

Once you've created the second database, or specified the existing database, the EMCA builds the relevant repository tables for you, and populates them. That's the only repository you then need, however many target databases there are to manage.

Obviously, if there are many DBAs managing many targets, the repository will need to be created on a single machine to which all DBAs can readily gain access, so your private client PC probably wouldn't suffice. That's probably the point at which you start thinking about enabling the web management functionality: install the Oracle HTTP server and OEM on one central server, and all DBAs can get to the repository via their browsers.

Don't let the fact that OEM has the words "Enterprise Manager" in its name confuse you: it bears not the slightest resemblance to the SQL Server tool of the same name. It's far more complex and capable than that, and requires a firm understanding of the n-tier architectural principles involved.

Regards
HJR
>
> in mssql 2000 we can create a database (separate from the master which
> contains all the system info) to hold the live data, create all the
> users with their roles separately and then assign users to databases
> to give them access.
>
> i had a go using the EM Configuration wizard to create a repository
> (OEMREP - yes i just accepted the defaults) however, when i logged in
> as system all it seemed to create was another database!! i already
> have one when created for me during installation (called EVAL).
>
> i am confused as i do not want to create many "repositories" for each
> user. pls note at the moment i am using the OEM on the server, not
> the client.
>
> should i be using the client software?
>
> Edwina
>
> "Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote in message
news:<3db0267c$0$8508$ed9e5944_at_reading.news.pipex.net>...
> > "Edwinah63" <edwinah_at_customercare.com.au> wrote in message
> > news:d714e824.0210180211.5919dac6_at_posting.google.com...
> > > Dear Oracle Community,
> > >
> > > i am a newbie to oracle (being reasonably fluent with mssql server
> > > 2000) and have been asked to evaluate 9i with a view to migrating a
> > > current oracle 7.3 database (on sun solaris) to oracle 9i on win 2000.
> > >
> > > my questions are these:
> > >
> > > * i was asked to change the passwords for sys and system as part of
> > > the installation - now it won't let me log into the enterprise manager
> > > using these (nor sysdba, sysoper, sysman) but.... it would let me log
> > > into sql worksheet as sys/sysdba using the passwords i supplied during
> > > install - any advice on this one?
> >
> > sys and system are database users. Enterprise manager requires a
repository
> > (usually in an oracle database) and has its own logins. Thus you should
be
> > able to connect to your 9i database using the sys and system passwords,
you
> > will need to set up enterprise manager if you wish to use it.
> >
> > >
> > > * how do i create a connection from 9i to the oracle 7.3 database?
> >
> > Ah now this is a bit of a problem as connection from a 9i client to a
7.3
> > database isn't supported and doesn't actually work in the case of 9.2.
If
> > you have installed 9i on a server somewhere then my advice would be to
use
> > an 8i client on your workstation which can connect quite happily to
either
> > 9i or 7.3 databases.
> >
> >
> > --
> > Niall Litchfield
> > Oracle DBA
> > Audit Commission UK
> > *****************************************
> > Please include version and platform
> > and SQL where applicable
> > It makes life easier and increases the
> > likelihood of a good answer
> >
> > ******************************************
Received on Mon Oct 21 2002 - 02:20:43 CDT