Database 版 (精华区)

发信人: rhine (风雨无阻), 信区: Database
标  题: Oracle DBA Guide, V8, part 15
发信站: 哈工大紫丁香 (2000年07月08日20:34:21 星期六), 站内信件


发信人: chendu (Oracle Only), 信区: Database
标  题: Oracle DBA Guide, V8, part 15
发信站: BBS 水木清华站 (Sat Nov 13 15:34:08 1999)

Hi, required by several friends, I am posting the
Oracle Database Administrator's Guide version 8
here.

Web Master, if my post it too long and not good for
the bbs, please delete it and I am sorry for it.

Hoping everyone enjoy it!

Good luck!


----------------------------------------------------------------------------

15
Managing Clusters
This chapter describes aspects of managing clusters (including clustered tab
les and indexes), and includes the following topics:
Guidelines for Managing Clusters
Creating Clusters
Altering Clusters
Dropping Clusters
Before attempting tasks described in this chapter, familiarize yourself with
 the concepts in Chapter 10, "Guidelines for Managing Schema Objects".
Guidelines for Managing Clusters
A cluster provides an optional method of storing table data. A cluster is co
mprised of a group of tables that share the same data blocks, which are grou
ped together because they share common columns and are often used together.
For example, the EMP and DEPT table share the DEPTNO column. When you cluste
r the EMP and DEPT tables (see Figure 15-1), Oracle physically stores all ro
ws for each department from both the EMP and DEPT tables in the same data bl
ocks. You should not use clusters for tables that are frequently accessed in
dividually.
Because clusters store related rows of different tables together in the same
 data blocks, properly used clusters offer two primary benefits:
Disk I/O is reduced and access time improves for joins of clustered tables.
The cluster key is the column, or group of columns, that the clustered table
s have in common. You specify the columns of the cluster key when creating t
he cluster. You subsequently specify the same columns when creating every ta
ble added to the cluster. Each cluster key value is stored only once each in
 the cluster and the cluster index, no matter how many rows of different tab
r how many rows of different tab
les contain the value.
Therefore, less storage might be required to store related table and index d
ata in a cluster than is necessary in non-clustered table format. For exampl
e, notice how each cluster key (each DEPTNO) is stored just once for many ro
ws that contain the same value in both the EMP and DEPT tables.
After creating a cluster, you can create tables in the cluster. However, bef
ore any rows can be inserted into the clustered tables, a cluster index must
 be created. Using clusters does not affect the creation of additional index
es on the clustered tables; they can be created and dropped as usual.
Figure 15-1 Clustered Table Data
The following sections describe guidelines to consider when managing cluster
s, and includes the following topics:
Cluster Appropriate Tables
Choose Appropriate Columns for the Cluster Key
Specify Data Block Space Use
Specify the Space Required by an Average Cluster Key and Its Associated Rows

