仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 609|回复: 7
打印 上一主题 下一主题

[学习教程] MYSQL网站制作之Oracle专家调优奥密(一)

[复制链接]
小妖女 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-16 22:40:13 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
每个人都在使用它。MySQL是开源LAMP组合的一个标准组件:Linux、Apache、MySQL和Perl/PHP。根据Evans的调查,LAMP组合的迅速推广很大程度上代表着MySQL的被广泛接受。oracle
媒介

在已往的十年中,Oracle已成为天下上最专业的数据库之一。关于IT专家来讲,就是要确保使用Oracle的壮大特征来进步他们公司的临盆力。最无效的办法之一是经由过程Oracle调优。它有大批的调剂参数和手艺来改善你的Oracle数据库的功能。

  Oracle调优是一个庞大的主题。关于调优能够写整整一本书不外,为了改良Oracle数据库的功能,有一些基础的观点是每一个OracleDBA都应当服从的。

  在这篇简介中,我们将扼要地先容以下的Oracle主题:

  --内部调剂:我们应当记着Oracle并非独自运转的。因而我们将检察一下经由过程调剂Oracle服务器以失掉高的功能。

  --Rowre-sequencing以削减磁盘I/O:我们应当明白Oracle调优最主要的方针是削减I/O。

  --OracleSQL调剂。OracleSQL调剂是Oracle调剂中最主要的范畴之一,只需经由过程一些复杂的SQL调优划定规矩就能够年夜幅度地提拔SQL语句的功能,这是一点都不奇异的。

  --调剂Oracle排序:排序关于Oracle功能也是有很年夜影响的。

  --调剂Oracle的合作:表和索引的参数设置关于UPDATE和INSERT的功能有很年夜的影响。

  我们起首从调剂Oracle内部的情况入手下手。假如内存和CPU的资本不敷的话,任何的Oracle调剂都是没有匡助的。

  内部的功能成绩

  Oracle并非独自运转的。Oracle数据库的功能和内部的情况有很年夜的干系。这些内部的前提包含有:

  .CPU--CPU资本的不敷令查询变慢。当查询凌驾了Oracle服务器的CPU功能时,你的数据库功能就遭到CPU的限定。

  .内存--可用于Oralce的内存数目也会影响SQL的功能,出格是在数据缓冲和内存排序方面。

  .收集--大批的Net8通讯令SQL的功能变慢。

  很多老手都毛病的以为应当起首调剂Oracle数据库,而不是先确认内部资本是不是充足。实践上,假如内部情况呈现瓶颈,再多的Oracle调剂都是没有匡助的。

  在反省Oracle的内部情况时,有两个方面是必要注重的:

  1、当运转行列的数量凌驾服务器的CPU数目时,服务器的功能就会遭到CPU的限定。弥补的办法是为服务器增添分外的CPU大概封闭必要良多处置资本的组件,比方OracleParallelQuery。

  2、内存分页。当内存分页时,内存容量已不敷,而内存页是与磁盘上的互换区举行交互的。弥补的办法是增添更多的内存,削减OracleSGA的巨细,大概封闭Oracle的多线程服务器。

  可使用各类尺度的服务器工具来失掉服务器的统计数据,比方vmstat,glance,top和sar。DBA的方针是确保数据库服务器具有充足的CPU和内存资本来处置Oracle的哀求。

  以下让我们来看一下Oracle的row-resequencing是怎样可以极年夜地削减磁盘I/O的。

  Row-resequencing(行的从头排序)

  就象我们下面提到的,有履历的OracleDBA都晓得I/O是呼应工夫的最年夜构成部分。个中磁盘I/O出格凶猛,由于当Oracle由磁盘上的一个数据文件失掉一个数据块时,读的历程就必需守候物理I/O操纵完成。磁盘操纵要比数据缓冲慢10,000倍。因而,假如能够令I/O最小化,大概削减因为磁盘上的文件合作而带来的瓶颈,就能够年夜年夜地改良Oracle数据库的功能。

  假如体系呼应很慢,经由过程削减磁盘I/O就能够有一个很快的改良。假如在一个事件中经由过程按必定的局限搜刮primary-key索引来会见表,那末从头以CTAS的办法构造表将是你削减I/O的主要战略。经由过程在物理大将行排序为和primary-key索引一样的按次,就能够加速取得数据的速率。

  就象磁盘的负载均衡一样,行的从头排序也是很复杂的,并且也很快。经由过程与别的的DBA办理技能一同利用,就能够在高I/O的体系中年夜年夜地削减呼应的工夫。

  在高容量的在线事件处置情况中(onlinetransactionprocessing,OLTP),数据是由一个primary索引失掉的,从头排序表格的行就能够令一连块的按次和它们的primary索引一样,如许就能够在索引驱动的表格查询中,削减物理I/O而且改良呼应工夫。这个技能仅在使用选择多行的时分有效,大概在利用索引局限搜刮和使用收回多个查询来失掉一连的key时无效。关于随机的独一primary-key(主键)的会见将不会由行从头排序中失掉优点。

  让我们看一下它是怎样事情的。思索以下的一个SQL的查询,它利用一个索引来失掉100行:


