第10章 管理表

1. rowid:Oracle数据库中的每一行都有一个唯一的rowid

当一个用户往oracle数据库的表中插入一行数据时,oracle就会自动地在这一行数据上加上一个ROWID,在一个oralce数据库中每一行都有一个唯一标识的ROWIDoracle系统就是利用它来定位数据行的,ROWID也是oracle数据库提供的一个内置的标量数据类型。

 a)rowid的特性:

   1)rowid是数据库中每一行的唯一标识符;

   2)rowid并不显示地存储为一行的值;

   3)rowid可以被用来定位行;

   4)rowid提供了访问一个表中一行数据的最快的机制;

2. Oracle创建表时应遵守的原则:

 1)将不同的表放在不同的表空间中;

 2)使用本地管理表空间以避免碎片;

 3)在表中使用若干标准extent尺寸以减少表空间的碎片

3. 引入临时表的原因

当需要对某一(也可以是几个)表中的一批数据进行反复的操作时,通过为这批数据创建一个临时表可能会简化操作并提高效率。

4. 怎样动态改变存储参数(可以动态的修改PCTFREEPCTUSED这两个参数)

Alter table scott.product

PCTFREE 20

PCTUSED 50;

5. 怎样移动非分区表(查看所要移动的表的索引,然后将表移到要求表空间中,然后重建索引)

ALTER TABLE SCOTT.EMP

MOVE TABLESPACE USERS

6. 移动非分区表之后的相关索引的维护

ALTER INDEX SCOTT.PK_EMP REBUILD TABLESPACE INDX

7. 怎样重命名表中的一列

ALTER TABLE 用户名.列名

RENAME COLUMN 旧名

TO 新列名

限制:如果所要改名的列上有索引,则不能修改,除非删除索引

重新命名表中的一列的副作用及解决办法

列名修改后,基于该表的视图,触发器,函数,过程,软件包等的状态都将无效,需要重新编译

解决方法:可以通过创建视图或在输出结果时使用别名来代替

8. 怎样在一个表中删除一列

ALTER TABLE 用户名.表名

DROP COLUMN 列名

CASCADE CONSTRAINTS CHECKPOINT 行数

在一个表中删除一列时可能对系统造成的冲击

在一个表中删除一列,特别是在一个大表中删除一列是相当耗时的,并且需大量的还原磁盘空间,因此对系统的效率冲击很大,所以应该尽可能的避免在数据库繁忙期间使用删除列语句。

9. 怎样在一个表中把某一列设置成无用

ALTER TABLE 用户名.表名

SET UNUSED 列名 CASCADE CONSTRAINTS

10. 怎样删除已经设置成无用的列

ALTER TABLE 用户名.表名

DROP UNUSED COLUMN CHECKPOINT 行数

11. 把某一列设置成无用时要注意的事项

  1)该选项只能在oracle8i和以上版本使用

  2)只能在设置成无用的列标上做记号,并不能真的删除这一列  

  3)设置成无用的列无法用SQL*Plus命令或SQL语句看到

  4)Oracle把设置能无用的列当做删除列处理

  5)可以把一列也可以把多列设置成无用

  6)可以使用DROP列名选项来删除被设置成无用的列

  7)因为该语句是一个DDL语句,所以没有恢复无用列的命令

12. 在一个表中删除一列时使用CHECKPOINT选项

使用该选项来减少还原磁盘空间的使用量,CHECKPOINT 500表明oracle每做了500行的操作就会产生一个检查点,如果在该命令执行期间系统崩溃了,当重启系统后该命令可以从检查点开始继续它的工作,而不必重新开始,可以使用如下命令:

ALTER TABLE 用户名.表名 DROP COLUMNS CONTINUE

表的截断和删除时要注意的问题

这两个语句都是DDL语句,因此是不能回滚的,建议在使用这两个语句之前先做好备份

13. TRUNCATE TABLE语句的特性

 1)删除表中所有的数据行,但保留表的结构

 2)对应的索引也被截断

 3)因为该语句为DDL语句,所以不会产生还原数据,所删除的数据也无法恢复

 4)该语句释放表所占的磁盘空间

 5)并不触发表的删除触发器

 6)如果一个表正在被一个外键所引用,该表不能截断。

14. DROP TABLE语句的特性

 1)删除表中的所有的数据行和表的结构

 2)删除表中的所有索引

 3)如果没有备份,所删除的表无法恢复

 4)该语句释放表所使用extent

 5)提交所有挂起的事务

 6)所有基于该表的视图和别名依然保留但已失效。

原文地址:https://www.cnblogs.com/kangxuebin/p/2822486.html