P. 1


|Views: 1|Likes:
Published by Arsalan Ahmed

More info:

Published by: Arsalan Ahmed on Dec 26, 2012
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less







3 3 3 3




his chapter has a quick analytical view of the important concepts you will encounter when using Oracle8. While some of these concepts are specific to Oracle8, many apply to any relational database.

In This Chapter
Looking at Users Understanding Roles and privileges Reviewing storage concepts Defining Objects

You will find further coverage of the material in this chapter embedded in later chapters. You could think of this chapter as the pure science and the later references as the applied science. For your ease of use, I note the cross-reference in each section of this chapter.

Security in Oracle8 involves several interconnected components: Users, Roles, privileges, and profiles. After a brief overview of each component, there is a quick description of the default security setup with Oracle8.




Chapter 6 shows how to create Users with Security Manager. Chapter 11 describes how to create Users with SQL commands. One of the first DBA tasks often involves defining new Users. Later, when a definitive security plan evolves, the DBA establishes Roles with specialized sets of privileges to enforce security. Each end User with access to the database becomes a member of at least one Role created by the DBA. A new feature of Oracle8 enables you to control aspects of the User’s password, such as expiration, complexity, and what to do when a User enters an incorrect password.


Part I 3 Getting Started


Chapter 6 shows how to create Roles with Security Manager. Chapter 11 shows how to create Roles with SQL commands. Roles give you a convenient way to manage sets of privileges. Once a role has been created, the DBA assigns privileges to the Role rather than to the User. In turn, the DBA assigns Users to the Roles. A User inherits all the Role’s privileges when you assign the Role to her. A User can have more than one Role assigned at one time.


Chapter 6 describes how to assign privileges to Users and Roles with Security Manager. Chapter 11 shows how to assign privileges to Users and Roles with SQL commands. Two kinds of privileges exist: 3 Object privileges. Use these to control access to database Objects. A database Object can be many different elements within the database, such as Tables, Indexes, Synonyms, Constraints, and Object Tables. You assign the privileges for each Object. Examples of Object privileges are SELECT, INSERT, UPDATE, and DELETE. The ability to assign privileges like SELECT and UPDATE belongs solely to the Object Owner (Schema) by default. Even the DBA cannot assign these privileges for another Schema’s Tables unless the Schema has allowed it with a special kind of privilege. The GRANT option delegates the capability to assign (GRANT) a privilege. 3 System privileges. These privileges are capabilities not specific to one Object. For example, the DBA may have the system privilege called CREATE ANY TABLE, which enables him to create a new Table in any Schema. The ability to assign system privileges like ALTER ANY USER belongs solely to the DBA by default. The ADMIN option delegates the capability to assign (GRANT) a system privilege.


Chapter 6 shows how to manage profiles with Security Manager. Chapter 11 describes how to manage profiles with SQL commands. Profiles, like Roles, can simplify and streamline the work of the DBA or security officer. A profile is a collection of capabilities you can assign to one or more Oracle8 Users.

Chapter 3 3 Concepts


Profiles limit usage of system resources such as CPU time, connect time, and idle time. Profiles also limit usage of database resources such as the number of concurrent sessions per User and the number of blocks read per session. Once created, profiles can be assigned to Users. Oracle8 has one profile preloaded with its default database. The Profile is named Default.

Oracle8 default security
A brief list of the standard security in the Oracle8 database world follows. For simplicity, I use the term Object to represent all the various Objects that make up the database, such as Table, Index, Synonym, view, and so forth. 3 An Object can only be created by a User with privileges to do so. Once a User creates an Object, that User name becomes a Schema with the same name. A Schema is simply a User who creates one or more database Objects. 3 An Object has an owner — the User who created the Object. The Object, in other words, is in the Schema of the owner. For example, if AMY creates a Table called AQUATIC_ANIMAL, then AQUATIC_ANIMAL is part of the AMY Schema. 3 If you’re the Object Owner, you can perform the following actions on the Object: 3 View the data in the rows in the Table. 3 View and modify the Table structure (Column names and so forth). 3 Add and delete rows of data. 3 Add, change, and remove data in any row or Column. 3 Modify the structure (add, change, and remove Columns). 3 Remove the entire Table. 3 Create Table Synonyms, Indexes, Primary Keys, relationships, and views. 3 Grant and revoke permission to any User or Role to perform the preceding tasks. 3 By default, no other Users may view or modify an Object. Those privileges must be granted by the Object Owner or by a User who has been granted the privilege along with authority to grant the privilege to others.

