关于 oracle 数据库表空间设计及本分数据库的问题

[erwei1983]

oracle数据库的表空间设计原则是什么，在网上看了一些资料，有的建议多分几个表空间，有的则不建议，比较迷茫。
例如：一个管理系统，有自己SYS_开头的系统表，我想系统表放到一个表空间中，然后业务表存放一个表空间，索引再放一个表空间，这就需要3个表空间，这样好不好？还有表空间和临时表空间需要几个，如果这个管理系统需要3个表空间的话，那是不是还需要创建3个临时表空间，还是只需要一个临时表空间就可以了。
如果多个表空间的话，对数据库备份和维护会带来哪些麻烦。如何备份oracle数据库比较好，是每天生成dmp文件然后备份，还是有别的更好的方法。感觉dmp文件备份不好，数据恢复也很麻烦。
有没有什么工具备份数据库，例如jenkins打包发布类似备份数据库的工具啊。

[erwei1983]

怎么没人回答我的问题啊

[minsic78]

如果你的底层存储在一起，而且数据并不是很大很大很大，比如超过了单个表空间的最大空间限制，那么放不放在一起无所谓，如果你底层的磁盘不在一起，打个比方，一个文件系统是单独磁盘（非磁阵上的LUN，但其实现在的数据库服务器除非用SSD，否则不用磁阵是没法玩的），那么分表空间存储也许还是有点用的

[erwei1983]

引用 2 楼 minsic78 的回复:

如果你的底层存储在一起，而且数据并不是很大很大很大，比如超过了单个表空间的最大空间限制，那么放不放在一起无所谓，如果你底层的磁盘不在一起，打个比方，一个文件系统是单独磁盘（非磁阵上的LUN，但其实现在的数据库服务器除非用SSD，否则不用磁阵是没法玩的），那么分表空间存储也许还是有点用的

那是不是数据量不大的话，没必要分表空间啊，一个表空间就可以了。
是有是不是把索引单独放在一个表空间比较好啊，那样两个表空间就可以搞定啦。

[minsic78]

引用 3 楼 erwei1983 的回复:

[quote=引用 2 楼 minsic78 的回复:]
如果你的底层存储在一起，而且数据并不是很大很大很大，比如超过了单个表空间的最大空间限制，那么放不放在一起无所谓，如果你底层的磁盘不在一起，打个比方，一个文件系统是单独磁盘（非磁阵上的LUN，但其实现在的数据库服务器除非用SSD，否则不用磁阵是没法玩的），那么分表空间存储也许还是有点用的

那是不是数据量不大的话，没必要分表空间啊，一个表空间就可以了。
是有是不是把索引单独放在一个表空间比较好啊，那样两个表空间就可以搞定啦。
[/quote]
其实没什么必要，而且建索引的时候，很多人是没有习惯添加tablespace参数指定到用户的非默认表空间的，尤其在开发测试环境。如果想管理上清晰点，分开也可。

[学海无涯-回头是岸]

数据表空间和索引表空间 分开吧，undo不用了

[卖水果的net]

多个表空间，可以把数据分布到多个磁盘上，但如果只有一个物料磁盘，分不分的，对性能影响不大，可以忽略。

临时表空间一个就够了， 也只能有一个。这个是按用户来的。

备份，生产环境，要用 rman 或 第三方的工具（其实也是 调用 rman）

jenkins 是发布用的，和备份数据库，是两种工作。

[erwei1983]

引用 9 楼 minsic78 的回复:

备份恢复无论选择哪一种方式都不会方便的，rman的问题其实不在于命令的复杂性，而在于备份存储是要花钱的……

为啥还要花钱啊，rman不是数据库自己带的吗？
你们的数据库都是怎么备份恢复啊。
我原来的数据库是这样备份的，看看是否可行：每天凌晨生产数据库通过exp命令生产，并放到一个指定文件夹下，这台服务器会开启ftp服务。
另一台服务器定时会去生产设备的机器上通过ftp把生产的dmp文件取过来放到一个位置，后缀加上时间日期，然后保留三天的dmp文件，其实全量备份，三天的dmp文件基本也没啥区别，保留一个也可以。

[erwei1983]

引用 5 楼 baidu_36457652 的回复:

数据表空间和索引表空间 分开吧，undo不用了

我想问一下，undo表空间是必须建的吗？还是要不要都可以啊，以前还真注意过这个表空间，因为本人不是DBA，所有比较茫然啊。
如果算上undo表空间，那我就要建三个表空间啦：undo表空间、索引表空间、除索引外其他存储的表空间。

[yaiger]

数据量不大的话随便建，没那么讲究

[minsic78]

引用 10 楼 erwei1983 的回复:

[quote=引用 9 楼 minsic78 的回复:]
备份恢复无论选择哪一种方式都不会方便的，rman的问题其实不在于命令的复杂性，而在于备份存储是要花钱的……

为啥还要花钱啊，rman不是数据库自己带的吗？
你们的数据库都是怎么备份恢复啊。
我原来的数据库是这样备份的，看看是否可行：每天凌晨生产数据库通过exp命令生产，并放到一个指定文件夹下，这台服务器会开启ftp服务。
另一台服务器定时会去生产设备的机器上通过ftp把生产的dmp文件取过来放到一个位置，后缀加上时间日期，然后保留三天的dmp文件，其实全量备份，三天的dmp文件基本也没啥区别，保留一个也可以。[/quote]

