A discussion about tablespace allocation specification

A discussion about tablespace allocation specification

Round 1:

from wen xie
to ddd
date Thu, May 14, 2009 at 21:43
subject Re: 答复: 给看看有啥问题（表空间分配规范）
mailed-by googlemail.com

hide details 21:43 (10 minutes ago)


Reply

Follow up message


2009/5/14 ddd

1,数据文件命名贵发没法给你，正在写，发给你的也是今天下午写的

一般, 数据文件的前缀同表空间名, 同一个表空间的第一个编号01, 第二个编号02, 依此类推

还有什么更好的建议吗

2，临时表是指临时创建的表，

如何控制用户建表使用哪个表空间呢? 好像只能细分用户权限, 不同用户有不同权限, 可是你又不愿意建那么多的用户

3，请给出让表空间自动扩展的理由，如果是裸设备怎么自动扩展

你自己说的就是数据文件

如果是数据文件则可以. 在可控的空间范围内, 文件大小自动扩展, 兼顾空间使用率和可扩展性

如果是裸设备, 本来就扩展不了, 何必专门提出
另外, 没用过裸设备, 不知道如何扩展/收缩大小, 总觉得没文件方便

4，业务表达的近1000个，不可能将业务表部署在一个表空间上，这些修改较少的，主要是相对一些每天都大量修改的表，大量修改肯定会形成碎片，单独部署到表空间能确保其他少修改的表数据能规整些，如果全表扫描，也能降低访问次数

碎片定义1: 指表空间中存在的一些小的不连续的空闲空间, 由于太小, 无法被使用

使用盘区(extent)本地管理,自动分配大小, 即可解决此问题


碎片定义2: 指因为表空间中数据对象占用的空间不是一次性分配的,盘区是随着数据量增长,自动扩展分配的, 肯定要分配多个盘区, 所以造成了同一个数据对象的盘区的分布是不连续的

数据对象分配本来就是一个一个盘区分配的, 不可能是连续的, 除非表空间里只有一个数据对象, 或数据对象只分配了一个大的盘区
第一种情况(盘区是连续的): 也没有意义, 比如说全表扫描读取, 也是一个一个盘区读的(其实是多数据块读multiblock read), 效果跟不连续的是一样的, 所以连续的盘区并不能带来读写上的优势
第二种情况(单一的盘区, 或者较少数量的盘区): 8i以前的字典管理下, 较少的盘区可能会带来性能上的少许提高, 8i之后是本地管理, 再加上自动分配大小, 这不再是问题了.


碎片定义3: 数据块中有未被使用/不能使用的空间, 数据行是不连续的,存在于多个数据块内.
不写了.

这TMD都跟表空间命名规范/使用规范, 频繁不频繁,没一点儿关系.

估计你主要指的是第二种, 是不成立的

- Hide quoted text -

5，业务表所属表空间确实不适合使用数字编号，按业务或功能确实比较合适，




发件人: wen xie [mailto:xiewenxiewen at googlemail.com]
发送时间: 2009年5月14日 17:35
收件人: ddd
主题: Re: 给看看有啥问题（表空间分配规范）

1. 没有制定数据文件的命名规范, 也就是说没有考虑表空间对应的数据文件的规范


2. 临时表指的是什么, 临时创建的表, 还是oracle的临时表?
这个好像无法限制用户在哪个表空间创建

3. 表空间(其实应该是数据文件)应该设置为自动扩展, 但要设置一个最大大小, 以免疯狂扩展

4."数据量及增删较少，不会形成大量碎块，部署到单独表空间，能有效提高查询性能"
这就是你第4条"频繁更新的表和其它表部署在不同表空间上"的理由
但是理由不充分. 是什么?

表空间应使用自动分配管理, 基本上就可避免碎块

5. 以数字编号命名表空间不是个好的方法, 一个表空间多个数据文件的情况下数据文件才应该带上编号,
表空间按业务,功能区分即可, 分区表空间可按分区字段命名, 比如日期