If a User queries a Table without proper permissions, he gets this error message:
ORA-00942: Table or view does not exist


Part I 3 Getting Started

Oracle8 uses Roles to group related privileges together. For example, the Resource Role gives a User every system privilege needed to create database Objects. Executing a Procedure is an exception to the general rule of Object privileges. A Procedure executes with the privileges of the Procedure Owner, not the User who runs the Procedure. As long as the User has the EXECUTE privilege on the Procedure, the User needs no privileges on the Objects used inside the Procedure.


Chapter 5 shows how to allocate data files and Tablespaces using the Storage Manager. A database requires physical storage space, of course. Oracle8 allocates storage space using physical datafiles and logical Tablespaces. When you allow Oracle8 to create a default database, the process creates a set of datafiles for the database to use. If you create a custom database, you must define your own datafiles during the process. Adding another data file expands the size of the database. You can take a file offline for backup in some cases. You can also design a file to grow in predetermined increments to avoid running out of database space. Every physical data file is mapped to one logical Tablespace. A Tablespace can span more than one data file. Only Objects inside the Tablespace can use the available space in a data file. A Tablespace has characteristics that define how it allocates space to Objects, such as the percentage of free space you reserve for updates. You can also design a Tablespace to grow in predetermined increments to avoid causing a database Object to run out of space. The space used by a Tablespace cannot go beyond the physical data file space you assign to the Tablespace. Every Object created in the database is mapped to one Tablespace. You can specify the amount of space used by an Object when it is created. The amount of space can be modified later if needed. Each Object receives an initial space allocation. When this is used up, a chunk of space (extent) is allocated to the object. The space used by an Object cannot go beyond the total assigned Tablespace space in which the Object resides. Usually one or more Tables are mapped to one Tablespace. Furthermore, no two tables can share a single data block. Two kinds of tables are exceptions to these rules: partitioned Tables and clustered Tables. 3 Partitioned Tables. In the case of extremely large Tables, you divide the Table into partitions. Each partition can be mapped to a separate Tablespace. Each Tablespace is mapped to a separate data file. The primary purpose of partitioning a Table is to distribute the load across multiple physical devices.

Chapter 3 3 Concepts


3 Clustered Tables. Several Tables that are closely related and frequently referenced together in queries can be clustered. Clustering merges the rows of two Tables so the Tables share data blocks.

Chapter 22 shows how to create clustered Tables and their Indexes. Chapter 23 describes how to implement extremely large Tables using partitioning and LOBs (large Objects). Table data is stored in rows. Rows are loaded into data blocks, which are the smallest chunks of space Oracle8 manages. You can view the physical location of any particular row by looking at its RowID. Rows in a Table may not be stored in any particular order unless the Table is stored in a clustered or partitioned Table. Oracle8 adds rows to the end of a block until there is no more room, though a certain amount of the block is saved to allow room for updates to rows in the block. When a row is updated with additional data, it may outgrow its current location. In this case, the row is chained to another data block. The row now spans two data blocks. Chaining degrades performance; you should monitor and correct this problem by Exporting and Importing the Table.


Chapter 15 shows how to evaluate a command’s efficiency using EXPLAIN PLAN, Hints, and the Performance Monitor. Oracle8 uses its Optimizer to evaluate every command that is run in the database. The Optimizer has rules that calculate the most efficient path to the data. The optimizer reviews the WHERE clause of a command and determines how to use Indexes, Table scans, partial Indexes, and so forth. From this information, the Optimizer comes up with a plan. Use the EXPLAIN PLAN command to evaluate a command with the Optimizer. View the plan by querying a special Table containing the plan details. The Optimizer can take into account the physical structure, size, and makeup of your Table if you run the ANALYZE command on the Table. Providing Hints embedded in the command constitutes another way to aid the Optimizer. Use this strategy for unusual Tables in which you have determined (using EXPLAIN PLAN) the Optimizer is actually choosing a less efficient plan. Partitioning aids performance by narrowing down the partitions physically read during a database operation. The Optimizer analyzes the physical location of the data and eliminates partitions that do not contain data relevant to the operation. Partitioning helps Oracle8 store and retrieve very large tables efficiently.


Part I 3 Getting Started

Clustering improves performance by storing closely related data in the close physical proximity so the data is retrieved together. If the same data were retrieved from two nonclustered Tables, two separate retrieval functions might be required. Oracle8 provides a tool called Performance Monitor to help you view the activity on the database.

