17,377
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
inthirties 2009-07-30
- 打赏
- 举报
大家对于讨论性的贴，如果以前有接触过的，可以多多谈谈自己的想法。每个人有每个人的看法，通过集中的讨论，如果个人的想法还是一斑窥豹的话，那么大家的理解体会集中起来，虽做不到一概而全，但是也是可以汇集成更多的面的
无·法 2009-07-30
- 打赏
- 举报
不懂，帮顶
inthirties 2009-07-30
- 打赏
- 举报
ASM的确是新的技术，RAW的历史悠久，是老式的一种提高性能和实现RAC的传统方式，多年的生产线考验下来的技术，在其成熟性上，当然是一些生产系统的选择考虑的方面之一，但是RAW也有其不足，这也是Oracle，综合file system和RAW的优点，提出ASM技术解决方案的初衷和目标。
当然对于一个新的技术来说(其实ASM也不算是很新了，毕竟也出来有几年了)，大家更多的是对其成熟度的顾虑，不过，试问一下，又有哪家的小孩出生就可以想成人一样快意的奔跑了，不过，这个名为
ASM的Oracle的小孩，却是含着无比的关注和优良的基因而生的。
让我们一起看着它能够快速的成长为肆意在存储解决方案的领域里领跑的人物。
当然对于一个新的技术来说(其实ASM也不算是很新了，毕竟也出来有几年了)，大家更多的是对其成熟度的顾虑，不过，试问一下，又有哪家的小孩出生就可以想成人一样快意的奔跑了，不过，这个名为
ASM的Oracle的小孩，却是含着无比的关注和优良的基因而生的。
让我们一起看着它能够快速的成长为肆意在存储解决方案的领域里领跑的人物。
傻儿哥 2009-07-30
- 打赏
- 举报
ASM是教新的概念,感觉我接触的大的生产系统基本都还是用raw方式来存储数据的.
ASM的优点比较明显,就是可以动态的增删磁盘,而且读写效率和raw在一个数量级别,
ASM还可以把磁盘读写均衡的分摊到他的diskgroup中.
ASM还有一个优点,在RAC环境下做归档或者快闪的时候,RAW环境下一般需要NFS 挂载文件系统来解决.
有了ASM,可以把归档空间还有快闪目的地都指向ASM.
ASM有一个大的缺点,我想这应该是一个很多生产系统都不敢用它的原因,就是它是基于ASM INSTANCE的,
如果这个instance挂掉了,那么所有数据都完了.
ASM的优点比较明显,就是可以动态的增删磁盘,而且读写效率和raw在一个数量级别,
ASM还可以把磁盘读写均衡的分摊到他的diskgroup中.
ASM还有一个优点,在RAC环境下做归档或者快闪的时候,RAW环境下一般需要NFS 挂载文件系统来解决.
有了ASM,可以把归档空间还有快闪目的地都指向ASM.
ASM有一个大的缺点,我想这应该是一个很多生产系统都不敢用它的原因,就是它是基于ASM INSTANCE的,
如果这个instance挂掉了,那么所有数据都完了.
majy 2009-07-29
- 打赏
- 举报
下面再来一段，oracle公司极力推荐使用bigfile，每一个tablespace只用一个datafile，这样可以更好的使用好64位操作系统的威力：
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/physical.htm#sthref485
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/physical.htm#sthref485
suncrafted 2009-07-29
- 打赏
- 举报
关注
majy 2009-07-29
- 打赏
- 举报
关于ASSM，给你一段oracle公司最权威的专家的原话：
Auto segment management just automates the process by which you used to have to manually
tune using multiple freelists. In the past, you would have had to of determine the
number of concurrent modifiers of data (inserts/updates that happen exactly at about the
same time) and configure multiple freelists in order to satisfy these concurrent requests
in a timely fashion.
With auto management you don't have to do this anymore. It'll not distribute across
multiple blocks any more then multiple freelists would have in the past -- only you need
not waste your time and energy attempting to determine the exact correct number of
freelists to have.
This new feature is more efficient then multiple freelists:
<quote>
Free lists have been the traditional method of managing free space within segments.
Bitmaps, however, provide a simpler and more efficient way of managing segment space.
They provide better space utilization and completely eliminate any need to specify and
tune the PCTUSED, FREELISTS, and FREELISTS GROUPS attributes
for segments created in the tablespace. If such attributes should be specified, they are
ignored.
</quote>
a very informal, quick and dirty test I've done shows that automatic segment space mgmt
gives us almost all of the benfit of finely tuned freelists -- without the pain of finely
tuning freelists (something that is virtually impossible to do in the "real world"
anyway).
Go for it -- on a heavy OLTP type table -- this is very beneficial.
Auto segment management just automates the process by which you used to have to manually
tune using multiple freelists. In the past, you would have had to of determine the
number of concurrent modifiers of data (inserts/updates that happen exactly at about the
same time) and configure multiple freelists in order to satisfy these concurrent requests
in a timely fashion.
With auto management you don't have to do this anymore. It'll not distribute across
multiple blocks any more then multiple freelists would have in the past -- only you need
not waste your time and energy attempting to determine the exact correct number of
freelists to have.
This new feature is more efficient then multiple freelists:
<quote>
Free lists have been the traditional method of managing free space within segments.
Bitmaps, however, provide a simpler and more efficient way of managing segment space.
They provide better space utilization and completely eliminate any need to specify and
tune the PCTUSED, FREELISTS, and FREELISTS GROUPS attributes
for segments created in the tablespace. If such attributes should be specified, they are
ignored.
</quote>
a very informal, quick and dirty test I've done shows that automatic segment space mgmt
gives us almost all of the benfit of finely tuned freelists -- without the pain of finely
tuning freelists (something that is virtually impossible to do in the "real world"
anyway).
Go for it -- on a heavy OLTP type table -- this is very beneficial.
quiettown 2009-07-29
- 打赏
- 举报
感谢热心回复。
我想知道的是：
1. ASM对性能有没有什么影响，管理成本是比以前多了还是少了。
2. BIGFILE和SMALLFILE楼上也有兄弟说了，SMAILLFILE的CHECKPOINT有增多，可能比BIGFILE开销大。
3. 网上还有贴说创建BigFile，就会有很大的inode locking issues，使用单个TEMPFILE会影响查询性能等。俄想要个相对完整的输出。。。
我想知道的是：
1. ASM对性能有没有什么影响，管理成本是比以前多了还是少了。
2. BIGFILE和SMALLFILE楼上也有兄弟说了，SMAILLFILE的CHECKPOINT有增多，可能比BIGFILE开销大。
3. 网上还有贴说创建BigFile，就会有很大的inode locking issues，使用单个TEMPFILE会影响查询性能等。俄想要个相对完整的输出。。。
majy 2009-07-29
- 打赏
- 举报
ASM是一种管理方式，oracle9i以后，被强烈推荐使用。我们100G大小的数据库，自从用了这个，从来不用去关心索引重建之类的事情了
关于sallfile和bigfile，其实是要看你的磁盘设计的，如果就是一个普通的大磁盘，那效果是没什么区别的，如果你用的是 磁盘陈列，并且做了条块化(stripping），那么，取一个合适的文件大小就有关系了，我和oracle公司的技术人员讨论过，他们一般推荐每一个文件4－8G是比较合适的
关于sallfile和bigfile，其实是要看你的磁盘设计的，如果就是一个普通的大磁盘，那效果是没什么区别的，如果你用的是 磁盘陈列，并且做了条块化(stripping），那么，取一个合适的文件大小就有关系了，我和oracle公司的技术人员讨论过，他们一般推荐每一个文件4－8G是比较合适的
inthirties 2009-07-29
- 打赏
- 举报
[Quote=引用 13 楼 inthirties 的回复:]
个人觉得bigfile对性能没有好处，只有坏处。
不过这里提到的database open倒是有可能会好一些，
checkpoint会提高，就有些不明白了。
[/Quote]
checkpoint会提高，就有些不明白了。
难道是如果多个datafile的话，checkpoint会去同步后比较然后在确认，还是？？？
个人觉得bigfile对性能没有好处，只有坏处。
不过这里提到的database open倒是有可能会好一些，
checkpoint会提高，就有些不明白了。
[/Quote]
checkpoint会提高，就有些不明白了。
难道是如果多个datafile的话，checkpoint会去同步后比较然后在确认，还是？？？
inthirties 2009-07-29
- 打赏
- 举报
个人觉得bigfile对性能没有好处，只有坏处。
不过这里提到的database open倒是有可能会好一些，
checkpoint会提高，就有些不明白了。
不过这里提到的database open倒是有可能会好一些，
checkpoint会提高，就有些不明白了。
ngx20080110 2009-07-29
- 打赏
- 举报
smallfile和bigfile各有各的好處。
smallfile在管理方面更有靈活性。
如果一個tablespace要儲存巨大的數据(TB級別的)，那麽就用bigfile吧，因爲用smallfile來保存的話，要用很多個smallfile，這樣會增加checkpoint時的IO操作。
ps.對ASM還不是很熟悉，不討論了。
smallfile在管理方面更有靈活性。
如果一個tablespace要儲存巨大的數据(TB級別的)，那麽就用bigfile吧，因爲用smallfile來保存的話，要用很多個smallfile，這樣會增加checkpoint時的IO操作。
ps.對ASM還不是很熟悉，不討論了。
csuxp2008 2009-07-29
- 打赏
- 举报
继续顶
quiettown 2009-07-29
- 打赏
- 举报
感谢楼上诸位兄弟，小结下，只说性能，管理上优势显而易见：
1. Bigfile在某些可能影响性能的方面做的比Smallfile
Performance of database opens, checkpoints, and DBWR processes should improve if data is stored in bigfile tablespaces instead of traditional tablespaces. However, increasing the datafile size might increase time to restore a corrupted file or create a new datafile.
-- http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/physical.htm#i14068
2. ASM可以改善性能，由上面天黑的回复及
ASM：A vertical integration of both the file system and the volume manager built specifically for Oracle Database files. It extends the concept of stripe and mirror everything to optimize performance, while removing the need for manual I/O tuning.
-- http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/glossary.htm#CNCPT1995
3. 不过上面都是ORACLE自己说的，有时候也当不得真。
4. 所以有没有人明白里面的实现机理或给出测试数据。
5. 此帖200分，哪边给建议都给分，明天结帐，多谢！
1. Bigfile在某些可能影响性能的方面做的比Smallfile
Performance of database opens, checkpoints, and DBWR processes should improve if data is stored in bigfile tablespaces instead of traditional tablespaces. However, increasing the datafile size might increase time to restore a corrupted file or create a new datafile.
-- http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/physical.htm#i14068
2. ASM可以改善性能，由上面天黑的回复及
ASM：A vertical integration of both the file system and the volume manager built specifically for Oracle Database files. It extends the concept of stripe and mirror everything to optimize performance, while removing the need for manual I/O tuning.
-- http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/glossary.htm#CNCPT1995
3. 不过上面都是ORACLE自己说的，有时候也当不得真。
4. 所以有没有人明白里面的实现机理或给出测试数据。
5. 此帖200分，哪边给建议都给分，明天结帐，多谢！
thesecretblue 2009-07-29
- 打赏
- 举报
pay attention
inthirties 2009-07-29
- 打赏
- 举报
[Quote=引用 9 楼 majy 的回复:]
回答楼上：如果磁盘已经做了条块化(stripping）不用自己去考虑I/O分布的问题
[/Quote]
这个和bigfile就没有关系叻。
回答楼上：如果磁盘已经做了条块化(stripping）不用自己去考虑I/O分布的问题
[/Quote]
这个和bigfile就没有关系叻。
majy 2009-07-29
- 打赏
- 举报
回答楼上：如果磁盘已经做了条块化(stripping）不用自己去考虑I/O分布的问题
inthirties 2009-07-29
- 打赏
- 举报
[Quote=引用 7 楼 majy 的回复:]
下面再来一段，oracle公司极力推荐使用bigfile，每一个tablespace只用一个datafile，这样可以更好的使用好64位操作系统的威力：
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/physical.htm#sthref485
[/Quote]
这里没有推荐的意义吧，突出的bigfile的好处
也就是在storage上，不需要多个datafile叻，但是我决定这个对于文件管理来说是好处，毕竟只对应一个文件，当然比多个文件好管理，不过性能上倒是比不到smallfile哟，毕竟small file又方式分散到IO如果处理的好的话。
而且对于管理来说如果用ASM的话。我们也不需要对文件直接管理哟
所以这里smallfile解决的storage capacity的问题，并不是解决better-performance的问题的，
不应该把smallfile/bigfile和ASM进行比较，比较方向不同，没有可比性。
也可以见我在这个贴上的回帖
http://topic.csdn.net/u/20090729/09/9b958ebf-533e-4200-bc4e-3c1c11c4b329.html?85728
下面再来一段，oracle公司极力推荐使用bigfile，每一个tablespace只用一个datafile，这样可以更好的使用好64位操作系统的威力：
http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/physical.htm#sthref485
[/Quote]
这里没有推荐的意义吧，突出的bigfile的好处
也就是在storage上，不需要多个datafile叻，但是我决定这个对于文件管理来说是好处，毕竟只对应一个文件，当然比多个文件好管理，不过性能上倒是比不到smallfile哟，毕竟small file又方式分散到IO如果处理的好的话。
而且对于管理来说如果用ASM的话。我们也不需要对文件直接管理哟
所以这里smallfile解决的storage capacity的问题，并不是解决better-performance的问题的，
不应该把smallfile/bigfile和ASM进行比较，比较方向不同，没有可比性。
也可以见我在这个贴上的回帖
http://topic.csdn.net/u/20090729/09/9b958ebf-533e-4200-bc4e-3c1c11c4b329.html?85728
