What is a schema?
A schema is a collection of database objects (tables, views, stored procedures etc) owned by a single user. 10g Concepts Manual defines it here. Typically, all of an applications objects will be in a single schema and application users will access those objects through a combination of grants and synonyms.
When to use a schema.
As a rule, each application should be in its own schema. If you are used to Microsoft SQL Server or some other databases, when you would want to create a new database in a server, in Oracle you would create a schema.
The ANSI 'CREATE SCHEMA' statement.
The ANSI SQL standard includes a 'CREATE SCHEMA' statement which in theory allows the creation of all the objects in schema in a single statement. In practice it is useless because (at least as implemented by Oracle) it limits you to ANSI standard syntax within the statement. This means that any oracle extensions to the ANSI standard (for example, storage options) can not be used. Steer well clear.
Creating the schema owner.
The main difference between a schema owner and an application user is that the schema owner requires system privileges (such as create table) whereas an application user only requires object privileges (such as select, insert,delete on a table).
The short method.
The simple way to do this is as follows
C:\>sqlplus "sys/********@xe as sysdba"
SQL*Plus: Release 184.108.40.206.0 - Production on Sun Nov 19 10:18:39 2006
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production
sys@XE> CREATE USER BLOG IDENTIFIED BY BLOG;
sys@XE> GRANT CONNECT,RESOURCE TO BLOG;
This has the merit of simplicity, but not much else.
The problems with this are -
- The RESOURCE role includes the "unlimited tablespace" privilege which means that the schema owner can create objects in any part of the database, including the system tablespace. While the DBAs who will be creating the schema objects know that you shouldn't create objects just anywhere, accidents will happen.
- As currently defined (in 9i and 10g), the CONNECT and RESOURCE roles combined do not include all the system privileges which might be needed. If I try to use the user created above...
sys@XE> CONNECT BLOG/BLOG@XE
sys@XE> SELECT * FROM SESSION_PRIVS;
10 rows selected.
sys@XE> CREATE TABLE X ( COL1 NUMBER(10) );
sys@XE> CREATE VIEW Y AS SELECT * FROM X;
CREATE VIEW Y AS SELECT * FROM X
ERROR at line 1:
ORA-01031: insufficient privileges
The select from SESSION_PRIVs shows the privileges which are currently active and are the union of the privileges in the granted roles.
This particular example would have worked in 9i because the connect role included the CREATE VIEW privilege, but there are other privileges which are missing.
This table lists the system privileges which a schema owner might need, with those provided by the connect and resource roles highlighted.
ALTER SESSION2 CREATE CLUSTER12 CREATE DATABASE LINK2 CREATE EVALUATION CONTEXT CREATE EXTERNAL JOB CREATE INDEXTYPE1 CREATE JOB CREATE LIBRARY CREATE MATERIALIZED VIEW CREATE OPERATOR1 CREATE PROCEDURE1 CREATE PUBLIC DATABASE LINK CREATE PUBLIC SYNONYM CREATE RULE CREATE RULE SET CREATE SEQUENCE12 CREATE SESSION CREATE SYNONYM2 CREATE TABLE12 CREATE TRIGGER1 CREATE TYPE1 CREATE VIEW2 1 Granted as part of RESOURCE role 2 Granted as part of CONNECT role prior to 10gR2
Note that (apart from ALTER SESSION), no ALTER <OBJECT> or DROP <OBJECT> privileges are required. An object owner can always drop or alter its own objects.
- In general, it is not a good idea to use system defined roles. The vendor is free to change the definition of the role at any time which could break your applications, or leave you exposed to an unknown risk. With the release of Oracle 10g, oracle drastically changed the definition of the CONNECT role. The original definition included privileges beyond those needed to simply connect and the change was a long overdue improvement. However, unless you were aware of the change, your upgrade could have gone badly wrong.
The right method.
There are three steps to creating the schema owner.
- Create the user
sys@XE> create user blog identified by blog;
At this stage, the user exists, but has no privileges (not even the right to connect to the database) and no resources.
- Specify which resources it can use.
When setting up an oracle user, you can specify what storage it can use, using tablespace quotas, and what machine resources (cpu, clock time etc) using profiles. I won't cover profiles here in any detail here. The tablespaces required should be created in advance.
sys@XE> alter user blog
2 temporary tablespace temp -- specify which temp tablespace to use
3 default tablespace blogdata1 -- ensure uncontrolled creates go somewhere safe
4 quota unlimited on blogdata1 -- allow the creation of objects in a tablespace
5 quota unlimited on blogdata2 -- there can be as many tablespaces here as you like.
6 quota unlimited on blogdata3
7 profile schemaowner_profile; -- security and resource control
- Grant the privileges required.
You can either grant the required privileges directly to the user;
sys@XE> grant create session to blog;
sys@XE> grant create table to blog;
sys@XE> grant create view to blog;
or you can create a role, grant the privileges to the role and then grant the role to the user.
sys@XE> create role schema_owner;
sys@XE> grant create session to schema_owner;
sys@XE> grant create table to schema_owner;
sys@XE> grant create view to schema_owner;
sys@XE> grant schema_owner to blog;
What this does is create your own customised and more useful version of the resource role. A usable sample script is here
When to use the schema owner.
The schema owner account should only ever be used to create and modify the application objects. Ideally it should be locked in when not required and only unlocked as part of your change control procedures.
1 A schema is a collection of objects owned by a single database user.
2 The schema owner requires physical resources and system privileges
3 The default roles provided by Oracle do not provide all the required controls and privileges