Specify the Location of Each Cluster and Cluster Index Rows
Estimate Cluster Size and Set Storage Parameters
See Also: For more information about clusters, see Oracle8 Concepts.
Cluster Appropriate Tables
Use clusters to store one or more tables that are primarily queried (not pre
 tables that are primarily queried (not pre
dominantly inserted into or updated) and for which the queries often join da
ta of multiple tables in the cluster or retrieve related data from a single
table.
Choose Appropriate Columns for the Cluster Key
Choose cluster key columns carefully. If multiple columns are used in querie
s that join the tables, make the cluster key a composite key. In general, th
e characteristics that indicate a good cluster index are the same as those f
or any index.
A good cluster key has enough unique values so that the group of rows corres
ponding to each key value fills approximately one data block. Having too few
 rows per cluster key value can waste space and result in negligible perform
ance gains. Cluster keys that are so specific that only a few rows share a c
ommon value can cause wasted space in blocks, unless a small SIZE was specif
ied at cluster creation time (see below).
Too many rows per cluster key value can cause extra searching to find rows f
or that key. Cluster keys on values that are too general (for example, MALE
and FEMALE) result in excessive searching and can result in worse performanc
e than with no clustering.
A cluster index cannot be unique or include a column defined as LONG.
See Also: For information about characteristics of a good index, see "Guidel
ines for Managing Indexes".
Specify Data Block Space Use
Specify Data Block Space Use
By specifying the PCTFREE and PCTUSED parameters during the creation of a cl
uster, you can affect the space utilization and amount of space reserved for
 updates to the current rows in the data blocks of a cluster's data segment.
 Note that PCTFREE and PCTUSED parameters set for tables created in a cluste
r are ignored; clustered tables automatically use the settings set for the c
luster.
See Also: For more information about setting PCTFREE and PCTUSED, see "Manag
ing Space in Data Blocks".
Specify the Space Required by an Average Cluster Key and Its Associated Rows

The CREATE CLUSTER command has an optional argument, SIZE, which is the esti
mated number of bytes required by an average cluster key and its associated
rows. Oracle uses the SIZE parameter when performing the following tasks:
estimating the number of cluster keys (and associated rows) that can fit in
a clustered data block
limiting the number of cluster keys placed in a clustered data block; this m
aximizes the storage efficiency of keys within a cluster
SIZE does not limit the space that can be used by a given cluster key. For e
xample, if SIZE is set such that two cluster keys can fit in one data block,
 any amount of the available data block space can still be used by either of
 the cluster keys.
By default, Oracle stores only one cluster key and its associated rows in ea
ch data block of the cluster's data segment. Although block size can vary fr
om one operating system to the next, the rule of one key per block is mainta
ined as clustered tables are imported to other databases on other machines.
If all the rows for a given cluster key value cannot fit in one block, the b
locks are chained together to speed access to all the values with the given
key. The cluster index points to the beginning of the chain of blocks, each
of which contains the cluster key value and associated rows. If the cluster
SIZE is such that more than one key fits in a block, blocks can belong to mo
re than one chain.
Specify the Location of Each Cluster and Cluster Index Rows
If you have the proper privileges and tablespace quota, you can create a new
 cluster and the associated cluster index in any tablespace that is currentl
y online. Always specify the TABLESPACE option in a CREATE CLUSTER/INDEX sta
tement to identify the tablespace to store the new cluster or index.
The cluster and its cluster index can be created in different tablespaces. I
n fact, creating a cluster and its index in different tablespaces that are s
tored on different storage devices allows table data and index data to be re
trieved simultaneously with minimal disk contention.
Estimate Cluster Size and Set Storage Parameters
Following are benefits of estimating a cluster's size before creating it:
You can use the combined estimated size of clusters, along with estimates fo
r indexes, rollback segments, and redo log files, to determine the amount of
r indexes, rollback segments, and redo log files, to determine the amount of
 disk space that is required to hold an intended database. From these estima
tes, you can make correct hardware purchases and other decisions.
You can use the estimated size of an individual cluster to better manage the
 disk space that the cluster will use. When a cluster is created, you can se
t appropriate storage parameters and improve I/O performance of applications
 that use the cluster.
Whether or not you estimate table size before creation, you can explicitly s
et storage parameters when creating each non-clustered table. Any storage pa
rameter that you do not explicitly set when creating or subsequently alterin
g a table automatically uses the corresponding default storage parameter set
 for the tablespace in which the table resides. Clustered tables also automa
tically use the storage parameters of the cluster.
See Also: For information about estimating the size of schema objects, inclu
ding clusters, see Appendix A, "Space Estimations for Schema Objects".
Creating Clusters
This section describes how to create clusters, and includes the following to
pics:
Creating Clustered Tables
Creating Cluster Indexes
To create a cluster in your schema, you must have the CREATE CLUSTER system
privilege and a quota for the tablespace intended to contain the cluster or
the UNLIMITED TABLESPACE system privilege.
To create a cluster in another user's schema, you must have the CREATE ANY C
LUSTER system privilege and the owner must have a quota for the tablespace i
ntended to contain the cluster or the UNLIMITED TABLESPACE system privilege.

You can create a cluster using the SQL command CREATE CLUSTER. The following
 statement creates a cluster named EMP_DEPT, which stores the EMP and DEPT t
ables, clustered by the DEPTNO column:
CREATE CLUSTER emp_dept (deptno NUMBER(3))
   PCTUSED 80
   PCTFREE 5
   SIZE 600
   TABLESPACE users
   STORAGE (INITIAL 200k
      NEXT 300K
      MINEXTENTS 2
      MAXEXTENTS 20
      PCTINCREASE 33);
Creating Clustered Tables
To create a table in a cluster, you must have either the CREATE TABLE or CRE
ATE ANY TABLE system privilege. You do not need a tablespace quota or the UN
LIMITED TABLESPACE system privilege to create a table in a cluster.
You can create a table in a cluster using the SQL command CREATE TABLE with
er using the SQL command CREATE TABLE with
the CLUSTER option. The EMP and DEPT tables can be created in the EMP_DEPT c
luster using the following statements:
CREATE TABLE dept (
   deptno NUMBER(3) PRIMARY KEY, . . . )
   CLUSTER emp_dept (deptno);
CREATE TABLE emp (
   empno NUMBER(5) PRIMARY KEY,
   ename VARCHAR2(15) NOT NULL,
   . . .
   deptno NUMBER(3) REFERENCES dept)
   CLUSTER emp_dept (deptno);
----------------------------------------------------------------------------
----Note: You can specify the schema for a clustered table in the CREATE TAB
LE statement; a clustered table can be in a different schema than the schema
 containing the cluster.  --------------------------------------------------
------------------------------
Creating Cluster Indexes
To create a cluster index, one of the following conditions must be true:
Your schema contains the cluster and you have the CREATE INDEX system privil
ege.
You have the CREATE ANY INDEX system privilege.
In either case, you must also have either a quota for the tablespace intende
quota for the tablespace intende
d to contain the cluster index, or the UNLIMITED TABLESPACE system privilege
.
A cluster index must be created before any rows can be inserted into any clu
stered table. The following statement creates a cluster index for the EMP_DE
PT cluster:
CREATE INDEX emp_dept_index
   ON CLUSTER emp_dept
   INITRANS 2
   MAXTRANS 5
   TABLESPACE users
   STORAGE (INITIAL 50K
      NEXT 50K
      MINEXTENTS 2
      MAXEXTENTS 10
      PCTINCREASE 33)
   PCTFREE 5;
The cluster key establishes the relationship of the tables in the cluster. S
everal storage settings are explicitly specified for the cluster and cluster
 index.
See Also: See Chapter 21, Managing User Privileges and Roles for more inform
ation about system privileges, and Chapter 20, Managing Users and Resources
for information about tablespace quotas.

for information about tablespace quotas.
nt alters the EMP_DEPT cluster:
ALTER CLUSTER emp_dept
   PCTFREE 30
   PCTUSED 60;
Altering Cluster Tables and Cluster Indexes
You can alter clustered tables using the SQL command ALTER TABLE. However, a
ny data block space parameters, transaction entry parameters, or storage par
ameters you set in an ALTER TABLE statement for a clustered table generate a
n error message (ORA-01771, "illegal option for a clustered table"). Oracle
uses the parameters of the cluster for all clustered tables. Therefore, you
can use the ALTER TABLE command only to add or modify columns, or add, drop,
 enable, or disable integrity constraints or triggers for a clustered table.

----------------------------------------------------------------------------
----
Note:
When estimating the size of cluster indexes, remember that the index is on e
ach cluster key, not the actual rows; therefore, each key will only appear o
nce in the index.
----------------------------------------------------------------------------
----
Manually Allocating Storage for a Cluster
Oracle dynamically allocates additional extents for the data segment of a cl
uster as required. In some circumstances, however, you might want to allocat
e an additional extent for a cluster explicitly. For example, when using the
 Oracle Parallel Server, you can allocate an extent of a cluster explicitly
for a specific instance.
You allocate a new extent for a cluster using the SQL command ALTER CLUSTER
with the ALLOCATE EXTENT option.
See Also: For information about altering tables, see "Altering Tables".
You alter cluster indexes exactly as you do other indexes. For more informat
ion, see "Altering Indexes".
For more information about the CLUSTER parameter in the ALTER CLUSTER comman
d, see Oracle8 Parallel Server Concepts and Administration.
Dropping Clusters
This section describes aspects of dropping clusters, and includes the follow
ing topics:
Dropping Clustered Tables
Dropping Cluster Indexes
A cluster can be dropped if the tables within the cluster are no longer nece
ssary. When a cluster is dropped, so are the tables within the cluster and t
he corresponding cluster index; all extents belonging to both the cluster's
data segment and the index segment of the cluster index are returned to the
containing tablespace and become available for other segments within the tab
lespace.
lespace.
Dropping Clustered Tables
To drop a cluster, your schema must contain the cluster or you must have the
 DROP ANY CLUSTER system privilege. You do not have to have additional privi
leges to drop a cluster that contains tables, even if the clustered tables a
re not owned by the owner of the cluster.
Clustered tables can be dropped individually without affecting the table's c
luster, other clustered tables, or the cluster index. A clustered table is d
ropped just as a non-clustered table is dropped-with the SQL command DROP TA
BLE.
----------------------------------------------------------------------------
----
Note:
When you drop a single table from a cluster, Oracle deletes each row of the
table individually. To maximize efficiency when you intend to drop an entire
 cluster, drop the cluster including all tables by using the DROP CLUSTER co
mmand with the INCLUDING TABLES option. Drop an individual table from a clus
ter (using the DROP TABLE command) only if you want the rest of the cluster
to remain.
----------------------------------------------------------------------------
----
See Also: For information about dropping a table, see "Dropping Tables".
Dropping Cluster Indexes
A cluster index can be dropped without affecting the cluster or its clustere
d tables. However, clustered tables cannot be used if there is no cluster in
dex; you must re-create the cluster index to allow access to the cluster. Cl
uster indexes are sometimes dropped as part of the procedure to rebuild a fr
agmented cluster index.
To drop a cluster that contains no tables, and its cluster index, use the SQ
L command DROP CLUSTER. For example, the following statement drops the empty
 cluster named EMP_DEPT:
DROP CLUSTER emp_dept;
If the cluster contains one or more clustered tables and you intend to drop
the tables as well, add the INCLUDING TABLES option of the DROP CLUSTER comm
and, as follows:
DROP CLUSTER emp_dept INCLUDING TABLES;
If the INCLUDING TABLES option is not included and the cluster contains tabl
es, an error is returned.
If one or more tables in a cluster contain primary or unique keys that are r
eferenced by FOREIGN KEY constraints of tables outside the cluster, the clus
ter cannot be dropped unless the dependent FOREIGN KEY constraints are also
dropped. This can be easily done using the CASCADE CONSTRAINTS option of the
 DROP CLUSTER command, as shown in the following example:
DROP CLUSTER emp_dept INCLUDING TABLES CASCADE CONSTRAINTS;
Oracle returns an error if you do not use the CASCADE CONSTRAINTS option and
E CONSTRAINTS option and
 constraints exist.
See Also: For information about dropping an index, see "Dropping Indexes".
----------------------------------------------------------------------------
----
----------------------------------------------------------------------------

--
※ 来源:·BBS 水木清华站 bbs.net.tsinghua.edu.cn·[FROM: 162.105.41.166]
--
           海纳百川，
                   有容乃大，
                           壁立千尺，
                                   无欲则刚。    

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: dip.hit.edu.cn]