select
salary
from
employee
where
last_namelikeB%;
  这个查询将会利用last_name_index,搜刮个中的每行来失掉方针行。这个查询将会最少利用100次物理磁盘的读取,由于employee的行寄存在分歧的数据块中。

  不外,假如表中的行已从头排序为和last_name_index的一样,一样的查询又会如何处置呢?我们能够看到这个查询只必要三次的磁盘I/O就读完整部100个员工的材料(一次用作索引的读取,两次用作数据块的读取),削减了97次的块读取。

  从头排序带来的功能改良的水平在于在你入手下手的时分行的乱序性怎样,和你必要由序列中会见几行。至于一个表中的行与索引的排序键的婚配水平,能够检察数据字典中的dba_indexes和dba_tables视图失掉。

  在dba_indexes的视图中,检察clustering_factor列。假如clustering_factor的值和表中的块数量大抵一样,那末你的表和索引的按次是一样的。不外,假如clustering_factor的值靠近表中的行数量,那就标明表格中的行和索引的按次是纷歧样的。

  行从头排序的感化是不成以小视的。在必要举行年夜局限的索引搜刮的年夜表中,行从头排序能够令查询的功能进步三倍。

  一旦你已决意从头排序表中的行,你可使用以下的工具之一来从头构造表格。

  .利用Oracle的CreateTableAsSelect(CTAS)语法来拷贝表格

  .Oracle9i自带的表格从头构造工具

  以下,我们来看以下SQL语句的调优。
也许最好的策略是以不变应万变:给客户他们所需要的,不多也不少。如果MySQL学习教程适合他们,他们就不应该买别的工具。事实上,云计算产业一直推崇自助服务,但提供这些服务的公司已经开始认识到解决方案提供商推销他们商品的价值。
飘灵儿 该用户已被删除
沙发
发表于 2015-1-19 21:08:25 | 只看该作者
理解了存储结构,再阅读下性能优化的章节基本上会对sqlserver有个清晰地认识
若相依 该用户已被删除
板凳
发表于 2015-1-25 23:23:57 | 只看该作者
是否碎片会引发效率问题?这都是需要进一步探讨的东西。varbinary(max)代替image也让SQLServer的字段类型更加简洁统一。
再现理想 该用户已被删除
地板
发表于 2015-2-9 23:20:52 | 只看该作者
一直以来个人感觉SQLServer的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。(有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。)
谁可相欹 该用户已被删除
5#
发表于 2015-2-28 04:42:26 | 只看该作者
对一张百万级别的表建游标,同时又没有什么过滤条件,取得游标效率是如果直接SQL查询百万条数据;如果再对每条记录做处理,耗时将更长。
admin 该用户已被删除
6#
发表于 2015-3-9 21:13:26 | 只看该作者
对一张百万级别的表建游标,同时又没有什么过滤条件,取得游标效率是如果直接SQL查询百万条数据;如果再对每条记录做处理,耗时将更长。
只想知道 该用户已被删除
7#
发表于 2015-3-17 01:10:19 | 只看该作者
但换公司用MSSQL2K感觉自己好像根本就不了解MSSQL。什么DTS触发器以前根本没用过。
若天明 该用户已被删除
8#
发表于 2015-3-23 14:20:45 | 只看该作者
不好!如果出了错;不好调试;不好处理!其实web开发将代码分为3层:web层;业务逻辑层和数据访问层;一般对数据库的操作都在数据访问层来做;这样便于调试和维护!而且将来如果是换了数据库的话;你只需要改数据层的代码;其他层的基本可以不变!要是你在jsp中直接调用sql数据库;那么如果换了数据库呢?岂不都要改?如果报了异常呢?怎么做异常处理?
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-12-24 00:50

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表