没有必胜的秘籍，没有方程式遵循~~
要赢~~只有全身心的投入！
晶晶小妹的个人资料
- 性别: 女
- 生日: 1988-4-24
- 婚恋状况: 未婚
- 民族: 汉族
- 血型: B
- 身高: 165－170公分
- 常用E-Mail: jjxm@live.cn
- QQ号码: 522439797
- MSN帐号: jjxm@live.cn
- 职业: 计算机IT
- 省份: 河南
- 地区: 开封
管理 给我的留言
-
liyongdong 留言于2008-09-26 13:52:57
- 10月一快到了，是不是可以休息休息了。
2008-09-28 09:15:39
是啊 是啊
长假是很舒服的,而且我父母也来
哈哈~~~快乐的10-1长假哟~~~
-
建 留言于2008-09-14 09:15:31
- 在朋友的谈话说中--知道了 你这个风云 人
甚是 佩服2008-09-16 16:38:04
呵呵，谢谢支持．
-
lsora 留言于2008-09-10 10:52:49
- 晶晶小妹,你的msn一直不在线,可能你一直很忙,我有一个duplicate database问题想问你,或者你有常用的油箱,我能发给你,谢谢
2008-09-16 16:37:34
jjxm@live.cn 发邮件就好了．最近是有点忙，头晕了．．．
-
lsora 留言于2008-08-30 02:03:11
- 看了你的myshell1,期待你的myshell2,几个月了,晶晶小妹,期待中......,有msn吗,能否加我lush_second@hotmail.com
2008-09-02 10:04:51
jjxm@live.cn 谢谢支持,嘿嘿!不过最近上班了,比较忙,都是这样吗,总会出现自己计划外的事情要做.SHELL 恐怕要先放放了....
-
black_sun 留言于2008-08-22 16:41:21
- 晶晶小妹﹐本人寫了一年的SQL PL/SQL現正准備轉DBA﹐看了一些ORACLE DBA的官方文檔﹐大概知道一些ORACLE的概念﹐現在不知道學什么了﹐能不能給點意見
2008-08-25 00:34:44
从备份恢复开始学起吧。这是比较实际的东西。调优、排故对刚开始的人来说比较虚，容易摸不着方向。把基本的备份恢复学完，对于理解一些概念还是有帮助的。注意一定要多做练习。
至于不错的书籍，我的采访视频中介绍了几本，你可以去看看。
-
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，数据仓库中一条语句的执行时间更长，更值得花时间优化一下执行计划。本来还想起来有几点，刚才有事情一打断，忘了，明天再补充吧。2008-08-01 10:43:28
隔了这么久,不好意思,前一段时间不能经常上网.不好意思.继续前面的话题.我觉得你应该考虑一下索引组织表,簇表等特性,只要使用得当,它们可以有效的增进性能.你数据仓库的应用应该平常的并发插入,修改都不是太多的,也比义适合使用这些特性.
-
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
- 已回复了。五一要能出去玩就好了。
