Chapte 3
Chapte 3
Concepts
3
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 specic to Oracle8, many apply to any relational database.
In This Chapter
Looking at Users Understanding Roles and privileges Reviewing storage concepts Dening Objects
You will nd 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
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.
Users
CrossReference
Chapter 6 shows how to create Users with Security Manager. Chapter 11 describes how to create Users with SQL commands. One of the rst DBA tasks often involves dening new Users. Later, when a denitive 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 Users password, such as expiration, complexity, and what to do when a User enters an incorrect password.
44
Roles
CrossReference
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 Roles privileges when you assign the Role to her. A User can have more than one Role assigned at one time.
Privileges
CrossReference
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 Schemas 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 specic 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.
Proles
CrossReference
Chapter 6 shows how to manage proles with Security Manager. Chapter 11 describes how to manage proles with SQL commands. Proles, like Roles, can simplify and streamline the work of the DBA or security ofcer. A prole is a collection of capabilities you can assign to one or more Oracle8 Users.
Chapter 3 3 Concepts
45
Proles limit usage of system resources such as CPU time, connect time, and idle time. Proles 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, proles can be assigned to Users. Oracle8 has one prole preloaded with its default database. The Prole is named Default.
If a User queries a Table without proper permissions, he gets this error message:
ORA-00942: Table or view does not exist
46
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.
Space
CrossReference
Chapter 5 shows how to allocate data les and Tablespaces using the Storage Manager. A database requires physical storage space, of course. Oracle8 allocates storage space using physical datales and logical Tablespaces. When you allow Oracle8 to create a default database, the process creates a set of datales for the database to use. If you create a custom database, you must dene your own datales during the process. Adding another data le expands the size of the database. You can take a le ofine for backup in some cases. You can also design a le to grow in predetermined increments to avoid running out of database space. Every physical data le is mapped to one logical Tablespace. A Tablespace can span more than one data le. Only Objects inside the Tablespace can use the available space in a data le. A Tablespace has characteristics that dene 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 le 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 modied 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 le. The primary purpose of partitioning a Table is to distribute the load across multiple physical devices.
Chapter 3 3 Concepts
47
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.
CrossReference
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.
Performance
CrossReference
Chapter 15 shows how to evaluate a commands efciency 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 efcient 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 efcient 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 efciently.
48
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.
CrossReference
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 congure auditing features.
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 rst shut down the database and then back up the database les. 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.
CrossReference
Chapter 3 3 Concepts
49
Foreign Key
Grant Instance
Method
Schema
Object-Relational Concepts
CrossReference
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.
50
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 dene the structure of data. These types are similar to your own data types for use in dening 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 predened 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 dened 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 dened 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 identier (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 elds and place them in the appropriate Tables. Alternatively, you can use SQL to manipulate data in relational Tables.
Summary
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.