2009/5/14 ddd
一、实施背景及目的

目前基本上所有系统，都只有一个表空间，系统对应用户下的所有表、索引及其他都全部建立在同一个表空间下，存在较大的安全及性能问题，随着业务的开展，数据量的急剧增加，数据的管理及共享方式也将受到影响，为了更好的提高数据库性能，有必要对表空间划分建立规范，新系统建立依照规范执行
二、实施基本原则

本规范实施中必须遵循的主要原则有：

1， 备份表和生产表必须分开在不同表空间上

2， 临时表单独建立在独立的表空间上

3， 基表和业务表分离在不同表空间上

4， 频繁更新的表和其它表部署在不同表空间上

5， 日志表单独部署表空间

6， 超大表采用分区表方式，部署在不同表空间上

7， 索引和表对应，基表对应基表索引表空间，频繁更新表的索引单独部署表空间

8， 表空间数据文件不能自动扩展（asm除外）
三、数据库表空间划分

按照表空间的功能进行划分建立

1， 基表所属表空间

命名规则：系统简称_+BASE

用途：用于保存所有基础表，由于基础表数据量及增删较少，不会形成大量碎块，部署到单独表空间，能有效提高查询性能

2， 业务表所属表空间

命名规则：系统简称_+DATA+编号（01，02….）

用途：用于保存部分业务表，业务表数据的增长情况

3， 频繁更新表所属表空间

命名规范：系统简称_+DATA+

用途：由于频繁更新，导致表空间碎片增加，通过将表独立部署到单独表空间，能提高其他表数据的规整性，有效提高性能

4， 日志表所属表空间

命名规则：系统简称_+LOG+编号（01，02….）

用途：用于保存业务系统各个日志表数据，日志表单独部署，可以

5， 超大表分区表空间

命名规则：系统简称_+PART+编号（01，02….）

用途：用于保存业务系统各个超大表分区数据

6， 索引表空间和数据所属表空间一一对应

命名规则：系统简称_+IDX_+PART+编号（01，02….）

用途：用于保存各个表表空间中表的索引数据，索引空间和表空间一一对应，确保早迁



Continued

from wen xie
to ddd
date Fri, May 15, 2009 at 12:24
subject Re: 答复: Re:
mailed-by googlemail.com

hide details 12:24 (18 hours ago)


Reply

Follow up message

http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/instance_tune.htm
10.3.4 db file sequential read

This event signifies that the user process is reading a buffer into the SGA buffer cache and is waiting for a physical I/O call to return. A sequential read is a single-block read.

Single block I/Os are usually the result of using indexes. Rarely, full table scan calls could get truncated to a single block call due to extent boundaries, or buffers already present in the buffer cache. These waits would also show up as 'db file sequential read'.


等我有时间再做个实验证实一下!

- Hide quoted text -


2009/5/15 ddd

我得学习学习了，需要确认一下你说的到底有没有问题，没有骗人吧？如果extent只有128k，那么db_file_multiblock_read_count设置再大也没有用？在哪记载？



临时表特指数据库中创建的用于清单报表打印、业务中间处理、关联系统数据同步、上传和下载中间处理的，不需长期保存，且表或数据清除后不影响业务的表。





发件人: wen xie [mailto:xiewenxiewen at googlemail.com]
发送时间: 2009年5月15日 10:08
收件人: ddd
主题: Re:

多数据块读不能跨盘区, 即最多读取的数量等于: db_file_multiblock_read_count和extent两者取一个最大值

2009/5/15 ddd

这个应该有影响因素吧？

如果我将db_file_multiblock_read_count设为64，一次读取64块，将近1m的数据，表的extent大小为65k，那么如果这16个extent都是一个表数据，全表扫描是否16个extent一次性读取；

而当这16个extent包含多个表数据并且互相交叉，是否要多次访问才能将某个表数据都取出：







碎片定义1: 指表空间中存在的一些小的不连续的空闲空间, 由于太小, 无法被使用

