一个由于应用程序逻辑设计的失误导致的性能问题

myfriend2010 · 发表于 2008-10-25 11:49

why not blob?

wangzhonnew · 发表于 2008-10-25 12:27

因为是varchar呀，blob是存binary得，clob是char得……

另一个思路，设置一个足够大的dedicate buffer，把这个表单独放到一个表空间，用这个bufferpool使得所有数据常驻内存，这种思路有什么优点和缺点呢？^_^

fck · 发表于 2008-10-25 21:09

学习中。。。
clob对比varchar有何有缺点？
说说第二种方法：优点就是这个表的数据常驻内存了，存取这个表肯定是快了很多。
缺点是不好估算到底建立多大的bufferpool合适？pagesize？另外还有可能需要调整
LSN?再或瓶颈也许又会出现在和它相连的其他表上面。

wangzhonnew · 发表于 2008-10-25 23:25

CLOB没有prefetch，所有的读写都是direct I/O，会对性能造成负面影响

上面说的挺对，单独的bufferpool对产品今后的发展不利。当数据越来越多的时候不可能无限地增大bufferpool。
为什么楼上的认为需要调整pagesize和LSN？不大理解，能不能解释一下？

另外一个可能性，在插入数据得时候直接插入15000个空白字符，这样会产生什么影响呢？

fck · 发表于 2008-10-26 21:28

不一定非得调整，只是一种考虑。
关于pagesize有好几种，总的选一个吧，一般是选4K,也有用用8K,16K大小的。
关于LSN其实是涉及到页清除方面的考虑，还有参数chngpgs_thresh 需要配合考虑，因为如果缓冲池比较大，而chngpgs_thresh和LSN都比较大，那么产生页清除时，一次性写入磁盘的数据可能会很多，同样会对IO造成加大压力，当然如果采用了主动的页清除则除外。

wangzhonnew · 发表于 2008-10-26 22:05

既然有了2个15000得varchar，已经可以肯定最少需要32k得pagesize拉

当前问题的瓶颈在于overflow，如果把表分成两个则需要double logging i/o，俺同意一般来说page cleaning是一个需要考虑的因素，但是在这个问题中，感觉好像并没有什么直接的联系吧。还是俺没有理解你的意思？

ninth99 · 发表于 2008-10-27 09:30

我觉得应用为什么要先插一条记录后再修改，为什么不一起插入？

wangzhonnew · 发表于 2008-10-27 10:18

改应用是一个思路，并且是客户在现实中将要做的。但是这个做法和其他的一些方案比起来要考虑的东西更多。
需要从这个应用的框架上修改，同时需要很多的planing/coding/testing，是一个很浩大的工程……

还有没有其他的比较有创意的思路呢？感觉这个case比较典型，能够有很多的方法从不同角度对性能造成正面或者负面的影响……

diablo2 · 发表于 2008-10-27 10:58

why not try altering PCTFREE of the table?

缺点是，浪费存储

fck · 发表于 2008-10-27 10:59

为了解决overflow--〉增加一个bufferpool---->解决了overflow---->是否会带来其它问题？
多考虑一些还是没有坏处的，另外还要记的对应增加一个32K得临时表空间。

[精华] 一个由于应用程序逻辑设计的失误导致的性能问题

浏览过的版块