没有必胜的秘籍，没有方程式遵循~~
要赢~~只有全身心的投入！
管理 给我的留言
-
daiyan008 留言于2008-07-18 21:24:10
- 感谢你5月份对我的一个提问的详细解答，问题大致是“关于中度或者中高度汇总的大数据量（譬如行数为亿级别）表的查询性能优化思路”，你的视角是从DBA的角度思考的，而现实中，作为开发人员，我们很难获得DBA组同事的这方面协助。
这是一些OLAP的应用，准数据仓库中的操作，出现在加工汇总和数据的ETL中，我一般把是先提取需要汇总的清单写入ETL服务器的落地文本中，这个过程不一定做排序，然后再来汇总，这在避免哦555方面效果比较明显——其速度也减少不了多少，因为在落地文本中汇总和从文本写入数据库的过程速度是非常快的。
还有一部分应用是在生成CUBE的星型模型中，一个超大的事实表和诸多维度表做关联，Oracle数据仓库方面的专家和文档强烈推荐使用位图索引来代替普通的B树索引，组内同事也极少这方面的经验，我的了解不是很多，不知道晶晶对这个主题有经验没？
祝早日康复，平常多多锻炼身体-_-2008-07-23 19:42:07
对于数据仓库，我也正在找机会钻研。在一般情况下，根据你的应用的情况位图索引的确要好于B树索引。
你是典型的数据仓库型应用。感觉对这种类型的应用，巨表的查询没有什么特别好的优化方法。从开发者角度，可以尽可能的编程更有效的应用程序，这就要根据不同情况来决定了。从DBA角度，如果数据仓库中大表的汇总，首先应该保证有足够大的PGA，因为汇总需要排序。二要在合适的列上要有合适的索引，看是否可以只访问索引不访问表就能完成需求。三要观察语句的执行计划，相比OLTP，数据仓库中一条语句的执行时间更长，更值得花时间优化一下执行计划。本来还想起来有几点，刚才有事情一打断，忘了，明天再补充吧。
-
sqysl
留言于2008-07-10 19:05:49
- 晶晶小妹，很为你的身体状况担心，你天赋很高，人也不错，但IT这个行业很累人，希望你能好好静养身体，我也有这种经历，人生就是一场马拉松，谁坚持到最后就是胜利，你还很年轻，不要急着工作学习，以后的路还很长，身体是革命的本钱，切记啊。。。
-
一个海外佩服 留言于2008-07-10 12:27:06
- 静静小妹你好，你的名气不小，在加拿大的论坛出现了你的名字，然后我GOOGLE到你这里了
我是做HP-UX的，对ORACLE也很熟悉，不过感慨你的悟性和毅力还是很高，比我20岁要强，多联系，想了解加拿大的技，，术或其他事情可以联系我，，，我英文讲课没问题，但是ORACLE比你要差，呵呵，，EMAIL
sun.denny@gmail.com2008-07-10 17:26:33
给你回了封邮件
-
sqysl
留言于2008-07-09 19:35:12
- 晶晶小妹，最近一直没看到你的踪迹，呵呵，没事情，问候一下，最近还好吗？
2008-07-10 17:25:39
多谢关心。
病情有点反复，本来准备这个月就回北京的，看来是不行了。
唉！
-
sqysl
留言于2008-06-26 16:17:14
- 悄悄话，只给空间主人查看...
-
wisdomone1
留言于2008-06-12 09:14:34
- 问了问题,没回啊,唉.
2008-06-12 18:40:38
已经回复了
-
zx2010 留言于2008-06-07 15:19:59
- 晶晶小妹请教个问题。
实验九之详细论述增量检查点篇：
Update table set name=upper(name) where id=1;
------块1 38.10335.0
其中这个块的RBA你是怎么取到的啊？是通过控制文件还是那个X$KCCCP查询到的啊？2008-06-12 18:40:22
不是通过X$KCCCP，它里面的RBA是控制文件中的LRBA。
某条DML语句对应重做记录的RBA，我是转储日志文件得到的。
-
wisdomone1
留言于2008-06-04 20:30:00
- 晶晶小妹,你好,我们客户有一个网站,现在开发人员反应在java代码中内含的insert语句,每天并发高达8000w-1亿记录之间,对于这种高并发性(随机性),有何优化方法.
已经采用:nologging
parallel
partition table
raw device
想请教下,你还有什么好的方法.2008-06-12 18:36:30
在不改变硬件的情况下：
插入并发高，可以使用ASSM的表空间。保证表、索引有足够 的区，如果表、索引的区快要用完了，可以手动的分配一些区给它们。另外，减少不必要的索引。
如果是普能的插入，使用NOLOGGING是没有用的。还有，你这个应该是OLTP型的应用，PARALLEL对这样的插入没有任何帮助，建议设并行度设为1。2008-06-25 09:27:51
补充一点，看看你的关于I/O、Buffer cache的主要的等待事件是什么，根据这个进行下一步的调优，这样更有目的性。
-
liqy103 留言于2008-06-03 00:06:41
- 悄悄话，只给空间主人查看...
-
sqysl
留言于2008-05-29 16:11:31
- 刚看了你写的算是经历吧，一路走来，很不容易，佩服。。。，可见女侠天资不错，只是有点可惜了。
继续加油、努力，身体健康。2008-05-29 22:17:40
可惜什么？
没上大学？
-
zf_wu
留言于2008-05-15 20:12:10
- 悄悄话，只给空间主人查看...
-
daiyan008
留言于2008-05-11 23:57:13
- 关于中度或者中高度汇总的大数据量（譬如行数为亿级别）表的查询性能优化，请问晶晶有没有什么一般性的建议？
遇到很多这样的表，很难找到合适的字段加索引，也往往没有主键，汇总的程度也不同，并且不时会加入或者减少汇总字段，最后查询起来就是个全表扫描，似乎是无可奈何。2008-05-12 23:19:01
对于这样的情况，我没有什么特别的建议。
按你的意思，既然建索引是不太现实的。那就不考虑索引了。
如果汇总的操作需要排序（比如分组），可以把PGA加大一些。可以考虑使用手动的PGA，把运行汇总的会话PGA设大一些。
如果查询执行时间长，在读写混合的情况下，是需要注意ORA-01555的。
也可以看汇总的精度，如果对汇总结果的准确性要求不是十分的高，可以自己开发一些专用的汇总程序。将一条语句完成的求和、求平均等运处分解为多段。这样做速度可能比一条语句完成要慢。但可以避免ORA-01555。
在读写混合时，汇总的查询有可能需要大量的使用CR块，这也可能降低速度。而且读、写在Buffer cache中块上的锁是不相容的。
最好考虑进行读、写的分离。应该会对性能有不小的提升。而且也不会有ORA-01555的困扰。
在不能改变数据库规化的情况下，只能优化全表扫描操作了。在不考虑改变硬件环境的情况下，可以根据容载能力，选择适合的并行度。在SQL*Plus有个ARRAYSIZE，在游标中也叫成批抓取，将批值设的大一些，可以降低逻辑读，提高全表扫描的速度。还有db_file_multiblock_read_count的值，可以设置的大一些。不过我以前遇到的情况，它的效果不如批抓取对性能影响更大，它主要是可以影响执行计划。另外，对于这些经常全表扫描的表，区大小应该使用统一区大小的表空间，而且区大小可以尽量的大一些。ASSM会增加更多的管理块，全扫描性能不如MSSM好。如果并发插入不多，应该使用MSSM的表空间。如果不改应用、不动硬件，应该也就这么多了吧。
-
wind998899 留言于2008-05-10 15:44:17
- 见到你开讲了，要加油哦，期待中.......。对了，不要太紧张，放轻松哦，对，轻松！
2008-05-11 12:57:03
以前没讲过，毕竟自己会到把别人也讲会 还有很长的路呢．．我会努力的，谢谢你的支持．．虽然我不知道你是哪位＼哈哈
-
iso90000 留言于2008-05-04 17:52:14
- 谢谢晶晶的精彩解答！
我的理解是：
dirty:只要buffer上有被修改的数据，但还没有写进磁盘，这个buffer就是dirty（无论是否提交）
clean：只要buffer上有数据与磁盘上一致，这个buffer就是clean（无论是否提交）
pinned：对块进行读、写操作时，需要在Ｂｕｆｆｅｒ ｃａｃｈｅ中先在块上加一个Ｐｉｎ，当在BUFFER上读写完成后就立即释放（无论是否提交），与提交有关的表级锁和行级锁。2008-05-04 19:49:23
对啊，这几点理解都很对。
读块时，要在Ｂｕｆｆｅｒ ｃａｃｈｅ中块上加共享ＰＩＮ，写块时加独占ＰＩＮ。ＰＩＮ的争用就是Ｂｕｆｆｅｒ ｂｕｓｙ ｗａｉｔ事件
-
晶晶小妹
留言于2008-05-04 09:37:33
- 已回复了。五一要能出去玩就好了。
-
iso90000 留言于2008-05-02 17:53:45
- 怎么没人回答？晶晶是不是五一出去玩了？
-
iso90000 留言于2008-04-29 21:33:39
- 晶晶你好：
看了你的2篇关于检查点的文章，有些问题想向你请教：
1.检查点队列中只有脏块，这个dirty block是指已提交的的dirty block，还是也包括未提交的dirty block。因为记得未提交的当前使用的块应该是PINED状态
2曾经看过一篇文章中的一段如下：
检查点发生的时候，ckpt 去更新数据文件头和控制文件，并不是把当前检查点发生时候的 scn 更新进去，而是把上一次dbwr写入已经完成的检查点发生时候的 scn 更新进去 ，也就是说，更新控制文件和数据文件头 是 滞后于检查点的发生的。
(1)"这里的检查点发生的时候，ckpt 去更新数据文件头和控制文件"中所指的检查点应该是包括增量检查点和完全检查点（还是只是包括增量检查点的日志切换和完全检查点），我觉得是第一种假设：因为每3秒钟只是CKPT检查DBWR工作的进度（虽然是增量检查点的一部分），与检查点并无直接关系?
(2)"并不是把当前检查点发生时候的 scn 更新进去，而是把上一次dbwr写入已经完成的检查点发生时候的 scn 更新进去 ，也就是说，更新控制文件和数据文件头 是 滞后于检查点的发生的。"
所以我理解日志切换的那个实验（实验十）应该是当日志切换时，CKPT先将前一次完成的检查点时的SCN更新到数据文件头和控制文件，然后在下次增量检查点或完全检查点来时将这次日志切换的检查点的SCN(前提是已做完了)更新到数据文件头和控制文件!2008-05-04 09:35:30
看了你的2篇关于检查点的文章，有些问题想向你请教：
1.检查点队列中只有脏块，这个dirty block是指已提交的的dirty block，还是也包括未提交的dirty block。因为
记得未提交的当前使用的块应该是PINED状态
脏块和提交于否没有关系。只要块被修改了，而在修改后块还没被DBWn写磁盘，块就是脏块。如果块被修改了，但一
直没有提交，但是过一会儿块被DBWn刷新到磁盘，那么这个块就不是脏块，而是干净块。
PINED也和提交没有关系。在修改块中数据时，要对块加独占PIN，修改完后，马上释放此独占PIN。但块中的行锁、
ITL事务槽会一直保留，直到提交时清除。可以把PIN看作一种特殊的锁。其实Pin和Latch都是不同于队列锁的另一种
形式的锁。
2曾经看过一篇文章中的一段如下：
检查点发生的时候，ckpt 去更新数据文件头和控制文件，并不是把当前检查点发生时候的 scn 更新进去，而是
把上一次dbwr写入已经完成的检查点发生时候的 scn 更新进去 ，也就是说，更新控制文件和数据文件头 是 滞后
于检查点的发生的。
是的，这样做的目的，是使用检查点完成的更快速。CKPT不必等本次刷新脏块操作完成，因为刷新脏块操作要写磁盘
，物理写速度慢。检查点发生时，CKPT把上次刷新脏块的位置写进控制文件，这样不必等待物理写的完成。
不过，CKPT只在增量检查点中按照这样的方式去完成。并且只更新控制文件中的Low cache rba、On disk rba、On disk scn。在日志切换时、完全检查点时并不这样。
(1)\"这里的检查点发生的时候，ckpt 去更新数据文件头和控制文件\"中所指的检查点应该是包括增量检查点和
完全检查点（还是只是包括增量检查点的日志切换和完全检查点），我觉得是第一种假设：因为每3秒钟只是CKPT检
查DBWR工作的进度（虽然是增量检查点的一部分），与检查点并无直接关系?
这个检查点应该指的是增量检查点。每三秒中CKPT检查DBWR的写进度，检查完后还干什么，还要将此写进度写进控制
文件中。这里写进控制文件的“DBWR的写进度”，就是你上面所说的“上次dbwr写入已经完成的检查点发生时候的信
息”。增量检查点由两部分构成，一是根据一些参数（如fast_start_mttr_target）的设置，到一定时机由CKPT通过DBWR沿检查点队列的顺序刷新脏块。二是每三秒一次的由CKPT检查DBWR的写进度，并且记录此进度到控制文件中。
完全检查点，主要在关闭数据库时触发，此时当然不会在控制文件、数据文件头记录上次检查点的完成情况。只会记录本次检查点的完成情况。
日志切换也是如此。将记录日志切换时检查点的信息。因此日志切换时的检查点操作可能完成的比较慢，也就有了一个“日志切换（检查点未完成）”这样的等待事件。但是，我们几乎在数据库中发现不了相关增量检查点的等待事件，因为它并不等待DBWR，它只需要向控制文件中写少量信息即可，因此它完成的非常快。
(2)\"并不是把当前检查点发生时候的 scn 更新进去，而是把上一次dbwr写入已经完成的检查点发生时候的 scn 更
新进去 ，也就是说，更新控制文件和数据文件头 是 滞后于检查点的发生的。\"
所以我理解日志切换的那个实验（实验十）应该是当日志切换时，CKPT先将前一次完成的检查点时的SCN更新到
数据文件头和控制文件，然后在下次增量检查点或完全检查点来时将这次日志切换的检查点的SCN(前提是已做完了)
更新到数据文件头和控制文件!
日志切换时的检查点和增量检查点并不一样。它并不滞后于DBWR实际的写进度。
-
╰╃┈→丹 留言于2008-04-24 22:36:00
- 经朋友介绍，有了你的博客地址，进来看看，进来才看见，是个漂亮才华一身的才女，很高兴欣赏了你的博客。
2008-04-28 18:06:49
呵呵 过奖了，谢谢你，也感谢你的朋友，都是大家给面子．．：）
-
tempyou1 留言于2008-04-17 21:47:46
- 谢谢回答
-
迷人的蚊子 留言于2008-04-17 08:17:38
- 照片怎么看不到了？
2008-04-18 19:30:34
我这打开正常啊．．只有照片看不到吗
