Re: Just Installed But Now Shrugging

username SYS is the "owner" of nearly all of the oracle defined tables, views, packages, etc. including the data dictionary views.

username SYSTEM has DBA privileges, and owns only a few oracle defined objects.

including "as sysdba" in the connect gives you system dba privileges needed, for example, to shutdown or startup the database.

connect internal

is going away in a future release. this is equivalent to

connect / as sysdba

if you are not logged on to the unix box as a user with the proper permissions, you can connect to a local database by providing the username/password:

connect sys/change_on_install as sysdba

i've never had a need to connect as dbaoper... an "operator" would have a subset of the privileges of s "dba"... an operator can probably shutdown and startup the database, but maybe not create a new database...

this is just part of the whole user identification (who are you?) authentication (are you who you say you are?) and privileges (what operations are you and are you not allowed to perform?) setup

as you get into it, you will find that both SYS and SYSTEM are usernames with powerful privileges, powerful enough to essentially destroy the database. be VERY careful when logged on as either. when either username will do, then use SYSTEM.

be very careful what system privileges you grant to what usernames. also be careful granting the roles CONNECT and RESOURCE, which include a lot of system privileges.

"Michael B. Allen" <mballen_at_erols.com> wrote in message news:slrn9j9vpj.1db.mballen_at_nano.foo.net...
> Spencer wrote:
> >The Oracle Documentation is indispensable, but it is not really
> >organized step-by-step for the beginner. Do read the Concepts
> >guide. It will give you part of the foundation (terminology and
>
> I have this book! It's the Oracle 7 Concepts one.
>
> >"Oracle: the Complete Reference" Koch and Loney is a good
> >text... Reference, yes. Complete, not quite. It does cover the
> >basics.
>
> Ok, sounds like this is what I'm going to get then.
>
> >I'd suggest you keep an annotated log of all of the SQL statements
> >that you run... why you ran which statements, and what worked and
> >what didn't. There is absolutely no substitute for the experience you
> >are gaining.
>
> This is great advice. It's exactly the kind of stuff I want to
> know about. One time I wrote a stack.c program and posted it on
> comp.lang.c. People commented on semantics, style, to typedef or not to
> typedef ...etc. I would make changes and post the result. The thread
> was 20-30 posts and I learned a great deal about writing c and good c
> programming style from writing that seemingly trivial 100 line stack
> module. I think the subject was "How to Write the Perfect C Program"
> or something like that. I love Usenet :~)
>
> >As for mount points and file system layouts, there are two fundamental
> >reasons for using multiple disk drives, file systems and mount points:
> >recoverability (the ability to "recover" the database in the event of a
> >failure) and improved performance (effectively distributing i/o across
> >the available controllers and disks.)
>
> Clear enough. I suspect it take a lot of expience to know exactly how
> to partition all the data though; I'll leave this stuff for later.
>
> >a few suggestions:
> >
> >for "normal" work, do NOT use the SYS userid... only use SYS
> >for running the /rdbms/admin scripts that require these to be
> >run as SYS.
>
> I've been wondering what the difference between all these accounts are:
>
> internal
> sys/manager
> sys/manager as sysdba
> sys/manager as dbaoper
> system/change_on_install
> system/change_on_install as sysdba
> system/change_on_install as dbaoper
>
> >change the default tablespace for users other than SYS to
> >something other than SYSTEM (e.g. USERS or TOOLS)
> >do not create user objects in the SYSTEM tablespace.
>
> Yes, sqlplus barked at me for trying to create a table in the SYSTEM
> tablespace. Are the USERS and TOOLS common tablespace names to use? I
> suspect USERS is for users to run standard SQL queries in and TOOLS
> would be where support procedures and functions are loaded?
>
> >here are a few more statements to get you started:
>
> This is great. This is right at my level. I have been mucking about with
> these kind of things quite a bit.
>
> My immediate issue is creating public rollback segments so I can actually
> UPDATE a table with some data. I think I need to use the rollback_segments
> = (name1, name2), transactions = 40, transactions_per_rollback_segment =
> 5 directives in my initSID.ora and recreate the database.
>
> This has been very helpfull. I think I'm at a point where I should put
> NPR on low, find a comfortable chair, and do some serious reading.
>
> Thanks,
> Mike
>
Received on Sun Jun 24 2001 - 00:48:47 CDT