在AnySQL.net中搜索标签(Tags) 'Tuning' 的结果:
OR引起的Join性能问题
在SQL语句中用了OR之后, 其实很不容易控制, 第一次是想让一个带两个OR的用UNION去执行, 结果用了USE_CONCAT后变成了4个UNION了, 居然没有办法让他按我想象的第一个OR进行UNION. 第二次是在索引上, OR条件导致了不能在索引上进行条件过滤. 现在遇到了第三次, 是同事发现的, 怕自已记不住, 就没有征得他的同意, 在这儿共享出来了. 有下面两个表, TYPE_ID列上值的重复性很高. CREATE TABLE T_SMALL (TYPE_ID, ID, ...); CREATE TABLE T_MIDDLE (TYPE_ID, ID1, ID2, ...); 运行下面的SQL时, 总是很慢, 我们已经指定用HASH JOIN, 并也指定了T_SMALL是驱动表, 百思不得其解. SELECT...
分析用户所有表之后
随着Oracle对CBO的进一步增强和改进, 对表进行分析已经成为一种常用的调优的手段, 当发现某个表的相关SQL语句的执行计划有问题时, 首先会想是不是统计信息过旧的问题, 如果的确是过旧, 则对这个表进行分析, 以让Oracle重新选择准确的最优执行计划, 以达到调优的目标. 用不合适的方式对表进分析, 则会造成十分严重的后果, 如对一个用户下的所有表进行分析, 或一下子分析多个表. 看到网友的一篇贴子, 让我想起二年多前帮别人处理过的一个案例, 有位DBA对某用户下的所有表进行了分析. 基本情况是, IBM P570, 16CPU, 32GB内存, 24GB的SGA, 支持不了一个50G的9i数据库(OLTP类型), 二百个以内的会话. 在分析之前CPU利用率是50-70%左右, 在分析后则一直是100%. 面临这样的情况后, 由于没有做统计信息(Statistics)的备份, 因此无法恢复以前的情况, 首先做的是删除所有非分区表的统计信息, 对分区表做更精确的统计信息分析, 使之运行于RULE方式, 情况稍有好转, 但用户还是不能接受, 相信Oracle的CBO没有那么差, 因此性能问题的关键并不在于统计信息了. 在处理了以下几个问题之后,...
Oracle AQ的问题
Oracle AQ问题, 江湖救急, 在那么多的回答中, 有幸我的答案最后解决了问题, 解决的方法是如此之简单. 将aq表的索引rebuild一下? 其实在调优化的过程中, 主要还是缺少数据, 从而无法找出问题的根本原因所在, 所以我的回答也加了一个问号, 因为这只是猜的. 对于这种持续较长一段时间的, 比较容易获得相应数据, 如Statspack或现场去捕捉一些. 但对于偶然发生的突发性数据库负荷很高, 这种情况持续的情况很短暂, 可能最后自动变好, 或者数据库服务器就挂了, Statspack就无能为力. 因此需要一些能以较快的频率捕捉性能数据的程序, 如很早以前开发的OTop程序, 可以每10秒钟输出Top Session信息. 或OPMon程序, 可以捕捉最近30秒的SQL的执行情况, 从而找出Top SQL, 这两个工具本身的执行代价都极低. 但无法相象以这样的频率去进行Statspack收集. 最近在完善的另一个程序是oramon, 可以更好是记录一些主要的性能数据,...
Hack了一把Oracle的exp工具
想让Oracle的exp查询要导出的表时用并行去执行, 不想建一个Logon的触发器来做, 就Hack它一把了. 下面是用正常的exp跟踪(TRACE=YES)出来的SQL语句. SELECT /*+NESTED_TABLE_GET_REFS+*/ "SH"."T_COMPRESS".* FROM "SH"."T_COMPRESS" Rows Row Source Operation ------- ------------------------------ 10089 TABLE ACCESS FULL T_COMPRESS 将exp拷贝一份, 命名为expp(Exp Parallel). 然后用UltraEdit打开expp文件, 在二进制模式下找到如下这一段. BEGIN SYS.DBMS_EXPORT_EXTENSION.SET_NO_OUTLINES; END; 将它编辑为"ALTER SESSION FORCE PARALLEL QUERY PARALLEL 4", 然后保存. 接下来用expp来导出一个表看看,...
如何提高Oracle exp/imp的速度?
在用Oracle的exp/imp工具时, 常常有人嫌它忙, 这个两个工具是比较慢, 除了用比较大的buffer参数外, 还是有办法可以加快的. 在exp时, 可以考虑更改表的并行度(ALTER TABLE xxx PARALLEL 4), 或者更改exp进程的Multiple Block Read参数的值. SELECT SID, SERIAL# FROM V$SESSION WHERE PROGRAM LIKE 'exp%'; exec dbms_system.set_int_param_in_session( sid, serial#, 'db_file_multiblock_read_count', 128); exec...
更改了Movable Type平台几个表上的索引
观看Movable Type后台的数据库, 发现有些索引建得不是很合理, 基本上是每个列上都建了一个单独的索引, 这一招是很多软件商都采用的办法, 而不管这个列上面的选择性如何. 我主要更改了以下三个表的索引. MT_PLACEMENT表记录了文章所属的类的信息, 更改后的索引结构如下: +--------------------------------+------+-----------------------+ | Key_name | Col | Column_name | +--------------------------------+------+-----------------------+ | PRIMARY | 1 | placement_id | | mt_placement_entry_id | 1 | placement_entry_id | | mt_placement_blog_category_id | 1 | placement_blog_id | | mt_placement_blog_category_id | 2 | placement_category_id | |...
加快Movable Type的留言速度的办法
最近基于Movable Type平台的本站留言速度下降比较历害, 这严重地影响了浏览者进行留言交流的极积性, 如何提高速度呢? 象Oracle数据库一样, 一开始没什么人用时比较快, 最后数据多了就慢了, 进行调优的最好的方法是减少数据库上的执行次数, 最近一个生产库就是用这个方法的, 效果很明显. 现在要将这一步应用到Blog平台上来, 由于Movable Type是静态发布的, 因此留言后需要重新发布页面, 因此减少需要重建的页面是很关键的一招. 拿我的站点来讲, 禁掉了以下几个页面的自动发布. 自定义的一些模板 Master Archives Site Scripts Site Styles 另外, 我还去掉了Monthly Archive, 有Cateogry Archive就足够了, 那东西没有多少人访问. 在CDMA 1X的网络上测试感觉还不是很明显, 不过大家可以留言试试速度. ...
用Stop List来缩小Oracle全文索引的大小
Oracle的全文索引是一个很好的搜索解决方案, 不过随着要搜索的内容的增加, 会发现全文搜索的索引会耗掉很多的空间, 也在一定的程度上影响了全文索引的查询速度. 我们可以用如下方法去看, Oracle是如何划分单词的, 如在CR_CTXDEMO表的COL2列上面建一了个CTXSYS.CONTENT类型的全文索引, 则可以用如下SQL语句去查询: SELECT TOKEN_TEXT, COUNT(*) FROM DR$IDX_CR_CTXDEMO_COL2$I WHERE ROWNUM < 1000000 GROUP BY TOKEN_TEXT HAVING COUNT(*) > 1000 可能会得到如下这样的结果: TOKEN_TEXT COUNT(*) -----------------...
庆祝oramon不停顿运行一周
要写一个能跑的程序不难, 用C写一个能跑的程序就不易, 写一个能不停顿跑一周的C程序就有点难了. 为了达到理想的效果, 历经周折, 终于搞明白了线程问题, 而我写的程序也已经在服务器上不停顿地运行了一周, 最怕的两个问题, 一个是内存汇漏, 另一个是Segment Fault(core dump), 都没有发生. C程序就有点象Unix小型机, 要出问题则会很快就体现出来, 要不出问题则可以很稳定. 当然测试还要续继, 看看一个月后, 或三个月后, 或半年后, 程序是不是还在不停顿的跑? 队了程序本身要稳定之外, 占用的资源也不能多, 否则那么多的DBA在管理数据库, 总会被发现最后被kill掉, 很多的程序都有这种下场的, 要逃过这一劫才算真正成功的程序. 用有自已的工具来监控数据库的性能是件很有意思的事, 会不停地改进你对数据库的直观认识, 然后你又会再次改进工具, 这个过程就象是炼金一样, 何况是在这样的一个单位呢? 最近在OTop和OPMon中去掉了Wait Event和Latch的输出,...
10g中不同Oracle优化器版本的参数差异
NAME8.1.79.2.010.2.0.1 _trace_optionstextmultipletext _db_block_adjchk_level785615367888921678889216 _always_semi_joinOFFCHOOSECHOOSE _ordered_nested_loopFALSETRUETRUE _optimizer_max_permutations8000020002000 query_rewrite_enabledFALSEFALSETRUE _mmv_query_rewrite_enabledFALSEFALSETRUE _index_join_enabledFALSETRUETRUE _table_scan_cost_plus_oneFALSETRUETRUE _cost_equality_semi_joinFALSETRUETRUE _new_initial_join_ordersFALSETRUETRUE _optim_peek_user_bindsFALSETRUETRUE _gs_anti_semi_join_allowedFALSETRUETRUE _optim_new_default_join_selFALSETRUETRUE optimizer_dynamic_sampling012 _pre_rewrite_push_predFALSETRUETRUE _union_rewrite_for_gsOFFYES_GSET_MVSYES_GSET_MVS _generalized_pruning_enabledFALSETRUETRUE _optim_adjust_for_part_skewsFALSETRUETRUE _optimizer_compute_index_statsFALSEFALSETRUE _optimizer_filter_pred_pullupFALSEFALSETRUE optimizer_features_enable8.1.79.2.010.2.0.1 optimizer_modeCHOOSECHOOSEALL_ROWS _always_anti_joinOFFCHOOSECHOOSE _partition_view_enabledFALSEFALSETRUE _b_tree_bitmap_plansFALSETRUETRUE _cpu_to_io10000 _optimizer_cost_modelIOCHOOSECHOOSE _optimizer_undo_cost_change8.1.79.2.010.2.0.1 _optimizer_system_stats_usageFALSETRUETRUE _new_sort_cost_estimateFALSETRUETRUE _complex_view_mergingFALSETRUETRUE _unnest_subqueryFALSETRUETRUE _pred_move_aroundFALSETRUETRUE _remove_aggr_subqueryFALSEFALSETRUE _optimizer_squ_bottomupFALSEFALSETRUE _push_join_predicateFALSETRUETRUE _push_join_union_viewFALSETRUETRUE...
FOR UPDATE SKIP LOCKED语句中的逻辑读
今天发现这样的一个语句逻辑读很高, 在Physical Standby上打开查询, 发现逻辑读是很低的, 只有源库的百分之一, 百思不得其解. 回来后建了如下表做测试: SQL> CREATE TABLE T_SKIPLOCKED 2 ( 3 NO NUMBER(2), 4 COL2 CHAR(200), 5 CONSTRAINT PK_T_SKIPLOCKED PRIMARY KEY (NO) 6 ); Table created. SQL> INSERT INTO T_SKIPLOCKED SELECT ROWNUM, OBJECT_NAME 2 FROM ALL_OBJECTS...
想写最后一个程序, 却发现提不起心思来了.
现在还是一个人在上海, 老婆儿子在南京. 下班以后这么热的天能做什么呢? 有两台相机, 不过没有风景可以拍, 只有坐在室子里, 开着空调纳凉了. 老是上网也没有什么网页可以看了, 写个程序应当是比较好的选择, 利用一个夏天再写一个有关Oracle性能监控的程序, 真是个好注意. 以前的程序大都是在这样的情况下编写出来的. 虽然我对于想写的程序已有了结构性的设想, 但今天想真的启动它时, 却发现提不起一点点心思. 为什么要写程序? 可以卖? 可以改善生活? 总是会联想到猪肉涨价的问题, 总会联想到通货膨胀的可能性, 总会联想到自已以后的路要怎么走, 如何去养大孩子, 未来生活的压力还是有些让人透不过气来. 稍稍脆弱一些的人已经拿根绳子自杀了. 上上周给一公司去作了一下支持, 发现极度缺少数据库负裁方面的历史信息, 不知道数据库那个时间段的负荷是最高的, 不知道工作日和周末的负荷有什么区别, 不知道最高时一分钟跑了多少个SQL语句或作了多少次数据库调用, 虽然说业务很好很忙但也不知道每分钟最高有多少个事务. 没有这些信息, 就不能对数据库的运行有很好的了解, 也就不可能作出很好的性能调整的方案, 也无法对应用作出合理的修改意见,...
Oracle 11g性能提升 -- 其他地方
看白皮书上这么多的功能, 如果在11g中能很成熟, 那真是一个变化比较大的改进, 来看一下关于性能方面的其他改进吧. 1, RAC节点通信协议的改进. 11g中的协议比较智能, 可以根据节点的负荷作出动态的调整, 大大减少节点之间的消息传递量. 说老实话不知道是如何工作的. 2, 边恢复边Open的Physical Standby -- Highly Available Reader Farms 这个功能肯定很受大公司的欢迎, 因为以前的Data Guard不能做到这样, 当Open时同主库的延迟会越来越大, 而在11g中则不存在这样的延迟, 因此可以建几个这样的Standby来分担读操作, 估计Shareplex或Realsync这样的软件市场要受到一定的影响了, 我对Log的研究也变得越来越没有价值了. 3, 面向OLTP的压缩表...
Oracle 11g性能提升 -- Server Connection Pool
在应用服务器这一层, 我们已经使用Connection Pool了, 可以有效地降低服务器上的连接的数量, 不过还是有不足之处的. 当你的访问量达到一定的规模时, 你会发现一台或几台应用服务器根本就解决不了问题, 在有些世界级的网站中, 应用服务器的数量可能是上千台的, 当每个应用服务器产生4-5个连接时, 你会发现Oracle服务器端便有了4-5千个物理连接. 象PHP程序, 要求每一个Web Server进程都至少有一个连接. 因此Oracle在11g中引入了Database Resident Connection Pool的功能, 这样客户端就可以不管连接池了, 由Oracle在服务器端进行连接共享控制. 通过增加一个后台进程CMON(Connection Monitor)来管理连接, 应用发出连接请求时, 实际上是连接到CMON进程, 然后由CMON进程分配一个已经连接好的后台进程, 当客户端连接关闭后, 这个后台进程又交由CMON进程管理. 估计PHP这类的Web程序要有福气了, 不需要去实现连接池的代码了. 但还有两个问题需要问, 可能会在正式的文档中有详细的说明: 1, 如果我连上去后, 一直不关闭连接,...
Oracle 11g性能提升 -- Consistent Client Cache
10g几乎没有关心, 现在都现11g了, 得关心一下了, 要不然就落伍了. Cache始终是提升性能的重要技术. 除了在前面讲的Server Result Cache, Oracle 11g还增加了一种Client Cache. 第一眼看到时, 我猜测可能和在程序中用数组保存一些查找表差不多, 不过仔看白皮书, 还是要比自已写程序来得方便许多. 这是一种在Oracle Client端的缓冲技术, 通过将中间结果或整个表缓冲在客户端, 当客户端发出查询请求时, Oracle可以直接在这个缓冲区中返回记录, 而不需要去和数据库打交道, 可以大大地着少和服务器端的网络来回, 降底服务器上的SQL调用, 根据Benchmarks测试, 对于只读或极少更新的表, 总的消耗时间可以降低500%, 而服务器上的CPU时间可以降低200%. 要使用这个Cache功能, 也很简单, 首先要使用Oracle 11g的OCI客户端, 如: JDBC-OCI, ODBC,...
Oracle 11g性能提升 -- Server Result Cache
10g几乎没有关心, 现在都现11g了, 得关心一下了, 要不然就落伍了. Cache始终是提升性能的重要技术, 在Oracle 11g中增加了一种Server Result Cache, 第一眼看到这个名字, 我觉得和MySQL的Query Cache是差不多的技术, 不过仔看白皮书, 还是要比MySQL进步多了. 谁可以共享这些数据? MySQL的Query Cache是根据SQL的文本来匹配的, 只有Query的文本一模一样时才可以共享, 而Oracle的Server Result Cache则只要执行计划一样或部份一样, 并且生命周期一样, 则就可以共享了. 当下面的表数据改变了, Oracle会自动清除这个Cache, 以确保查询结果的正确性. 在以读为主要的系统中, 宣称性能可以提升一倍. 这块内存从SGA中分配, 由RESULT_CACHE_MAX_SIZE控制. Oracle允许你在系统, 会话, 表和语句级(Hint:result_cache)控制是否使用Server Result...
通过改写SQL来优化性能, 如何做?
网友说这个SQL语句跑了两上小时, 没有什么思路去解决. select tbilltrace_43.bno,tbilltrace_43.SAVETIMESTAMP from ( select bno,SAVETIMESTAMP from tbilltrace where SAVETIMESTAMP>=monitor_start_date and SAVETIMESTAMP<=monitor_end_date and opcode=43 ) tbilltrace_43 where not exists (select bno from ( select bno from tbilltrace where SAVETIMESTAMP>=monitor_start_date and SAVETIMESTAMP<=monitor_end_date...
OR引起的性能问题, 在表上进行行过滤
对SCOTT用户EMP表的DEPTNO和ENAME字段建了一个复合索引. 在SQL的WHERE子句中用了一个OR条件, 看Plan: SQL> SELECT /*+ first_rows no_expand */ * FROM EMP 2 WHERE deptNO=10 AND (ENAME IS NULL OR ENAME > 'A'); --------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | --------------------------------------------------------------- | 0 | SELECT...
对Hash Cluster表的一些进一步测试之二
今天早上用真实的数据进行了第二次测试, 一是验证我这种定义SIZE和HASHKEYS参数的方法有没有问题, 另外一个是难证Oracle自带的Hash函数是否高效. 为此我选取了1000万条真实的记录, 表的大小大约是1.5个G, 我将Cluster的HASHKEYS * SIZE设成2G左右, 语句如下: CREATE CLUSTER C_USER_HOST_ID_LOOKUP (USER_ID NUMBER(38,0)) SIZE 8192 SINGLE TABLE HASHKEYS 262144; 用sqlldr装载这些数据却用了1个小时, 这是因为你不能用Direct方式, 而且每条记录是随机存放的, 而不是连续存放的, 所以比较慢. 装载完成后, 用如下脚本进行验证. 其中的SELECT语句可是要执行大约1000万次的. DECLARE TEMP VARCHAR2(64); BEGIN FOR REC...
对Hash Cluster表的一些进一步测试之一
在前面的例子中, 我们都只是做了一些小批量数据, 如果我的Hash Cluster表有几个GB或几十个GB的大小时, 又怎么样呢? 下面进行的是我在笔记本上的测试, 用于测试的表的大小是100MB, 进行测试时的数据是50万条. 测试的目的是为了要证明Hash Cluster是否可能用于大数据量的表中, 即验证Oracle内建的Hash函数是否是高效的. 创建Hash Cluster的句语是: CREATE CLUSTER C_T_OBJECTS (OBJECT_ID NUMBER(38,0)) SIZE 8192 SINGLE TABLE HASHKEYS 12800; 在100MB的DB_CACHE_SIZE下进行测试: 21:48:10 SQL> SELECT HASH_VALUE, BUFFER_GETS, EXECUTIONS 21:48:54 2 FROM V$SQL WHERE HASH_VALUE=3523526785;...
Oracle应当增加一种基于Hash算法的索引
Hash是非常高效的一种查找算法, Oracle中的Hash Join更是声名远播, 还有Hash Cluster表, 可以获得很好的性能. 现在的B*Tree结构的索引, 虽然很好, 但在很繁忙的系统中, 还是有一些不足, 比较典型的是在索引的根结点上, 发生Split时很容易引起数据库的问题. 另外从Root块到Branch块, 再到Leaf块, 最后到获得表的记录, 需要访问比较多的结点. 既然Hash算法能用于表, 那么也能用于索引. 因为索引从另外一个角度来说, 也象一个表, 象一个包括了索引列加上ROWID组成的表. 通过这种Hash类型的索引, 第一个可以将读一条记录的Gets减少到2, 同时也没有了Root块和Branch块的Split问题, 实在是值得考虑的一种新的索引类型. 其实通过Context接口, 已经可以很容易地实现这样的功能, 谁有写过自定义的Context索引类型? 在Oracle中Hash Cluster不一定要求字段是数字类型的, 因此支持Hash Index并不需要改动很多吧?...
如何创建Single Hash Cluster的表?
Hash Cluster的表可以在没有索引的情况下, 获得对表的极快访问, 这种访问的逻辑读比维一性索引还有效. 在这儿有一张表T_OBJECTS, 其中的OBJECT_ID是主键, 大量的SQL语句都是根据OBJECT_ID去访问其他字段, 通过索引的情况下每次执行的逻辑读已经只有3了(Index Root->Leaf->Table), 但是就是这样一句简单的SQL的逻辑读占据了大半. 因此考虑到使用Single Hash Cluster表来进行调优. 应当如何来创建这个Cluster呢? 决定Cluster性能的主要有两个因素: SIZE和HASHKEYS. 下面是我的思路, 首先分析一下现在的表, 获得比较准确的块数. SQL> SELECT BLOCKS FROM USER_TABLES WHERE TABLE_NAME='T_OBJECTS'; BLOCKS ---------- 118 因为在这个情况下, 数据分布均匀, 因此我只要将HASHKEYS定义为块数就已经比较好了, 实际上为了更安全,...
选择了错误的实现方法, 其实很简单!
今天写了下面这一段SQL语句, 在写之前总觉得有更简便的方法, 可就是没有想出来: SELECT REPLACE(REPLACE(REPLACE(REPLACE(REPLACE( REPLACE(REPLACE(REPLACE(REPLACE(REPLACE(TABLE_NAME,'0','#'), '1','#') ,'2','#') ,'3','#') ,'4','#') ,'5','#') ,'6','#') ,'7','#') ,'8','#') ,'9','#') PATTERN_NAME FROM USER_TABLES 下班时坐地铁, 突然想到了Translate函数, 原来可以这么简单: SELECT TRANSLATE(TABLE_NAME,'0123456789','##########') PATTERN_NAME FROM USER_TABLES 我写这个SQL是用来找出一些表结构应当相同的表, 最终的SQL应当如下: SELECT TABLE_NAME FROM...
MySQL的绑定(Bind)变量和Query Cache
在MySQL中并没有Shared Pool来共享SQL及其执行计划, 因此是否共享不是很重要, 在程序中是否使用绑定(Bind)变量也不是很重要. 事实上在目前的版本中, 只有Server Side的编程才能使用绑定变量, 而客户端的程序虽然用了绑定变量, 但实际是上只是被进行了文本替换, 最早我在MySQL的JDBC驱动说明上看到了这一点, 现在用Perl程序(asyncdata.pl)从Oracle向MySQL复制数据时(启动MySQL时指定--log选项)从SQL的日志文件中看到如下记录: Query DELETE FROM T_OBJECTS WHERE OBJECT_ID='441766' AND 1=1 Query DELETE FROM T_OBJECTS WHERE OBJECT_ID='441767' AND 1=1 Query DELETE FROM T_OBJECTS WHERE OBJECT_ID='441768' AND 1=1 而根据MySQL的解释,...
MySQL的binlog, InnoDB的日志和Oracle的日志
MySQL中有一个binlog的概念, 用于保存对数据库所作的修改, 这点上和Oracle的归档日志很接近, 但在原理上是很不一样的. 以InnoDB为例, InnoDB本身就有log文件, 和Oracle的联机日志一样, 用完了就重用, 但binlog并不是InnoDB的日志在重用前的拷贝, 而是另外写了一个文件. 因为binlog并不是专门为InnoDB设计的, 其他的存贮引挚如MyISAM也支持binlog, 它是MySQL备份及复制支持的重要基础, 因此不同于InnoDB的日志文件. 如果MySQL用于很重要的系统, 需要事务支持, 并且要支持联机备份, 要保证没有数据丢失, 目前来说, 一般会用InnoDB存贮引挚, 并启用binlog, 为了保证事务的数据不丢失, 就得: 1, 在每次Commit时, 将修改写入InnoDB的日志文件 2, 在每次Commit时, 将修改写入binlog文件 而在Oracle中只是保证写入到Oracle的联机日志就够了, 因此在性能测试中, 如果启用了binlog, 性能基本上下降了一半, 因为这中间要做两次写操作....
MySQL中我认为比重要的一些Status变量
1, Bytes_sent 累计值, 向客户端发送的字节数 2, Binlog_cache_disk_use 当前值, Binlog中(因为Binlog_cache_size不够大)用了临时文件的事务数, 如果不用Binlog则没有什么事情. 3, Connections 累计值, 向MySQL发出连接的数量, 成功和失败的总数. 4, Created_tmp_disk_tables 累计值?, MySQL中创建的在磁盘上的临时表的总数. 5, Flush_commands 累计值, Flush命令执行的次数 6, Handler_commit 累计值, 处理Commit的次数 7, Handler_rollback...
MySQL中的RBO特性, 数据访问方法的排名
参考原始文档后, 自已总结一下, 有不对的地方请指正. 在数据库中对数据的访问总存在不同的方法, MySQL中比较常的有以下几种, 在这儿按从好到坏的顺序排列. 在Oracle的Concept文档中, Oracle RBO有十六种不同的访问方法, MySQL中主要有以8种: 1, 访问系统固定(Constant)表 -- system. 2, 访问用户的固定表 -- const. 3, 在主键或维一性索引上用等于查找 -- eq_ref. 4, 在非空列的索引上用等于查找 -- ref. 5, 在允许空值的索引上用等于查找 -- ref_or_null. 6, 在索引上按范转查找 -- range. 7, 扫描整个索引 -- index....
InnoDB存贮引挚的一些重要设置选项
1, innodb_buffer_pool_size 用于缓冲表及其索引的内存区大小, 象Oracle中的DB_CACHE_SIZE, 这个比较容易理解. 2, innodb_log_file_size 每个日志文件的大小, Oracle在这个默认值上, 不同的版本变化很多. 真实的应用中, 从20M到2G都有人用, 自已选吧. 我现在并没有看到什么Checkpoint的概念, 不知道大小对于MySQL有多大的影响? 3, innodb_log_buffer_size 相当于Oracle中的LOG_BUFFER参数, 不过MySQL每秒种都会将日志缓冲区的内容写入日志文件, 因此不用设多大. 4, innodb_flush_logs_at_trx_commit 这个参数用于控制在用户发出提交(Commit命令)时, MySQL如何处理日志缓冲中的内容. 在默认情况下, MySQL会每秒种将日志文件强行刷新到磁盘, 由于日志文件还受操作系统文件缓冲的控制, 因此在写时就可以分为两步了, 第一步是写入日志文件, 写到文件缓冲就算成功, 第二步将日志文件刷到磁盘, 真正写入磁盘....
过长的In List引起的共享池内存问题
开发人员经常想用一个长长的In List来作为Where条件, 但这样的语句如果查执行计划不对的话, 很容易造成共享池(Shared Pool)内存问题, 下面是一个拥有40个值的In List的测试. 占用的内存如下所示: SQL> SELECT HASH_VALUE,SHARABLE_MEM,PERSISTENT_MEM,RUNTIME_MEM 2 FROM V$SQL WHERE HASH_VALUE IN (1981294536 ,3511787793); HASH_VALUE SHARABLE_MEM PERSISTENT_MEM RUNTIME_MEM ---------- ------------ -------------- ----------- 1981294536 31836 1088 5336 3511787793 171534 1088 127936 其中1981294536的计划中用的是INLIST ITERATOR方法, 3511787793语句用的是CONCATENATION方法. 源语句如下: SQL>...
Enable/Disable行内存贮的LOB字段性能分析
定义LOB字段时可以加上ENABLE/DISABLE STORAGE IN ROW的存贮属性, 默认情况下是ENABLE STORAGE IN ROW的, 这种情况除了在值小于4000字节时会将值直接存在行内以提高性能外, 对于再大一点的LOB值的存取也是有性能影响的, 请看下面的在10g版本中做的测试例子, 先建一个表, 包括两个CLOB字段, 并插入一样一样的大于4000字节的值. SQL> create table t_lobtest (col1 clob, col2 clob) 2 lob (col2) store as (disable storage in row); Table created. ASQL> SELECT DBMS_LOB.GETLENGTH(COL1) COL1_LEN, 2 DBMS_LOB.GETLENGTH(COL2) COL2_LEN...
性能调整等对于企业将越来越重要
象Oracle这样的数据库, 在License上面的监管将越来越严历, 随着业务的增长而导致的数据库性能问题, 将如何得到解决? 在过去的相当长的一段时间内, 我们的企业都不惜在硬件升级上大花血本, 但这种简单的解决方法将变得越来越困难, 原因以下几个方面: 1, License的费用增长 当你用硬件升级的道路(如增加CPU)来解决性能问题时, 势必会引起Licence的增加, 你将付出硬件的成本, 同时也得支付License的费用, 并且Oracle这样的原产服务成本也随着License的增加而增加. 现在许多行业还在用盗版的Licence, 如买了标准版, 但用了企业版; 没有买Replication或RAC, 但却正在用他们. 但这种情况还能走多久呢? 2, 硬件升级并不能解决问题 我们大部份的企业现在用的系统业务量还少, 增长速度没有硬件技术提高的速度来得快, 因此在过去的这些年中, 通过硬件升级的方法还是帮他们解决了系统的性能问题. 但这种方法的效率正在变得越来越低, 甚至根本不起作用. 我遇到过IBM...
站内搜索 | Search
总数: 512 | 留言: 1560
- Name: Fangxin Lou
- MSN: anysql©live.com
- Mail:anysql©yahoo.com
anysql©gmail.com - Skype: anysql
- AIM: loufangxin
- Mobile:008615925611590