使用盘区(extent)本地管理,自动分配大小, 即可解决此问题


碎片定义2: 指因为表空间中数据对象占用的空间不是一次性分配的,盘区是随着数据量增长,自动扩展分配的, 肯定要分配多个盘区, 所以造成了同一个数据对象的盘区的分布是不连续的

数据对象分配本来就是一个一个盘区分配的, 不可能是连续的, 除非表空间里只有一个数据对象, 或数据对象只分配了一个大的盘区
第一种情况(盘区是连续的): 也没有意义, 比如说全表扫描读取, 也是一个一个盘区读的(其实是多数据块读multiblock read), 效果跟不连续的是一样的, 所以连续的盘区并不能带来读写上的优势
第二种情况(单一的盘区, 或者较少数量的盘区): 8i以前的字典管理下, 较少的盘区可能会带来性能上的少许提高, 8i之后是本地管理, 再加上自动分配大小, 这不再是问题了.


碎片定义3: 数据块中有未被使用/不能使用的空间, 数据行是不连续的,存在于多个数据块内.
不写了.

这TMD都跟表空间命名规范/使用规范, 频繁不频繁,没一点儿关系.

估计你主要指的是第二种, 是不成立的



Round 2:

from wen xie
to ddd
date Fri, May 15, 2009 at 22:57
subject Re: 答复: 答复: 答复: 你觉得频繁更新表的表空间不需要建立？
mailed-by googlemail.com

hide details 22:57 (7 hours ago)


Reply

Follow up message


2009/5/15 ddd

呵呵，

1，运维用户确实只应该只对备份表空间有配额

2，DBLINK 可能其他人维护，如果没有一个配额，若想临时备份数据，备份到哪？

你的DBLINK用户是做什么的?

- Hide quoted text -

3，对于管理用户，我现在真的没想好，一直使用system或sys对数据库做管理，就他妈我一个人，建多个用户干什么用，



发件人: wen xie [mailto:xiewenxiewen@googlemail.com]
发送时间: 2009年5月15日 17:04
收件人: ddd
主题: Re: 答复: 答复: 你觉得频繁更新表的表空间不需要建立？

那么运维用户应该只对备份表空间有配额, 其它表空间无配额. 你写的是所有表空间用户的配额都一样, 是不对的

数据库连接用户就是建立数据库连接和视图和授权的, 这些都不占用用户表空间,不需要配额
你后面说的我没看懂, 什么同义词备份, 原表无法操作?

管理用户如果是system, 你竟然限制它使用1G? 而且system具有dba角色, 拥有unlimited tablespace系统权限, 你没限制住.

2009/5/15 ddd

运维用户肯定需要的，修改数据前需要对表备份,dblink用户一般情况是不需要用，一般通过建同义词使用，但现在有时可能真有对同义词数据进行保存操作，原表无法操作，那么只好对同义词查询的数据进行备份

管理用户实际不需要太大的空间，我个人理解管理用户应该就是system，不单独建用户



发件人: wen xie [mailto:xiewenxiewen at googlemail.com]

发送时间: 2009年5月15日 13:12
收件人: ddd
主题: Re: 答复: 你觉得频繁更新表的表空间不需要建立？

运维用户需要建表吗? dblink用户肯定是不用的. 管理用户为什么只有1G?

2009/5/15 ddd

2，我的目的就是控制不让某个用户大量建表并插入数据，如果配额等于0，当真有需要空间，那不歇菜了？



发件人: wen xie [mailto:xiewenxiewen at googlemail.com]
发送时间: 2009年5月15日 12:36
收件人: ddd
主题: Re: 你觉得频繁更新表的表空间不需要建立？

1.单独放到另一个磁盘上, 可能更有用处

2. 配额管理只对表的所有者有效. 比如有表scott.depts, 你给scott用户限额是无限, 给运维用户a限额为1m, 用户a有对scott.depts的操作权限, 那么用户a对表scott.depts的空间使用也是无限的, 只有它自己建的表才不能超过1m.
因此你的目的完全没有达到, 还不如对其它用户不授予任何空间配额, 即配额等于0