rman备份通常要比dmp文件大，而且为了保证数据能够恢复，可能需要2份以上的全备和N多个增量备份，对磁盘空间的要求更多，现在的库太大了，为了不影响正常的业务，也对rman备份的速度有一定的要求，也就是说，备份盘的性能也需要考虑，这些都是钱啊～～～

[minsic78]

引用 14 楼 minsic78 的回复:

[quote=引用 10 楼 erwei1983 的回复:]
[quote=引用 9 楼 minsic78 的回复:]
备份恢复无论选择哪一种方式都不会方便的，rman的问题其实不在于命令的复杂性，而在于备份存储是要花钱的……

为啥还要花钱啊，rman不是数据库自己带的吗？
你们的数据库都是怎么备份恢复啊。
我原来的数据库是这样备份的，看看是否可行：每天凌晨生产数据库通过exp命令生产，并放到一个指定文件夹下，这台服务器会开启ftp服务。
另一台服务器定时会去生产设备的机器上通过ftp把生产的dmp文件取过来放到一个位置，后缀加上时间日期，然后保留三天的dmp文件，其实全量备份，三天的dmp文件基本也没啥区别，保留一个也可以。[/quote]

rman备份通常要比dmp文件大，而且为了保证数据能够恢复，可能需要2份以上的全备和N多个增量备份，对磁盘空间的要求更多，现在的库太大了，为了不影响正常的业务，也对rman备份的速度有一定的要求，也就是说，备份盘的性能也需要考虑，这些都是钱啊～～～[/quote]

当然dmp也需要磁盘空间，但凡可以用dmp文件来做备份的，我是这么理解的：那么这个库的重要性其实是打折扣的，当然省钱不在话下了……

[学海无涯-回头是岸]

引用 11 楼 erwei1983 的回复:

[quote=引用 5 楼 baidu_36457652 的回复:]
数据表空间和索引表空间 分开吧，undo不用了

我想问一下，undo表空间是必须建的吗？还是要不要都可以啊，以前还真注意过这个表空间，因为本人不是DBA，所有比较茫然啊。
如果算上undo表空间，那我就要建三个表空间啦：undo表空间、索引表空间、除索引外其他存储的表空间。[/quote]
undo是创建数据库自带的，一个实例只能一个。临时表空间可以多个，索引可以放在单独的盘上建表空间。其它数据表空间，看需求多少个

[erwei1983]

引用 6 楼 wmxcn2000 的回复:

多个表空间，可以把数据分布到多个磁盘上，但如果只有一个物料磁盘，分不分的，对性能影响不大，可以忽略。

临时表空间一个就够了， 也只能有一个。这个是按用户来的。

备份，生产环境，要用 rman 或 第三方的工具（其实也是 调用 rman）

jenkins 是发布用的，和备份数据库，是两种工作。

我查了一下资料，rman备份怎么看着比dmp要复杂的多啊，不过可以增量备份，感觉还是没看懂rman，不知道rman的好处在哪里，
看着蛮复杂的，大神能不能说一下，这个rman好处在哪里，具体怎么操作啊

[卖水果的net]

RMAN 备份的颗粒度可以控制。大到整个数据库，小到一个数据块。

expdp 和 exp 只是一照相的功能，只是当时的个状态， 而 rman 增量备份，实点还原，都是可以实现的。

[minsic78]

备份恢复无论选择哪一种方式都不会方便的，rman的问题其实不在于命令的复杂性，而在于备份存储是要花钱的……

[erwei1983]

大神们，我又遇到一个问题啊，数据库的字符集的问题。什么字符集比较好啊，AMERICAN_AMERICA.ZHS16GBK还是
SIMPLIFIED CHINESE_CHINA.AL32UTF8 我看了一下，我们其他项目的都是AMERICAN_AMERICA.ZHS16GBK，plsql客户端字符集也改成这个AMERICAN_AMERICA.ZHS16GBK了，如果这个项目数据库我改成SIMPLIFIED CHINESE_CHINA.AL32UTF8，那我的plsql岂不是就不能用了，中文会成为乱码。
我比较倾向于UTF8，因为项目现在都是utf-8的编码。

[minsic78]

引用 17 楼 erwei1983 的回复:

大神们，我又遇到一个问题啊，数据库的字符集的问题。什么字符集比较好啊，AMERICAN_AMERICA.ZHS16GBK还是
SIMPLIFIED CHINESE_CHINA.AL32UTF8 我看了一下，我们其他项目的都是AMERICAN_AMERICA.ZHS16GBK，plsql客户端字符集也改成这个AMERICAN_AMERICA.ZHS16GBK了，如果这个项目数据库我改成SIMPLIFIED CHINESE_CHINA.AL32UTF8，那我的plsql岂不是就不能用了，中文会成为乱码。
我比较倾向于UTF8，因为项目现在都是utf-8的编码。

AL32UTF8是GBK的完全超集，数据库能够转换，不用担心。但问题在于plsql developer，这玩意总是会自作主张做一些莫名的转换，其他客户端，比如TOAD，比如sqlplus，只要设置好NLS_LANG变量就无问题。

你的客户端NLS_LANG的设置，其实要跟客户端所在操作系统的编码一致，因为我们基本用中文windows，所以这个值应该设置成GBK，这和数据库端的字符集是GBK还是UTF8没有关系，这个变量实际上是告诉数据库：我这边的字符集是GBK，你需要把我存入数据库的字符从GBK转成你要的UTF8，读取的时候也是如此运作。