Use auditing to aid you in monitoring performance. You can tell Oracle8 to monitor and report usage patterns on particular Tables. Chapter 20 describes how to configure auditing features.

Backup and Recovery

Chapters 16 and 17 discuss backup and recovery in further detail. The backup and recovery strategy you use depends on the needs of your particular site. If, for example, you run a 24-7 operation where no downtime is tolerated, you should consider hot backups, in which the database is backed up while it is still online. If you have periods — such as during the night — when the database can be down, you should consider cold backups, in which you first shut down the database and then back up the database files. You can do backups and recoveries using the Backup Manager GUI tool or the Server Manager (svrmgr) line-command tool. Export and Import give you another method of backup and recovery. Export the full database or Schemas and Objects within the database. The database automatically recovers itself in many cases where media failure caused the database to require recovery. Sometimes, operator errors force you to restore the database to a time prior to the error. Manual recovery processes enable you to specify a time or a transaction number where the recovery stops. This book does not cover how to design a database. Oracle8 gives you both relational and Object-oriented database design choices. Table 3-1 describes some common terms used in database design. Familiarity with these terms helps you communicate clearly with other database designers.


See the glossary for many more terms and definitions.

Chapter 3 3 Concepts


Table 3-1 Database Terms and Definitions
Term Constraint Definition A rule applied to an Object that restricts the data allowed in any instance of the Object. For example, a Primary Key Constraint on a Table defines the Primary Key for a Table. All rows must have unique values in the Columns included in the Primary Key Constraint. The Primary Key of a reference Table that is stored inside another Table. The Foreign Key connects the two Tables. It enables access to all information stored in both Tables without repeating data from either Table (other than the Key Column). An SQL command for adding security privileges on a Table, Synonym, or view. A single complete Oracle database. Each instance has its own name, number, and initialization parameters. Multiple instances can run on one computer. A function or Procedure that manipulates or extracts data from an Object. A method is connected with an Object type and invoked when referenced in a query or another SQL command. A Table created using one or more Object types as data types for the Columns. Object Tables contain Object rows. A framework that defines the structure of an Object. Object types can contain other Object types. Similar to Table view, an Object view is based on a query. An Object view formats data stored in relational Tables into Objects. A Column or set of Columns in one Table that uniquely identifies each row in the Table. Every row in a Table has a value in the Primary Key different from every other row in that Table. Everything created by a single User in Oracle8 (Tables, Roles, Indexes, Objects, relationships, and grants).

Foreign Key

Grant Instance


Object Table Object type Object view Primary Key


Object-Relational Concepts

Chapter 24 shows how to create and use Objects in Oracle8. The addition of Objects transforms Oracle8 into an entirely new form of database: an Object-relational database.


Part I 3 Getting Started

Objects are useful in translating business rules into workable and reusable modules. The primary advantages: Objects are reusable and you can test an Object as an independent unit prior to implementation. The primary disadvantages: Objects are more complex to design than relational Tables and Objects are a new technology to Oracle, currently making them less portable than the older relational model. To use Objects, you must set up Object types, which define the structure of data. These types are similar to your own data types for use in defining Table Columns. In addition to building the Object types, you must also build Object methods to associate with an Object type. Each method contains commands for manipulating data within the Object. A few predefined methods exist for certain tasks. You can write methods in PL/SQL and store them in the database or write them in C++ and store them outside the database. The data itself is never stored in an Object type. You must create either an Object Table or an Object view based on the Object type. An Object Table or Object view can contain normal Columns (columns with the usual data types such as VARCHAR2) in addition to containing Object attributes (complex structures defined by Object types). If you use Object Tables to store your data, you use Object methods to manipulate the data. You can only use relational-style SQL on portions of the Object defined as normal Columns. Rows stored in Object Tables are called Object rows. Object Tables can have Primary Keys and Indexes. Foreign Keys are implemented using the REF function and extracted using the DEREF function. Every Object row contains an Object identifier (OID) that functions similar to a RowID: the OID is a unique locator code for each Object row. If you use Object views, your data is actually stored in relational Tables. Object views provide an Object-oriented look at the data. You can use Object views to add data to the underlying relational Table using triggers that break out the appropriate fields and place them in the appropriate Tables. Alternatively, you can use SQL to manipulate data in relational Tables.

This chapter is a quick overview of concepts covered in detail throughout the book. Each topic builds the foundation of a solid knowledge base that you, the database professional, can use to maximize your effectiveness as a designer, programmer, or DBA.




You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->