3.先写这么多

2009/5/15 ddd
一、实施背景及目的

目前基本上所有系统，都只有一个表空间，系统对应用户下的所有表、索引及其他都全部建立在同一个表空间下，存在较大的安全及性能问题，随着业务的开展，数据量的急剧增加，数据的管理及共享方式也将受到影响，为了更好的提高数据库性能，有必要对表空间划分建立规范，新系统建立依照规范执行
二、实施基本原则

本规范实施中必须遵循的主要原则有：

1， 备份表和生产表必须分开在不同表空间上

2， 基表和业务表分离在不同表空间上

3， 业务表根据功能划分部署到不同表空间上

4， 频繁更新的表和其它表部署在不同表空间上

5， 日志表单独部署表空间

6， 超大表采用分区表方式，部署在不同表空间上

7， 索引和表对应，基表对应基表索引表空间，频繁更新表的索引单独部署表空间

8， 表空间数据文件不能自动扩展（asm除外）
三、数据库表空间划分

按照表空间的功能进行划分建立

1， 基表所属表空间

命名规则：系统简称_+BASE

用途：用于保存所有基础表，由于基础表数据量及增删较少，不会形成大量碎块，部署到单独表空间，能有效提高查询性能

2， 业务表所属表空间

命名规则：系统简称_+功能

用途：用于保存部分业务表，根据业务功能划分表空间，同一功能业务表部署到同一表空间中

3， 频繁更新表所属表空间

命名规范：系统简称_+DATA

用途：由于频繁更新，导致表空间碎片增加，通过将表独立部署到单独表空间，能提高其他表数据的规整性，有效提高性能

4， 日志表所属表空间

命名规则：系统简称_+LOG

用途：用于保存业务系统各个日志表数据

5， 备份表所属表空间

命名规则：系统简称_+BAK

用途：用于保存数据修改是需要对表备份形成的备份表及临时表



6， 超大表分区表空间

命名规则：系统简称_+PART+分区字段，如系统简称+PART+时间

用途：用于保存业务系统各个超大表分区数据

7， 索引表空间和数据所属表空间一一对应

命名规则：对因数据表空间名称 + IDX

用途：用于保存各个表空间中表的索引数据，索引空间和表空间一一对应


四、各表空间分配原则及规范

1，基础表空间对中间件用户的配额为无限制，对运维修改用户、DBLINK及管理用户配额为1G

2，业务表空间对中间件用户的配额为无限制，对运维修改用户、DBLINK及管理用户配额为1G

3，备份表空间对运维修改用户的配额为无限制，对中间件用户、DBLINK及管理用户配额为1G

4，日志表空间对中间件用户的配额为无限制，对运维修改用户、DBLINK及管理用户配额为1G

5，索引表空间对中间件用户的配额为无限制，对运维修改用户、DBLINK及管理用户配额为1G

6，分区表空间对中间件用户的配额为无限制，对运维修改用户、DBLINK及管理用户配额为1G


五、各表空间数据文件建立原则及规范

1，操作系统为32位，采用文件系统方式建立表空间的，每个数据文件大小不超过2G

2，操作系统为32位，采用裸设备作为数据文件建立表空间的，每个裸设备一般设置为5G，最大不超过10G

3，操作系统为64位，采用文件系统方式建立表空间的，每个数据文件大小为5G

4，操作系统为64位，采用裸设备作为数据文件建立表空间的，每个裸设备大小一般设置为10G，最大不超过20G
六、各表空间数据文件命名规范

1，采用文件系统方式建立表空间的，数据文件命名采用：

数据文件命名：表空间名 +编号 （01，02 。。。）+..dbf

2，采用裸设备作为数据文件建立表空间的，需要采用链接将裸设备指定到相应目录，具体目录参照数据库软件安装规范，裸设备命名采用：

数据文件命名：表空间名 +编号 （01，02 。。。）







-fin-