oracle10g优化数据库
oracle数据库性能调优
oracle数据库性能调优⼀:注意WHERE⼦句中的连接顺序:ORACLE采⽤⾃下⽽上的顺序解析WHERE⼦句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最⼤数量记录的条件必须写在WHERE⼦句的末尾.尤其是“主键ID=?”这样的条件。
⼆: SELECT⼦句中避免使⽤ ‘ * ‘:ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个⼯作是通过查询数据字典完成的, 这意味着将耗费更多的时间。
简单地讲,语句执⾏的时间越短越好(尤其对于系统的终端⽤户来说)。
⽽对于查询语句,由于全表扫描读取的数据多,尤其是对于⼤型表不仅查询速度慢,⽽且对磁盘IO造成⼤的压⼒,通常都要避免,⽽避免的⽅式通常是使⽤索引Index。
三:使⽤索引的优势与代价。
优势:1)索引是表的⼀个概念部分,⽤来提⾼检索数据的效率,ORACLE使⽤了⼀个复杂的⾃平衡B-tree结构. 通常,通过索引查询数据⽐全表扫描要快. 当ORACLE找出执⾏查询和Update语句的最佳路径时, ORACLE优化器将使⽤索引. 同样在联结多个表时使⽤索引也可以提⾼效率. 2)另⼀个使⽤索引的好处是,它提供了主键(primary key)的唯⼀性验证.。
那些LONG或LONG RAW数据类型, 你可以索引⼏乎所有的列. 通常, 在⼤型表中使⽤索引特别有效. 当然,你也会发现, 在扫描⼩表时,使⽤索引同样能提⾼效率.代价:虽然使⽤索引能得到查询效率的提⾼,但是我们也必须注意到它的代价. 索引需要空间来存储,也需要定期维护, 每当有记录在表中增减或索引列被修改时, 索引本⾝也会被修改. 这意味着每条记录的INSERT , DELETE , UPDATE将为此多付出4 , 5 次的磁盘I/O . 因为索引需要额外的存储空间和处理,那些不必要的索引反⽽会使查询反应时间变慢.。
⽽且表越⼤,影响越严重。
使⽤索引需要注意的地⽅:1、避免在索引列上使⽤NOT , 我们要避免在索引列上使⽤NOT, NOT会产⽣在和在索引列上使⽤函数相同的影响. 当ORACLE”遇到”NOT,他就会停⽌使⽤索引转⽽执⾏全表扫描.2、避免在索引列上使⽤计算.WHERE⼦句中,如果索引列是函数的⼀部分.优化器将不使⽤索引⽽使⽤全表扫描.举例:代码如下:低效:SELECT … FROM DEPT WHERE SAL * 12 > 25000;⾼效:SELECT … FROM DEPT WHERE SAL > 25000/12;3、避免在索引列上使⽤IS NULL和IS NOT NULL避免在索引中使⽤任何可以为空的列,ORACLE性能上将⽆法使⽤该索引.对于单列索引,如果列包含空值,索引中将不存在此记录. 对于复合索引,如果每个列都为空,索引中同样不存在此记录. 如果⾄少有⼀个列不为空,则记录存在于索引中.举例: 如果唯⼀性索引建⽴在表的A列和B列上, 并且表中存在⼀条记录的A,B值为(123,null) , ORACLE将不接受下⼀条具有相同A,B值(123,null)的记录(插⼊). 然⽽如果所有的索引列都为空,ORACLE将认为整个键值为空⽽空不等于空. 因此你可以插⼊1000 条具有相同键值的记录,当然它们都是空! 因为空值不存在于索引列中,所以WHERE⼦句中对索引列进⾏空值⽐较将使ORACLE停⽤该索引.代码如下:低效:(索引失效) SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL;⾼效:(索引有效) SELECT … FROM DEPARTMENT WHERE DEPT_CODE >=0;4、注意通配符%的影响使⽤通配符的情况下Oracle可能会停⽤该索引。
SQL语句执行计划变化的原因分析与应对策略-For Oracle 10g
通常而言,只需按照上文中的两个方面来做,应用的效果会非常的好, 然而在实际进行数据库SQL优化的过程中,当这两个方面的优化措施相互作用 时,却可能产生一些意想不到的情景—产生多版本的执行计划,在一些高访 问负荷,数据量巨大且分布复杂的业务系统中甚至可能引发突然性的性能下 降。 因此,为使业务系统长期稳定运行,以上问题是必须避免的。换言之, 找到多版本执行计划的产生原因并避免由于嵌入变量的处理而导致的执行计 划非正常改变将成为维护好业务系统的关键因素。
六、总结
随着各类业务系统的飞速发展,其数据量和数据复杂性也不断增加,从而引 起的各类由于SQL执行效率不佳所导致的性能问题也日趋严重。 对于数据库开发人员,必须掌握各类业务系统的数据特点。尽量的在开发阶 段就避免今后产生SQL执行计划不佳的现象。 对于数据库维护人员,要充分掌握SQL执行计划变化的各类原因,并能及时处 理因执行计划变差所导致的各类性能问题,确保业务系统的正常运行。
?数据库中触发sql语句硬解析的因素首次sql访问与sql相关对象的ddl操作与sql相关对象的权限变化与sql相关对象的统计信息变化会话或数据库级的优化器参数改变游标过期或共享池刷新三多版本执行计划的产生原因续?多版本执行计划产生的主要原因由此可见由于统计信息与优化器设置是执行计划的决定性因素故造成多版本执行计划产生的根本原因是由于统计信息或优化器参数设置的改变导致在下次触发硬解析时生成了与之前相比不同的执行计划
五、应对策略
在设计阶段确定最优执行计划
A.根据数据分布特性得到最优执行计划:在设计阶段各个数据表的数据特点都是 可预知的,从这些特征出发确定一个执行计划就最为准确,同时也避免了频繁统计收 集。这个执行计划需要与具体的数据无关,不求最快,但求最优,即适合大多数情况。 从技术上而言,可以使用嵌入变量的均值(而非理想或极端值)来创建执行计划。如 果结合优化器指令(HINT)可以更精确的固定一个最优的执行计划,或者缩小BIND- PEEKING所带来的执行计划变化的范围,减少BIND-PEEKING带来的副作用。 如果 很好的应用HINT和嵌入变量,BIND-PEEKING就不会影响到应用的正常运行。 B.适当使用常量与变量的组合:对于数据中的极端值(最大,最小等)可以使用 常量,由数据库自行选定最快执行计划,对于其它值则使用HINT来固定一个折中的执 行计划。
ORACLE数据库性能的调整
ORACLE数据库性能的调整摘要由于oracle具备功能和灵活性突出的优越性,因此它是一个功能极其强大和灵活关系型的数据系统。
在数据库的应用类型上是较为复杂的,不同类型的应用对其系统的要求也是不同的,所以为了能够满足不同类型的应用系统,就必须对系统性能进行定期的诊断和调整,以此来提高系统的运行效率。
关键词 oracle;数据库;优化和调整中图分类号tp311 文献标识码a 文章编号1674-6708(2010)22-0187-02随着数据库在信息领域的不断推广,数据库产品也逐渐增多,其中oracle数据库产品在整个数据库产品的应用中占有较为主要的部分,接近1/2,而且还有不断上升的趋势。
因此,对于oracle数据库性能的调整和优化问题也是人们所关注的问题,本文就oracle数据库性能的调整进行了相应的探讨。
1 性能调整与优化概述目前,性能调整作为一项活动在进行,活动可以通过优化应用程序、修改系统参数和改变系统配置来有效的改变系统的性能。
其中性能的调整主要包括了对硬件配置、操作系统和数据库管理系统的配置的调整,并且对所访问的组件的应用进行详细的分析和优化。
性能优化主要是指具备目的性的对所需调整的组件进行有效的改善,使数据库的吞吐量逐渐变大,所对应的响应时间逐渐达到最小化。
对于数据库性能的调整和优化来说,要尽可能的减少磁盘访问,从中获取所需的数据,数据库性能的调整和优化在一定程度上说是相互循环的,想要性能达到相应的优化目的,就必须进行适当的性能调整,最后再查看优化的结果,通过这种反复的检查,最终达到较为满意的结果。
2 数据库系统性能评价指标2.1 系统吞吐量系统的吞吐量是指在单位时间内数据库所完成的sql语句的数目,这主要是以每秒钟的事务量来进行表示。
想要有效的提高系统的吞吐量,就必须通过减少服务时间,并在相同的资源环境内做更加多的工作,或者减少总的响应时间,从而使工作能够做的更加快。
2.2 用户响应时间用户的响应时间主要是指用户在提交sql语句以后来获取相应的结果集的第一行所需要的时间,并且根据应用做出相应的反应时间,这个时间一般都是使用毫秒和秒来进行表示。
Oracle数据库优化原则和方法
当表 的记录数较大时 , 必然会影响查询速度。 这时 , 通过索引 查 询数据 比全表扫描效率要 高得 多。在写S L Q 语句时 , 应遵循 以 下原则 :避免在索引列上 使用N TI 、 U LI O U L O I N L 、 N TN L 、 NS S LK 等操作符或者 函数计算( IE 如转换字段类型 )否D O al , ] rc 数据 e 库会停止使用索引转而执行全表扫描。实际应用 中 , 有时必须要 在列 中应用函数等条件 ,则可以通过强制索引提示来利用索引。 当然 , 不一定用索引就一定是最优 的, 比如一个表只有两行数据 , 次I 就可 以完成全表 的检索 , / O 而此时用索引则需要两次I 这 / O, 时对这个 表做全表扫描是最好的。
hr d t ,.o ie aeb c mm r m mp ,o u F o e eb n s b w e eee a = .n me h r .n me b e a
、
调 整操 作 系统
ห้องสมุดไป่ตู้
Oal数据库服务器很 大程度上依 赖于运行 服务器 的操作 rce 系统 , 应尽 可能使O al  ̄ rc n 务器使用资源最大化 , e 特别是在Ci t ln e/ Sre,. evr_  ̄间的I 操作 。在数据库中建 表时, / O 对于一些简单且有特 殊要求 的数据 , 上适 当的完整性约束条件 ; 加 对一些较复杂 的处 理规则 , 可以利用数据 库触 发器来实现 , 数据库触发器 由数据本 身实现。另外 , 通过在O al 据库 中创建存储过程和函数 , rce 数 把复 杂 的s L Q 语句存储在服务器端 , 使应用程序 只需要简单地调用存 储过程和函数 , 网络上只需传输调用 的存储过程或 函数 的名字 在 和输出结果 。 这样都 可以有效地减少在客户端和服务器端之间传 递S L Q 语句的可能性 , 减轻网络I 负担。 / O 通 过 长 期 维 护 经 验 总 结 :0 8 %的性 能 问题 都 是 由不 良的S L Q 语句引起的, 所以调剂 和建立最佳的s L Q 语句对于业务系统的可 扩展性 和响应时间来说都显得尤为重要。影响s L Q 语句执行速度 的主要因素有 : 驱动表 的选择是否恰 当、 查询时是否用到恰当的 索引 、 间的连接顺序及条件顺序是否恰 当等 。对于一段准备 表之 执行 的s L Q 语句 , 首先分析其执行计划 。现在有很多 可视化工具 , 比如P Q 或者T A 等都提供 了非常方便的手段来获取 s L L OD Q 语 句的执行计划 。 通过分析执行计划 , 结合涉及到的表 的数据量 , 我 们 可以估算 或者测试该语句 的执行效率 ,分析表WH R 条件中 EE 涉及的字段 。根据s L Q 语句 中使用的查询条件 , 总能够找到一个 性 能最优 的执行方式 。调整S L Q 语句 的写法 , 可以遵循 以下 优化 原则和方法 : 在基于规则的优化方式 ( ue B sd pmi t n 简 R l ae O i z i , — ao 称为R O)的情况下 ,R M子句 中写在最后 的表将作 为驱 动表 B FO 被最后处理 , 在关 联查 询多个表的情况下 , 应选择最有效率 的表
第一章 oracle数据库10g概述
第一章oracle数据库10g概述1.1 数据库和信息管理服务器必须在多用户环境中管理大量的数据,使得多个用户能够并行访问数据。
所有这些必须能够在高性能的情况下完成,数据库服务器必须防止未经授权的非法访问,保护敏感数据,同时,为故障恢复提供解决方案。
▪客户用员务器环境▪大型数据库和空间管理▪多个并行数据库用户▪连接性▪高事务处理能力▪控制可用性▪开放的、基于工业标准▪管理安全性▪数据库完整性增强▪兼容性▪分布式系统▪复制环境1.2 Oracle 10g服务器Oracle 10g服务器是对象关系数据库管理系统,提供对信息管理的集成方法,一个Oracle服务器包括一个Oracle数据库和一个Oracle服务器实例。
每当数据库启动的时候,系统全局区(SGA)被分配,并启动了Oracle后台进程。
系统全局区是用于数据库用户共享数据库信息的内存区域。
后台进程和内存缓冲区称为Oracle实例。
Oracle实例包含两种类型的进程:用户进程和Oracle进程。
用户进程执行应用操作的代码。
Oracle 进程是执行用户进程和后台进程,对Oracle进行维护的服务器进程。
为了最大化性能和处理多个用户的请求,多进程Oracle系统使用附加进程,这些附加进程称为后台进程。
后台进程能够自动执行I/0和监视Oracle进程,为获得更好的性能和稳定性提供更好的支持。
数据库的物理结构和存储结构之间的关系由后台进程来维持。
数据库拥有多个后台进程,其数量取决于数据库的配置。
这些进程由数据库管理,它们只需要进行很少的管埋。
每个后台进程创建一个跟踪文件。
Oracle在实例操作期间保存跟踪文件。
后台进程跟踪文件的命名约定和位置随操作系统和数据库版本不同而不同。
一般来说,跟踪文件含有后台进程名或后台进程的操作系统进程ID.可以设置init.ora文件的BACKGROUND_DUMP_DEST参数来规定后台进程跟踪文件的位置。
但是有些版本的Oracle忽略这种设置。
ORACLE 10G自动化特性在联通BSS系统性能优化工作中的应用
ORACLE 10G自动化特性在联通BSS系统性能优化工作中的应用摘要:在介绍Oracle 9i版本下性能优化的基本方法基础上,着重论述了Oracle 10g版本中的一些自动化特性,以及应用10g中的自动化特性进行数据库系统性能优化的方法和案例。
关键词:Oracle 自动化;10G 优化;ADDMOracle数据库是中国联通核心业务支撑系统中最主要的关系型数据库管理系统。
在联通BSS业务支撑系统的体系结构中,绝大多数的子系统都是典型的在线事务处理系统(OLTP系统),对业务处理的实时性和性能要求非常高。
基于以上情况,对Oralce数据库及BSS应用系统进行不断地性能调整和优化,就成为联通业务支撑工作中一个必不可少的关键性工作。
Oracle 10G中很多性能优化工作可以借助自动化的工具方便快捷地进行,使性能优化工作的效率和效果得以大幅提升。
1Oracle 9i环境下性能优化的典型方法和问题1.1Oracle 9i环境下典型的性能优化步骤通常情况下Oracle 9i环境下的性能优化工作的步骤如下:①用户或应用维护人员反馈:“某个应用场景下,系统反应很慢”;②数据库管理员(DBA)人工观测该应用是否确实比较慢,或者根据以往记录的性能测试数据来比较,确认该性能问题是否确实存在;③使用统计信息收集工具包-StatsPack包(以下简称SP 包),在可能会发生性能问题的时间段,进行性能统计信息搜集(即进行“snapshot快照”);④使用SP包,生成SP分析报告;⑤DBA阅读SP分析报告,结合自己的经验,手工在浩如烟海的信息中找到可能存在的性能瓶颈;⑥对于性能瓶颈,DBA结合自己的经验,手工设计优化方案;⑦DBA或应用系统开发人员,进行数据库配置、数据库对象或应用程序的调整;⑧调整完成后,再次进行性能表现的观测,如果问题没有得到解决,则再次从步骤三开始进行新一轮的过程,直至问题得以解决。
Oracle 9i时期典型的性能优化步骤的示意图如图1所示:图1Oracle9i时期典型的性能优化的步骤1.2Oracle 9i环境下性能优化方法存在的问题从上述步骤中可以明显看出,9i环境下的性能优化,均是DBA人工处理,所有的判断和决策都依靠人来开展,不仅非常耗时耗力,而且对进行优化工作的人员素质要求较高,对DBA 的“经验”要求极高,旺旺只有对业务较熟悉的DBA才能进行一些有效的优化工作。
Oracle数据库10g GIS应用开发:使用Oracle Spatial网络数据模型说明书
Oracle Database 10g: Building GIS Applications Using the Oracle Spatial Network Data ModelAn Oracle Technical White PaperMay 2005Table of Contents Abstract (3)Introduction (3)Oracle Spatial Network Data Model (5)Network Data Model Schema (5)Network Metadata (6)Network Tables (6)Oracle Spatial Network Data Model APIs (6)Network Data Model Analysis Capabilities (7)Modeling Network Applications (8)Network Constraints (8)Java Representations of Network Elements (8)Software Requirements (9)Using the Network Data Model (9)1. Create a Network (9)2. Visualize or Edit the Network (9)3. Analyze the Network (9)Network Data Model Editor (9)GIS Applications using the Network Data Model (10)Network Tracing Applications (10)Network Routing Applications (10)Network Allocation Applications (11)Using Network Constraints in Analysis (11)New Features in the Oracle Spatial 10g Network Data Model (13)Network Modeling: Link Direction (13)Network Analysis: Maximum Flow Analysis (14)PL/SQL Wrapper Package (14)Conclusion (14)References (14)ABSTRACTNetwork modeling, management, and analysis are common tasks for Geographic Information Systems (GIS). Network analysis includes routing (path computation) in transportation networks, tracing (accessibility) in utility networks, and resource allocation in decision-making and customer relationship management (CRM) applications. In this paper we present the Oracle Spatial network data model, an Oracle Database release 10g feature that lets users model and analyze networks. This feature simplifies network modeling, analysis, and management so that users can focus on application logic. The network data model provides an open, generic data model with many common GIS analysis capabilities. In addition, it fully supports Oracle Spatial objects of type SDO_GEOMETRY. GIS applications based on the Oracle Spatial network data model are discussed in this paper. INTRODUCTIONThere are two common types of GIS applications: applications that deal with spatial proximity, and applications that deal with both spatial proximity and connectivity. For many applications queries on spatial proximity, which mainly consider metrics like Euclidean or geodetic distances, are sufficient. However, there are instances when connectivity needs to be taken into account, such as in finding the shortest distance between two locations in a road network. Many GIS applications are networks that require modeling and analysis on object relationships (connectivity). Figure 1 shows a road network of New York City.Figure 1. New York City Road Network (60384 nodes, 151962 links. Source: NavStreets from NavTech)Oracle Spatial has supported spatial objects since release 8.1.5. A complete set of indexes, operators, and functions is available for managing information based on spatial proximity. The network data model extends Oracle Spatial to deal with connectivity. Currently there are many GIS vendors offering network solutions; however, their solutions may have the following issues:• Their data model is stored in proprietary file formats, and cannot be integrated with their database.• The data model and analysis capabilities cannot be extended.• Application information cannot be separated from connectivity information.• Spatial information management and hierarchical relationships are not directly supported.To address these issues, Oracle Spatial network data model does the following: • Provides an open and persistent network data model.The network data model is stored as relational tables in the database and ismanaged through SQL.• Simplifies network data management and analysisPL/SQL and Java APIs are provided for network data management andanalysis.• Separates connectivity and application information in the data model Connectivity information can be separated from application information.Both application information and connectivity information are managed inthe database. However, only connectivity information is required fornetwork analysis.• Allows the extension of data model and analysis capabilitiesThe Java API provides representations of network elements as JavaInterfaces. Users can define their own network elements by extendingthese interfaces. As a result, users can implement their own user-definedrepresentations and analysis functions.• Integrates with Oracle Spatial technology for spatial information managementThe network data model supports all Oracle Spatial data types.This paper is organized as follows: it presents the network data model database schema, APIs and architecture; shows how to use the data model; presents several GIS network applications built on top of the data model; discusses how to use network constraints to enhance analysis capabilities; and discusses the network data model editor that is used to edit and visualize networks.ORACLE SPATIAL NETWORK DATA MODELThe network data model consists of two parts: a network schema and network APIs. The network schema is the persistent data storage used to store network information. The network APIs contain a PL/SQL package for data management in the database and a Java API for data management and analysis on the client-side (via Java JDBC drivers).Network Data Model SchemaA network contains network metadata, a node table, and a link table. In addition, path information (path table and path-link table) can be stored with the network if desired. Figure 2 shows a schematic view of a network in the database. Note that only connectivity information is stored. Additional application information can be stored in the network tables, or in other tables and referenced by foreign keys.Figure 2. Oracle Network Data Model (Schematic View)Network MetadataNetwork metadata provides general information about networks. It includes the following network details:• Directed or undirected• Logical or spatial• Hierarchical or flat• Information about nodes, links, and paths• Geometry information -- for spatial networksNetwork TablesAn Oracle network contains two tables: a node table and a link table. A path table can be added if needed. Figure 2 shows the schema for the network data model, which includes these tables. The schema represents the information necessary for network management and analysis. Application attributes can be added to these tables or referenced from other application tables (through foreign keys). Note that the network data model is also capable of handling geometry information. That is, the network data model can represent both logical and spatial network applications. Adding geometric data to a logical network will allow the logical network to be displayed.Oracle Spatial Network Data Model APIsThe network data model provides a PL/SQL API and a Java API for network management on the database and client sides. The Java API can also be used for network analysis. The three-tiered network data model application architecture is shown in Figure 3.Figure 3. Network Data Model ArchitectureNetwork Data Model Analysis CapabilitiesThe following analyses are supported in the network data model:• Shortest Path: The shortest path from node A to node B• Accessibility Analysis: Is node A accessible from node B?• Minimum-Cost Spanning Tree: What is the minimum-cost tree that connects all nodes?• Within Cost Analysis: What nodes are within a given cost from (to) a given node?• Nearest Neighbors: What are the N nearest neighbors of a given node?• K Shortest Paths: What are the K shortest paths from node A to node B?• Connected Components Analysis: Label connected components with IDs.• Graph Operations: Graph union, intersection, and difference.• Traveling Salesman Problem: What is the minimum-cost tour that visits a set of cities?• Single Source, Single Sink Maximum Flow Analysis: What is the maximum allowable flow that can flow from the source node to the sink node?(Oracle Spatial 10g Release 2)Modeling Network ApplicationsThe network data model takes a generic approach to solving network problems, by separating connectivity information from application-specific information. Figure 4 shows how a typical network application can be modeled and analyzed. First the network connectivity information (node connections and link cost) is extracted and separated from the application-specific information. Application-specific attributes are stored, if needed, with the connectivity information or separately. Once the connectivity information is extracted, network analysis is conducted on the generic model. Additional network constraints can also be considered. The final result is then mapped to application-related attributes, and displayed. This approach avoids customized network solutions and simplifies the data management of connectivity and application-specific information.Figure 4. Network Modeling and Analysis Using the Network Data ModelNetwork ConstraintsThe network data model introduces the concept of network constraints, which provides a mechanism to guide network analysis. For example, you may want to compute the shortest path that passes through network links of a specific type. With network constraints, applications can easily incorporate application-specific logic into the network data model analysis engine without knowing how the engine works. Other constraints, such as path depth, or cost, can also be included in analysis. The network constraint is a Java interface and must be implemented by the application.Java Representations of Network ElementsThe Java network representations (network, nodes, links, and paths) are defined as Java interfaces and can therefore be extended. These interfaces specify the necessary behaviors for the network and its elements. In addition to these interfaces, user-defined analysis functions can be used by applications, allowing the modeling and analysis capabilities of the network data model to be extended.Software RequirementsThe Spatial network data model is shipped with Oracle Database release 10g. The PL/SQL package is pre-loaded in the database and required Java .jar files are provided; the Java API supports JDK (or JRE) version 1.3 or later. The network editor is also included as a utility tool for the network data model. For more information, see the Oracle Spatial Topology and Network Data Models manual. USING THE NETWORK DATA MODELThis section explains the usage of the network data model. There are three major steps.1. Create a Network1. Create and populate network tables and add metadata to the database.2. Create a Java network object using the Java API and save it to thedatabase.2. Visualize or Edit the Network1. Load a network from the database or an XML representation.2. Visualize or edit the Java network object using the network data modeleditor. Store the network in the database, if needed.3. Analyze the Network1. Load a network into a Java network object.2. Conduct network analysis. Save the path results, if needed.NETWORK DATA MODEL EDITORThe network data model editor is a standalone Java application that helps create, edit, and visualize networks. The editor supports viewing operations such as pan, zoom, and auto-fit. It also provides functions to navigate between network elements. All analysis functions are supported in the editor. With the editor, users can create a network from scratch in the client-side and save it to the database. The editor is configurable on element styles, colors, and sizes. Figure 5 shows the network data model editor.Figure 5. Network Data Model EditorGIS APPLICATIONS USING THE NETWORK DATA MODELGIS network analysis may include network tracing, network routing, and network allocation.Network Tracing ApplicationsTracing applications deal with queries like Is node A reachable from node B? or What are the nodes that are reachable or can be reached from a given node? Such queries are common in water or utility networks. Another type of tracing analysis is to find out how many connected components are in a network. Figure 6 shows some such queries.Figure 6. Reachable and Reaching AnalysisNetwork Routing ApplicationsRouting analysis or path computation, probably the most studied topic in network applications, is divided into the following categories:• Shortest Path or Fastest Path (transitive closure problem) (see Figure 7).• K Shortest Paths: Find k shortest paths from a start node to a destination node.• Traveling Salesman Problem (see Figure 7): Find a minimum-cost tour that passes a set of locations.Figure 7. Shortest Path and Traveling Salesman ProblemNetwork Allocation ApplicationsAllocation analysis deals with designating destination points within a network. It provides information on a service area or coverage for points of interest. The network data model supports the following allocation analyses (see Figure 8):• Within Cost: Find all points of interest within a certain distance from a designated location.• Nearest Neighbors: Find the N nearest restaurants to a designated location.• Minimum-Cost Spanning Tree: Find the cheapest way to connect all nodes.Figure 8. Nearest Neighbors, Within Cost, and Minimum Cost Spanning Tree AnalysisUsing Network Constraints in AnalysisConstraints are conditions to be satisfied during analysis. The network data model supports network constraints so that applications can impose application-specific conditions on the network during analysis. The Java interface NetworkConstraint canbe implemented by the user, and passed into any network data model analysis function. Figure 9 shows analysis information that is available for users to implement their network constraintsFigure 9. Analysis Information for Network ConstraintsThe following are some examples of network constraints:• Depth (number of links), cost, and MBR constraintsNetwork analysis can be limited based on the depth of the search path, thecost limit, or the area (minimum bounding rectangle) where the analysisoccurs. These constraints can be used to specify a preferred subset ofpossible solutions. The network data model provides a SystemConstraintclass (which implements the NetworkConstraint class) for these commonnetwork constraints. Users can create an instance of SystemConstraint anduse it in analysis.• Temporarily inactivated nodes or linksSometimes nodes or links must be temporarily turned off before analysisbegins, for example, road segments (links) under construction in a roadnetwork, or water valves (nodes) shut down for repair in a water network.You can make a node or link inactive by setting its state to false. Networkelements that are inactive will not be considered during analysis. Note thatchanging the state of nodes and links does not affect the persistent datamodel.• Routing with specific types of links and nodesSometimes network analysis must only be conducted through nodes andlinks of specific types or with specific requirements.• Turn restrictionsTurn restrictions are constraints involving two links. They are common inrouting for transportation networks. In the following example, aprohibited turn is represented by a start link and an end link (see Figure10). For intersections with turn restrictions, such as no “U” turn or no leftturn, if the search encounters the start link of a prohibited turn, the searchdoes not continue through the end link of that prohibited turn. This typeof restriction can be easily modeled using NetworkConstraint, sinceinformation on the current link and next link is made available to users.Figure 10. Turn Modeling for Road NetworksNEW FEATURES IN THE ORACLE SPATIAL 10G NETWORK DATA MODELWith Oracle Spatial 10g Release 2, the network data model provides the following features:Network Modeling: Link DirectionThe directionality of a link can be further specified at the link level. Unlike the network directionality that determines the directions of all links, a directed network can have links that are directed or bi-directed. A BIDIRECTED column can be added to the link table and used to indicate if a directed link is bi-directed. This modeling enhancement will reduce the storage requirement for directed networks with non-homogeneous link directions (unidirectional and bidirectional).Network Analysis: Maximum Flow AnalysisThe maximum flow analysis function is provided for a single source and single sink flow network. Each link in a flow network has a flow capacity associated with it. The goal of this function is to find the maximum allowable flow that can flow from the source node to the sink node. This type of analysis is commonly seen in communication or logistics network planning.PL/SQL Wrapper PackagePrior to Oracle Spatial 10g Release 2, only the network data model Java API could be used for network editing and analysis. Now, a PL/SQL wrapper package is also provided that helps users edit and analyze networks in PL/SQL. This wrapper package provides nearly equivalent functionality as the Java API. It is done through database Java stored procedures and Java virtual machine in Oracle. CONCLUSIONThe Oracle Spatial network data model, available with Oracle Spatial 10g, is a generic network (graph) modeling and analysis environment for network applications. GIS applications for routing, tracing, and allocation have been discussed. The network data model provides an open, easy-to-use, scalable, efficient, and manageable approach to developing GIS network applications. We are currently working with our customers and partners to extend the modeling and analysis capabilities of the network data model.REFERENCESOracle Spatial Topology and Network Data Models, Oracle Corporation.Oracle Spatial User’s Guide and Reference, Oracle Corporation.Oracle Linear Referencing System: A Technical White Paper, Oracle Corporation. Oracle Spatial Network Data Model: A Technical White Paper, Oracle Corporation.Building GIS Applications Using the Oracle Spatial Network Data Model: An Oracle Technical White Paper May 2005Author: Jack Chenghua WangContributors: Vishal Rao, Nicole AlexanderOracle CorporationWorld Headquarters500 Oracle ParkwayRedwood Shores, CA 94065U.S.A.Worldwide Inquiries:Phone: +1.650.506.7000Fax: +1.650.506.7200Copyright © 2005, Oracle. All rights reserved.This document is provided for information purposes only and thecontents hereof are subject to change without notice.This document is not warranted to be error-free, nor subject to anyother warranties or conditions, whether expressed orally or impliedin law, including implied warranties and conditions of merchantabilityor fitness for a particular purpose. We specifically disclaim anyliability with respect to this document and no contractual obligationsare formed either directly or indirectly by this document. This documentmay not be reproduced or transmitted in any form or by any means,electronic or mechanical, for any purpose, without our prior written permission.Oracle, JD Edwards, and PeopleSoft are registered trademarks ofOracle Corporation and/or its affiliates. Other names may be trademarksof their respective owners.。
Oracle数据库性能优化与案例分析
Oracle数据库性能优化与案例分析
性能优化探讨
• 原因:为什么? • 慢(响应时间) • 慢(吞吐量)
性能优化探讨
• 目的:为了什么? • 快(响应时间) • 快(吞吐量)
性能优化之案例分析
• 案例之方法论 • 案例之登录访问 • 案例之资源 • 案例之锁
性能优化方法论发展
• 登录输入指标测量 • Logons:= EndSnap. logons cumulative– StartSnap. logons
cumulative。 • Logons Per Second:= Logons / TimeInterval
案例之登录访问
登录输出指标测量:
Logon Response Time:= Network Response Time * 10 + Native TCP Logon :=Network Response Time * 10 + Listener Response Time + Native IPC Logon Time 。
案例之登录访问
• 例:
•
某医院HIS业务系统的账户登录操作异常缓慢,部分情况下
甚至会出现长时间的卡壳情况,业务影响主要发生在每天早上
的上班时刻。
案例之登录访问
优化过程: • 账户登录过程一般涉及到在账户表格以及对应日志表格上的冲
突,比如Buffer busy waits或者TX lock。AWR未体现该特征。 • AWR报告显示connection management call elapsed time时间偏长
成功率:98% 高 失败率:2% 低
失败人数:500*2%=10
自动共享内存管理的自动化数据库:Oracle数据库10g Release 2说明书
The Self-Managing Database: Automatic Shared Memory Management with Oracle Database 10g Release 2An Oracle White PaperMay 2005Release 2 Introduction (3)Current Challenges (3)Introducing Automatic Shared Memory Management (4)The SGA_TARGET Parameter (4)Automatically Managed SGA Components (4)Manually Sized SGA Components (6)Benefits (7)More Flexible and Adaptive Memory Utilization (7)Enhanced Performance (7)Ease of Use (7)Enabling Automatic Shared Memory Management (8)Dynamic Modification of SGA Parameters (10)Dynamic Modification of SGA_TARGET (10)SGA Size Advisor (11)Dynamic Modification of Parameters for Automatically Managed Components (12)Modification of Parameters for Manually Sized Components (13)Persistence of Auto Tuned Values (14)Conclusion (14)Release 2INTRODUCTIONOne of the key self-management enhancements in the Oracle Database 10g is Automatic Shared (SGA) Memory Management. This functionality automates the management of shared memory used by an Oracle Database 10g instance and frees administrators from having to manually configure the sizes of shared memory components. Besides making more effective use of available memory and thereby reducing the cost incurred of acquiring additional hardware memory resources, the Automatic Shared Memory Management feature significantly simplifies Oracle database administration by introducing a more dynamic, flexible and adaptive memory management scheme.This paper describes this functionality and illustrates its advantages.CURRENT CHALLENGESThe Shared Global Area (SGA) in Oracle comprises multiple memory components -- a component being a pool of memory used to satisfy a particular class of memory allocation requests. Examples of memory components include the shared pool (used for allocating memory for SQL and PL/SQL execution), java pool (used for java objects and other java execution memory), buffer cache (used for caching disk blocks), etc.In past releases, the Oracle administrator was required to manually set a number of parameters for specifying different SGA component sizes, such as SHARED_POOL_SIZE, DB_CACHE_SIZE, LARGE_POOL_SIZE, and JAVA_POOL_SIZE.The task of manually adjusting the sizes of individual SGA components could pose a few challenges. It may not be easy to determine the optimal sizes of these components suitable for a given workload. Oracle9i Database alleviated this problem to a great extent by introducing advisory mechanisms that allow DBAs to determine the optimal sizes of the buffer cache and shared pool. However, these recommendations still had to be implemented by the administrator. This challenge is further compounded in situations in which the workload tends to vary with the time of the day e.g., online users during the day and batch jobs atnight. Sizing for peak load could mean memory wastage while under-sizing may cause out-of-memory errors (ORA-4031). For example if a system is configured with a big large pool to accommodate a nightly RMAN backup job, most of this memory – which could have been better utilized in the buffer cache or shared pool for OLTP activity – remains unused for the most part of the day. At the same time, the cost of failures could be prohibitive from a business point of view leaving administrators with few other options.INTRODUCING AUTOMATIC SHARED MEMORY MANAGEMENTTo resolve these challenges, Oracle Database 10g introduces Automatic Shared Memory Management. In Oracle Database 10g, DBAs can just specify the total amount of SGA memory available to an instance using the new parameterSGA_TARGET. The database server then automatically distributes the available memory among various components as required. The Automatic Shared Memory Management feature is based on a sophisticated algorithm internal to the database that continuously monitors the distribution of memory and changes it periodically as needed, according to the demands of the workload.The SGA_TARGET ParameterThe SGA_TARGET parameter reflects the total size of the SGA and includes memory for:• Fixed SGA and other internal allocations needed by the Oracle instance • Log buffer• Shared Pool• Java Pool• Buffer Cache• Keep/Recycle buffer caches (if specified)• Non standard block size buffer caches (if specified)• Streams Pool (new in Oracle Database 10g)An important point to note is that SGA_TARGET includes the entire memory for the SGA. Thus, SGA_TARGET allows the user to precisely control the size of the shared memory area allocated by Oracle.Automatically Managed SGA ComponentsWhen SGA_TARGET is set, the most commonly configured components are sized automatically. These include:1. Shared pool (for SQL and PL/SQL execution)2. Java pool for (java execution state)3. Large pool (for large allocations such as RMAN backup buffers)4. Buffer cache5. Streams poolThere is no need to set the of size any of the above components explicitly and by default the parameters for these components will appear to have values of zero. Whenever a component needs memory, it can request that it be transferred from another component via the internal auto-tuning mechanism. This will happen transparently without user-intervention.The performance of each of these components is also monitored by the Oracle instance. The instance uses internal views and statistics to determine how to optimally distribute memory among the automatically sized components. As the workload changes, memory is redistributed to ensure optimal performance with the new workload. This algorithm is never complacent and always tries to find the optimal distribution by taking into consideration long term as well as short terms trends.The administrator can still exercise some control over the sizes of the auto-tuned components by specifying minimum values for each of these components. This can be useful in cases in which the administrator knows that an application needs a minimum amount of memory in certain components to function properly. The minimum value of a component is specified by setting the corresponding parameter for the component.Here is an example configuration:SGA_TARGET = 132MSHARED_POOL_SIZE = 32MDB_CACHE_SIZE = 20MIn the above example, the shared pool and the default buffer pool will not be sized below the specified values (32M and 20M, respectively). This implies that the remaining 80M can be distributed across all the components. The actual distribution of values between the SGA components may be as follows:Actual Shared Pool Size = 92MActual buffer cache size = 20MActual java pool size = 16MActual Large Pool Size = 0MOther = 4MThe fixed view V$SGA_DYNAMIC_COMPONENTS displays the current size of each SGA component while the parameter values (e.g. DB_CACHE_SIZE, SHARED_POOL_SIZE) specify the minimum values. The current sizes of the SGA components can also be obtained by looking at the Enterprise Manager memory configuration page.Fig 1: EM displays the current sizes of automatically tuned SGA componentsManually Sized SGA ComponentsThere are a few SGA components whose sizes are not automatically adjusted. The administrator needs to specify the sizes of these components explicitly, if needed by the application. Such components are:• Keep/Recycle buffer caches (controlled by DB_KEEP_CACHE_SIZE and DB_RECYCLE_CACHE_SIZE)• Additional buffer caches for non-standard block sizes (controlled by DB_<N>K_CACHE_SIZE, N={2,4,8,16,32})The sizes of these components is determined by the administrator-defined value of their corresponding parameters. These values can, of course, be changed any time either using Enterprise Manager or from the command-line via the ALTER SYSTEM command.The memory consumed by manually sized components reduces the amount of memory available for automatic adjustment. So for example, in the following configuration:• SGA_TARGET = 256M• DB_8K_CACHE_SIZE = 32MThe instance has only 224M (256 – 32) remaining to be distributed among the automatically sized componentsBENEFITSMore Flexible and Adaptive Memory UtilizationThe most significant benefit of using automatic SGA memory management is that the sizes of the different SGA components are flexible and will adapt to the needs of a workload without requiring user intervention.Let us illustrate this with an example. Consider a manual configuration in where 1G of memory is available for SGA and distributed as follows (for the purpose of simplicity we ignore other SGA components for now):SHARED_POOL_SIZE=128MDB_CACHE_SIZE=896MIn this case, if the application ever tries to allocate more than 128M of memory from the shared pool, it will receive an ORA-4031 indicating that available shared pool has been exhausted. Note that when this condition happens, there may be free memory in the buffer cache - but it is not accessible to the shared pool. The user will then manually have to shrink the buffer cache and grow the shared pool to work around this problem.Instead with automatic management, the DBA can simply set:SGA_TARGET = 1GIn this case, if the application needs more shared pool memory for avoiding an ORA-4031 error condition, it will simply obtain that memory by acquiring it from the buffer cache.Enhanced PerformanceBesides maximizing the use of available memory, the Automatic Shared Memory Management feature can enhance workload performance as well. With manual configuration, it is possible that compiled SQL statements will frequently age out of the shared pool because of its inadequate size. This will manifest in terms of frequent hard parses and, hence, reduced performance. However when automatic management is enabled, the internal tuning algorithm will monitor the performance of the workload and grow the shared pool if it determines that doing so will reduce the number of parses required. This is one of the most wonderful aspects of Automatic Shared Memory Management feature since it provides enhanced out-of-box performance, without requiring any additional resources or manual tuning effort.Ease of UseHaving just a single parameter to deal with greatly simplifies the job of administrators. DBAs can now just specify the amount of SGA memory an instance has its disposal and forget about the rest. They do not need to figure outthe sizes of individual components any more. In addition, they can be assured of the fact that no out of memory errors will be generated unless the system has truly run out of memory.ENABLING AUTOMATIC SHARED MEMORY MANAGEMENTThe Automatic Shared Memory Management feature can be enabled either using EM or by setting the SGA_TARGET parameter.When migrating from a manual scheme, it is best to tally the existing values of the SGA parameters and add a small amount (e.g. 16MB) to account for fixed SGA and internal overhead. At the same time the values of the automatically sized components can be removed from the parameter file.For instance, when migrating from the following configuration:SHARED_POOL_SIZE=256MDB_CACHE_SIZE=512MLARGE_POOL_SIZE=256MLOG_BUFFER=16MThe above parameters can be replaced withSGA_TARGET = 256 M + 512M + 256 M + 16M + 16 M (fixed SGA overhead) = 1056 MAutomatic Shared Memory Management may also be enabled dynamically. If you are using Enterprise Manager, you can enable SGA tuning by clicking the enable button on the SGA screen in the Memory Parameters section.Fig 2: Enabling Automatic Shared Memory Management using Enterprise Manager When enabling the Automatic Shared Memory Management feature using EM, the appropriate value for SGA_TARGET is automatically calculated according to the formula described above. In addition, EM also unsets all the parameters specifying the size of individual components in order to maximize the benefit of automatic management.If using command line interface, the steps involved in enabling Automatic Shared Memory Management are as follows:• Dynamically set SGA_TARGET to the current SGA size. The current size of the SGA can be determined from the fixed-view V$SGA via thefollowing query:select sum(value) from v$sga;• Next dynamically set each of the auto-tuned component sizes to zero so that the automatic shared memory tuning algorithm can modify the sizes as needed.If the above query for example returns the result of 536870912 (or 512M) then the steps for enabling auto SGA are as follows:alter system set sga_target=512M;alter system set db_cache_size = 0;alter system set shared_pool_size = 0;alter system set large_pool_size = 0;alter system set java_pool_size = 0;DYNAMIC MODIFICATION OF SGA PARAMETERSDynamic Modification of SGA_TARGETThe SGA_TARGET parameter is dynamic and can be increased up to the value specified by the parameter SGA_MAX_SIZE. The value of this parameter can also be reduced. In that case, one or more automatically tuned components are identified to release memory. The value of the SGA_TARGET parameter can be reduced until one or more auto-tuned components reach their minimum size. The change in the amount of physical memory consumed when SGA_TARGET is modified depends on the OS platform. On some Unix platforms that do not support dynamic shared memory, the physical memory in use by the SGA is equal to the value of SGA_MAX_SIZE. On such platforms, there is no real benefit in running with a value of SGA_TARGET less than SGA_MAX_SIZE and setting SGA_MAX_SIZE on those platforms is, therefore, not recommended. On other platforms, such as Solaris and Windows, the physical memory consumed by the SGA is equal to the value of SGA_TARGET parameter.Note that when SGA_TARGET is resized, the only components to be affected are the auto-tuned components. Any manually configured components remain unaffected.For example, if we have an environment with the following configuration:SGA_MAX_SIZE=1024MSGA_TARGET = 512MDB_8K_CACHE_SIZE = 128MIn this example, the value of SGA_TARGET can be resized up to 1024M and can also be lowered until one or more of the buffer cache, shared pool, large pool, or java pool reaches its minimum size (the exact value depends on environmental factors such as the number of CPUs on the system). But the value of DB_8K_CACHE_SIZE will remain fixed at all times at 128M.Also, when SGA_TARGET is reduced, if the values for any auto-tuned component sizes have been specified to limit their minimum sizes, then those components will not shrink below their respective minimums. Therefore, if we have the following combination of parameters:SGA_MAX_SIZE=1024MSGA_TARGET = 512MDB_CACHE_SIZE = 96MDB_8K_CACHE_SIZE = 128MThe Self-Managing Database: Automatic SGA Memory Management with Oracle Database 10g Release 2 PageIn this example, in addition to the DB_8K_CACHE_SIZE being permanently fixed at 128M, the primary buffer cache will not shrink below 96M. This imposes an additional restriction on how far the value of SGA_TARGET can be reduced.SGA Size AdvisorTo determine the appropriate value for SGA_TARGET, Oracle provides the SGA Size Advisor. The SGA size advisor can be accessed from the Memory Parameters page of the EM interface.Fig 3: Accessing the SGA advisorThe advisor performs a what-if analysis to quantify the expected impact on the overall system performance for various sizes of the SGA. In the example below, the best improvement will be obtained by setting the SGA_TARGET value to 164M.Fig 4: SGA advisorAn alternative to using the EM interface is to query the$SGA_TARGET_ADVICE view.Dynamic Modification of Parameters for Automatically Managed ComponentsWhen the parameter SGA_TARGET is not set, the rules governing resize for all SGA_TARGET component parameters are the same as in earlier releases. This is because in the absence of SGA_TARGET, the Automatic Shared Memory Management feature is disabled.However, as mentioned earlier, when Automatic Shared Memory Management is enabled, the manually specified size of an automatically sized component (e.g. SHARED_POOL_SIZE), serves as a lower bound for the size of that component. It is possible to modify this limit dynamically by altering the value of the corresponding parameter.If the specified lower limit for the size of a given SGA component is less than its current size, there is no immediate change in the size of that component. The value simply limits the auto-tuning algorithm to that reduced minimum size in the future.For example, if:SGA_TARGET = 512M,SHARED_POOL_SIZE = 256M(Current) Shared Pool size = 284MIn this example, dynamically resizing the SHARED_POOL_SIZE parameter down to 128M or lower has no effect on the current size of the shared pool. Also note that setting the size of an automatically sized component to zero disables the enforcement of any user minimum on the size of the component. As stated earlier, this is the default behavior of automatically sized components when SGA_TARGET is set.However, if the value of the parameter is raised to be greater than the current size of the component, the component will grow in response to the resize to accommodate the increased minimum. In the above example, if the value of SHARED_POOL_SIZE is resized up to 300M, then the shared pool will grow till it reaches 300M. This resize will happen at the expense of one or more auto-tuned components.It is important to note that manually limiting the minimum size of one or more automatically sized components reduces the total amount of memory available for dynamic adjustment, thereby limiting the system’s ability to adapt to workload changes. Consequently, the use of this option is not recommended barring exceptional cases. The default automatic management behavior has been designed to maximize both system performance and the use of available resources.Modification of Parameters for Manually Sized Components Parameters for manually sized components can be dynamically altered as well, the difference being that the value of the parameter always specifies the precise size of its corresponding component.Therefore, if the size of a manual component is increased, extra memory is taken away from one or more automatically sized components. If the size of a manual component is decreased, the memory that is released is given to the automatically sized components.For example:SGA_TARGET = 512MDB_8K_CACHE_SIZE=128MIn this case, increasing DB_8K_CACHE_SIZE to 144M (or by 16M) will mean that the 16M will be taken away from the automatically sized components.Likewise, shrinking DB_8K_CACHE_SIZE to 112 M (or by 16M) will mean that the 16M will be given to the automatically sized components. PERSISTENCE OF AUTO TUNED VALUESThe sizes of the automatically tuned components are remembered across shutdowns if a server parameter file (SPFILE) is used. This means that the system will not need to learn the characteristics workload from scratch each time and will pick up where it left off from the last shutdown.For this reason it is highly recommended that an SPFILE be used in conjunction with the Automatic Shared Memory Management feature.CONCLUSIONMemory is a precious system resource and administrators currently spend a significant amount of their time optimizing its use. With Automatic Shared Memory Management, they are relieved of this time consuming and often tedious exercise. The flexibility and adaptiveness of this solution will ensure the best possible utilization of existing resources and thereby help organizations reduce capital expenditure. Just another example of how the Oracle Database10g is going to let administrators play more strategic roles and allow businesses to become more profitable!The Self-Managing Database: Automatic SGA Memory Management with Oracle Database 10g Release 2 May 2005Author:Tirthankar Lahiri, Arvind NithrkashyapContributing Authors:Sushil Kumar, Brian Hirano, Kant Patel, Poojan Kumar, Herve LejeuneOracle CorporationWorld Headquarters500 Oracle ParkwayRedwood Shores, CA 94065U.S.A.Worldwide Inquiries:Phone: +1.650.506.7000Fax: +1.650.506.7200Oracle Corporation provides the softwarethat powers the internet.Oracle is a registered trademark of Oracle Corporation. Variousproduct and service names referenced herein may be trademarksof Oracle Corporation. All other product and service namesmentioned may be trademarks of their respective owners.Copyright © 2002 Oracle CorporationAll rights reserved.。
Oracle10g数据库系统性能优化与调整
Orce数 据 库 系统 性 能 的 因素 入 手 , 优 化 策 略 , 包括 内存 区 调 整 与 优 化 、 盘 I0 优 化 、 盘 碎 磁 / 磁
ZH EN Fu—do ng
( vlA it nAi TrfcCo to a c fGa s , a z o 3 0 7 Chn ) Cii vai r af nr l n h o nu L n h u 7 0 8 , ia o  ̄ Br
Absr t t ac :Or ce d tbae i c 'n l he n o tw i l u e a g —sae d tbae ,d tb s t i t nce s h m be o u 一 a l aa s s une ty t l s dey s d lr e c l aa s s aa a edaaw t he i ra eoft e nu h rofc nc r
甄福东
( 肃 省 兰 州 市 川 机 场 民航 甘 肃 窄 管 分 局 技 术 保 障部 ,{ 兰 州 7 0 8 ) 甘 }肃 3 0 7
摘 要 : al 据 库 是 当前 应 用 最 广 泛 的 大 型数 据 库 , 着 数 据 库 数 据 量 的增 大 、 发 用 户 数 量 增 多 , Or e数 c 随 并 系统 常 常 出现 吞 吐 量 降低 , 响
a lz sO r ce d tb s yse ro m a c mpa tfc o ,w e f u e n he O r ce g daa a C s tm o tmi ai tae y ncu n nay e a l aa ae s tm pef r n e i c a t r oc s d o t a l 1 tb S yse 0 pi z t on srt g ,i l dig
Oracle配置优化
Oracle 学习笔记数据库命令 (2)Oracle的分区 (3)Oracle性能调优 (6)数据库命令查看用户表大小Select Segment_Name,Sum(bytes)/1024/1024 From User_Extents Group By Segment_Name查看表空间大小Select Tablespace_Name,Sum(bytes)/1024/1024 From Dba_Segments Group By Tablespace_Name创建表空间create tablespace tablespacename datafile ‘full path’ size numM online删除默认表空间USERS,由于USERS表空间在安装的时候默认为文件系统,有些时候处于数据库设备建立的需要,比如说建立成裸设备,我们需要将USERS表空间改成我们自己建立的裸设备,而USERS为数据库的默认表空间,直接删除是不可以的,那么就要使用命令将数据库默认表空间改成我们新建立的表空间,例如,新的表空间为USERS01,则使用alter database default tablespace USERS01然后drop tablespace USERS including contents查看表空间的物理路径以及大小select tablespace_name, file_id, file_name,round(bytes/(1024*1024),0) total_spacefrom dba_data_filesorder by tablespace_name查看表空间Select Tablespace_Name,Sum(bytes)/1024/1024From Dba_SegmentsGroup By Tablespace_Name关于WEB控制台创建一个EM资料库emca -repos create重建一个EM资料库emca -repos recreate删除一个EM资料库emca -repos drop配置数据库的 Database Controlemca -config dbcontrol db删除数据库的 Database Control配置emca -deconfig dbcontrol db重新配置db control的端口,默认端口在1158emca -reconfig portsemca -reconfig ports -dbcontrol_http_port 1160emca -reconfig ports -agent_port 3940先设置ORACLE_SID环境变量后,启动EM console服务emctl start dbconsole先设置ORACLE_SID环境变量后,停止EM console服务emctl stop dbconsole先设置ORACLE_SID环境变量后,查看EM console服务的状态emctl status dbconsole配置dbconsole的步骤emca -repos createemca -config dbcontrol dbemctl start dbconsole重新配置dbconsole的步骤emca -repos dropemca -repos createemca -config dbcontrol dbemctl start dbconsole查看目前数据库字符集select * from v$nls_parameters查看表大小select segment_name,(bytes/1024)/1024||'M',((BLOCKS*8196)/1024)/1024||'M'from USER_segments where segment_name='tablename'Oracle的分区全局索引适用于在全部记录中查询,比如要查询一个手机号之类的global index就是为整个分区表建立了一个大的索引。
ORACLE 10g数据库性能优化与分析
ORACLE 10g数据库性能优化与分析摘要:随着数据库在生活中各个领域中的广泛应用,数据库产品也层出不穷。
其中,oracle数据库产品在整个数据库产品的应用中占据50%,并且有不断上升的趋势。
可是,随着数据库数据量的增大、并发用户数量增多,系统常常出现吞吐量降低,响应时间延长等性能问题,怎样有效优化、改善数据库性能,突破系统瓶颈,是保证 oracle 数据库高效运行的基础。
oracle 数据库系统性能优化、调整是一项复杂的系统工程,贯穿于系统的整个生存周期中。
关键词:oracle数据库;性能优化;索引;sql语句中图分类号: tp311 文献标识码: a 文章编号:1009-3044(2013)13-2943-031 概述数据库优化不仅仅是dba(数据库管理员)的事情,它也是设计人员、应用开发人员必须做的事情。
有人认为,优化数据库不用着急,在系统出现宕机或者慢到无法忍受时再优化不迟。
但此时,往往无法有效的对相应的数据库进行更为有效的优化。
所以我们应当在整个数据库的生命周期中,给予不断地优化,以使数据库达到最好的性能[1]。
2 数据库系统性能评价指标2.1 系统吞吐量2.2 响应时间响应时间是,在用户提交任务要求到数据库做出回应的时间。
其实质就是,终端客户等待后台处理所花费的时间[2]。
因此响应时间优化的重要性不言而喻。
调查显示,当用户等待一项任务的响应时间超过几秒钟时,用户可能就会对此系统产生不满或者厌烦的情绪。
因此,我们必须通过优化,将响应时间降到最低。
2.3 数据库的命中率数据库命中率是数据库性能中非常重要的评价指标,包括数据库缓冲区命中率和共享池命中率。
缓冲区命中率是指用户需求的数据是否存放在在内存中,该命中率是指高速缓存命中总数除以高速缓存的查找总数;共享池命中率决定了用户提交的 sql语句是否需要进行重新解析,该比率等于 sql 语句的解析次数除以sql语句总的执行次数。
通常情况,数据库的命中率应该在 90%左右,低于这个值的系统均需要做出优化和调整[3]。
让Oracle跑得更快
让Oracle跑得更快—Oracle 10g性能分析与优化思路目录第1章引起数据库性能问题的因素11.1 软件设计对数据库的影响11.1.1 软件架构设计对数据库性能的影响11.1.2 软件代码的编写对数据库性能的影响21.2 数据库的设计81.2.1 OLTP数据库91.2.2 OLAP数据库101.3 数据库的硬件设计141.3.1 存储容量151.3.2 存储的物理设计161.3.3 数据的安全171.4 小结19第2章锁和阻塞202.1 关于锁202.2 锁和阻塞222.3 引起阻塞的其他情况302.3.1 select for update 302.3.2 外键和索引36第3章Latch和等待443.1 共享池中的Latch争用45.3.2 数据缓冲池Latch争用543.2.1 表数据块543.2.2 索引数据块593.2.3 索引根数据块623.2.4 段头数据块65第4章优化器664.1 RBO基于规则的优化器664.2 CBO基于成本的优化器69第5章执行计划855.1 Cardinality (基数)855.2 SQL的执行计划94第6章Hint 1096.1 和优化器相关的Hint 1156.1.1 all_rows和first_rows(CBO)1156.1.2 RULE Hint 1176.2 访问路径相关的Hint 1176.2.1 FULL Hint 1186.2.2 INDEX Hint 1186.2.3 NO_INDEX Hint 1186.2.4 INDEX_DESC Hint 1196.2.5 INDEX_COMBINE Hint 1196.2.6 INDEX_FFS 1196.2.7 INDEX_JOIN 1206.2.8 INDEX_SS Hint 1206.3 表关联顺序的Hint 1256.3.1 LEADING Hint 1256.3.2 ORDERED Hint 1266.4 表关联操作的Hint 1276.4.1 USE_HASH,USE_NL和USE_MERGE Hint 127 6.4.2 NO_USE_HASH Hint 1326.4.3 NO_USE_MERGE Hint 1336.4.4 NO_USE_NL Hint 1336.5 并行执行相关的Hint 1346.5.1 PARALLEL Hint 1346.5.2 NO_PARALLEL Hint 1346.6 其他方面的一些Hint 1356.6.1 APPEND Hint 1356.6.2 DYNAMIC_SAMPLING Hint 1356.6.3 DRIVING_SITE Hint 1366.6.4 CACHE Hint 1366.7 小结136第7章分析及动态采样1387.1 直方图1417.2 DBMS_STATS包1477.3 动态采样1767.3.1 什么是动态采样1767.3.2 动态采样的级别1827.3.3 什么时候使用动态采样?1857.4 小结185第8章并行执行1868.1 并行和OLAP系统1878.2 并行处理的机制1898.3 读懂一个并行处理的执行计划1918.4 一个很常见的并行执行等待事件1928.5 并行执行的适用范围1948.5.1 并行查询1948.5.2 并行DDL操作1958.5.3 并行DML操作2038.6 并行执行的设定2108.6.1 并行相关的初始化参数2108.6.2 并行度的设定2118.7 直接加载2138.7.1 直接加载和REDO 2168.7.2 直接加载和索引2198.7.3 直接加载和并行2218.7.4 直接加载和SQL*LOADER 226第9章变量绑定2329.1 什么是变量绑定,为什么要做变量绑定2329.2 为什么说OLTP必须要求变量绑定而OLAP不应该绑定变量241 9.3 bind peaking 248第10章SQL_TRACE和10046事件25410.1 SQL_TRACE 25410.2 TKPROF工具25610.3 10046事件268第11章10053事件276第12章性能视图和性能参数29412.1 性能视图29412.1.1 V$SQL 29512.1.2 V$SQL_SHARED_CURSOR 30012.1.3 v$session 30512.1.4 V$sessstat 30912.1.5 V$session_wait 31012.2 性能参数31212.2.1 Cursor_sharing 31312.2.2 DB_FILE_MULTIBLOCK_READ_COUNT 32812.2.3 PGA_AGGREGATE_TARGET和SGA_TARGET 33412.2.4 OPTIMIZER_DYNAMIC_SAMPLING 334第13章性能报告33513.1 AWR性能报告33513.1.1 生成AWR性能报告33713.1.2 AWR性能报告分析34213.2 Statspack性能报告38613.2.1 Statspack的安装38613.2.2 Statspack性能采集39113.3 ASH性能报告39413.3.1 生成ASH性能报告39513.3.2 ASH性能报告分析40513.4 小结416附录A 常见的等待事件417后记关于数据库的学习方法434。
关于Oracle 10g数据库系统性能优化与调整的研究
1 前 言
I T系统随着支持用量的增长和 新业务的不断扩 展, 数据 处理量 大量 增加 , 业 务处理模式 日趋 复杂 , 必然导致主机 C P U和 I / O占用不 断呈线 性增加。因此,充分使用先用硬件的处理能力对于保护投资至关重要。 O r a c l e 数据库 是现在 使用最广 泛的大型数据库之一 , 但是在 实际的应用 中, 不断增加的数据量和访 问量都会导致 O r a c l e数据库系统性能的降低 现象 , 这就 产生了对 O r a c l e数据库系统的优化 的需求, 通过相关 的优化 和调整 手段 , 以实现更快 的响应 时间、 更大 的吞 吐量 以及更少 的资源 占 用等 。
3 数 据库 系统性 能优 化与调 整
数据库系统 的优化与调整的 目的是通过对 0 r a c l e 1 O 数据库性能的
库配置等) 着手 , 实现对数据库 的体 系结构、 软件结构 、 具体的业务和 技 术等方面 的优 化效 果, 使得数据库系统 实现更快的响应 时间、 更大 的吞
点的通过率较低 。在 振动筛 的极限速度 已知的情 况下, 筛孔大小的计算 公式为:
d= r +V( 2 r / g )
在计算振动筛结构参数的过程 中, 还要注 意的是筛面的倾角与 吊杆 的角度 。 这主要是因为筛面的倾角和 吊杆的角度决定了振动筛筛分的时 间, 因而合理的调整筛面斜角与 吊杆的角度能够提高振动筛筛分的工作 效率 。
影 响因素 在0 r a c l e 数据库 系统性 能中的地位 数据 库服 数据库服务器是整个 O r a c l e 数据系统的核心, 服务器上运行的操作系 务器性能 统 以及服务器的硬件配 置对 0 r a c 1 e 数据系统产生直接 影响。 数据库配 数据库 的配置主要包括内存区的设置 、 I / O设置 、 相关参数设置、 回滚 置 段设置以及碎 片整理等 , 数据库配置情况对于数据库系统性能具有极 为重要的作用 , 是进行 0 r a c l e 数据库性能优化调整的核心。 网络 I / O 在0 r a c l e 数据库, 应用程序与服务器之间所进行 的交互主要是通过 网 络I / O完成, 因此网络 I / O对数据库系统性能有重要的影响。 应用程序 应用程序性能, 尤其是 S Q L语句的应用、 数据库端程序 设计以及数据 性能 库对象 的使用情况等由于能够影响 O r a c l e 数据库的执行效率, 因此其 对 数 据 库 性 能 的影 响也 是至 关 重 要 的 。
ORACLE 10g数据库性能优化与分析
E — ma i l : j s l t @d n z s . n e t . C n
ht t p: / / www. d nz s . n e t . c n
C o mp u t e r K n o w l e d g e a n d T e c h n o l o g y电脑 知 识 与技术
o p t i m i z a t i o n , a d j u s t me n t i s a c o m p l i c a t e d s y s t e m e n g i n e e r i n g , r u n s t h r o u g h t h e w h o l e s y s t e m l i f e c y c l e .
ma n c e , b r e a k t h r o u g h t h e b o t t l e n e c k o f s y s t e m, i s t o e n s u r e e ic f i e n t o p e r a t i o n o f t h e Or a c l e d a t a b a s e . Or a c l e d a t a b a s e p e f r o r ma n c e
摘要 : 随着数 据库在生活 中各个领域 中的广泛应 用, 数据库产品也层 出不穷。其 中, O R A C L E数据库产品在 整个数据库产
品的应用 中占据 5 0 %, 并且有不断上升的趋势。可是 , 随着数据库数据量的增大、 并发 用户数量增 多, 系统常常 出现吞 吐量 降低 , 响 应时间延长等性 能问题 , 怎样 有效优化 、 改善 数据库性能 , 突破 系统瓶 颈 , 是保证 O r a c l e 数 据库高效运行 的基 础。 O r a c l e 数据库 系统性能优化 、 调整是一项复杂的 系统工程 , 贯 穿于系统的整个生存 周期 中。
ORACLE 10g数据库技术查询性能浅谈
意 的是 , 个 优化是 有 限的 。 这
实验 5查询 E : MP表 和 D P E T表 , 示 部 门号 为 显 语 法 格式 为 :Q > S L C a , a R M S L E E Te me nme O n d F
e e 进程接下去就对书写语 v 通过分析 S L Q 语句中的 Sl t e c语句 ,来看数据 语法上的定义话 ,则 Sr r e 句 中的字段、 数据类型等 内容进行检查。确认这些字 库进 行 的查询 活 动 。 数据类型是否在数据库中。因此如果表名与列名 首先 , 要在 Ci t ln 书写 S L语句并执行时 ,ln e Q Ci t 段 、 e 数据库会就会反馈错误信息给 C et i ln。 就把 这 条 S L语 句发 送 给 Sre,evr Q evrSre 的进程 就会 不贴切的话 , () 4 经过 检查 ,Q S L语 句 的语法 、 义 都正 确后 , 语 来处 理 这条 Slc 语 句 。 eet 以防我们在查询的过程 中, 其次,当 S L Q 语句被传送到 Sr r ,e e进 为了保障数据的一致性 , e e后 Sr r v v 其他用户对查询对象的结构进行修改 ,系统就会锁 程就 会对 传送 过来 的语 句进行 分析 。 同理 ,这个分析 的工作 ,也是在 Sr r e e 方进行 定 我们需 要查 询 的对 象 。 v
不能够获取这些数据。所 以, 数据库 Sr r e e 进程是先 v
检 查语 法 与语义 , 然后 才会 检查访 问权 限 。
s o te c t・ mp;
这样显示的结果 比较直观 ,用户操作起来也很 () 6 经过上述一些列检查后 , 当我们确认语句 方便。 与语 法 都 没 有 问题 ,同时 也有 查 询权 限 的话 ,evr Sre 1 高级 S L连接 查 询 、 Q
Oracle数据库性能优化指南说明书
Real-World Performance Training Parallel ExecutionReal-World Performance TeamParallel ExecutionSerial and Parallel Execution•Serial Execution–SQL is executed by one process–The correct solution when:•the query references a small data set•high concurrency•efficiency is important•Parallel Execution–SQL is executed by many processes working together–The correct solution when:•the query references a large data set•low concurrency•elapsed time is important•Used to reduce the execution time of queries–Multiple processes work together to use more resources on the system, such as CPU and IOParallel ExecutionBasicsQuery Coordinator (QC)The “top level” process for the parallel queryParallel Execution Server (PX)An (OS) process that operates on part of a parallel query Parallel server group The group of parallel server processes that operate on arow sourceDegree of Parallelism (DoP)The number of parallel execution servers used in eachparallel server group during parallel executionParallel ExecutionWays to set the DoP•Table Setting–Can specify a value or set to parallel default•Hint–Useful for testing but usually not appropriate for production •Alter session–Useful for testing but usually not appropriate for production •Auto DoP–The optimizer determines the DoPParallel ExecutionConfiguration Parameters•parallel_min_servers–Specifies the minimum number of px processes started for the instance•parallel_max_servers–Specifies the maximum number of px processes started for the instance •parallel_threads_per_cpu–Specifies the number of px processes per CPU—OS threads are already accounted for in CPU_COUNT, so set to 1•Parallel_degree_policy–Determines how the DoP is calculatedParallel ExecutionPARALLEL_DEGREE_POLICY Parameter•The PARALLEL_DEGREE_POLICY parameter controls how the DoP is chosen –MANUAL•The default•Uses manual DoP rules–AUTO, which enables•Auto DoP•In Memory Parallel Execution•Parallel Statement Queuing–ADAPTIVE•The same as AUTO but also enables performance feedback to determine the DoP•New in 12c–LIMITED•Just enables Auto DoP–Only used when the table parallel decoration is set to DEFAULTParallel ExecutionManual DoP•The DoP is calculated based on table or system settings–Uses the parallel decoration on the table–If the table parallel decoration is set to “default” it uses the formulaCPU_COUNT * PARALLEL_THREADS_PER_CPU * # of instances •Manual DoP–Facilitates using a consistent DoP across users, schemas, queries and tables if tables have the same settings–Also allows for inconsistent DoPs if tables and/or instances have different settingsParallel ExecutionAuto DoP•First determines if the SQL statement will run serial or parallel–Uses the PARALLEL_MIN_TIME_THRESHOLD parameter–Defaults to 10 seconds–Defaults to 1 second for DBIM–Needed for DBIM on RAC•Automatically calculates the most “efficient” DoP for a SQL statement –Does not take system workload into account–The DoP calculation is based primarily on expected IO prior to 12c •Ignores the table parallel decorationResource Management with Parallel ExecutionParallel ExecutionWays to limit the DoP•Resource Manager–The Max DoP setting limits the DoP for a consumer group •PARALLEL_DEGREE_LIMIT–This parameter limits the DoP when using Auto DoPParallel ExecutionWays to control system resources with parallel execution•parallel_adaptive_multi_user–Reduces DoP based on system load–Usually reduces DoP too much—recommend setting to FALSE•Parallel statement queuing–Creates a FIFO queue for parallel statements–Make SQL statements wait for px resources to become available before execution starts instead of allowing SQL statements to run with insufficient px resources–When all of the parallel server processes in the pool are in use, statements queueParallel ExecutionThe Basics•Parallel execution is used to reduce the execution time of queries–Multiple processes work together to use more resources on the system, such as CPU and IO•A simple configuration should be used to determine the DoP–Coordinate parallel parameters–Avoid using hints and alter session•A resource management policy is needed when using parallel execution–To keep the system under control–To ensure SQL statements are able to execute in parallelPX Workload with No Resource Management•Available PX processes defined bythe following parameters which aredefined per instance–parallel_min_servers=32–parallel_max_servers=64•By default, PX servers will beallocated for parallel SQL and if allPX servers are busy subsequent SQLexecutions will be downgradedPX Workload with No Resource ManagementQuery Status RequestedDoPPXAllocatedExecutionDoPPX Workload with No Resource ManagementQuery Status RequestedDoPPXAllocatedExecutionDoPA Running8168PX Workload with No Resource ManagementQuery Status RequestedDoPPXAllocatedExecutionDoPA Running8168B Running122412PX Workload with No Resource ManagementQuery Status RequestedDoPPXAllocatedExecutionDoPA Running8168B Running122412C Running8168PX Workload with No Resource ManagementQuery Status RequestedDoPPXAllocatedExecutionDoPA Running8168B Running122412C Running8168D Running1284PX Workload with No Resource ManagementQuery Status RequestedDoPPXAllocatedExecutionDoPA Running8168B Running122412C Running8168D Running1284E Running3201PX Workload with Resource Management•parallel_min_servers andparallel_max_servers stilldefine the number of px serversavailable for execution•parallel_servers_targetdefines the pool of px serversavailable for SQL statements in thequeuePX Workload with Parallel Statement QueuingQuery Status RequestedDoPPXAllocatedExecutionDoPA8PX Workload with Parallel Statement QueuingQuery Status RequestedDoPPXAllocatedExecutionDoPA Running8168PX Workload with Parallel Statement QueuingQuery Status RequestedDoPPXAllocatedExecutionDoPA Running8168B Running122412PX Workload with Parallel Statement QueuingQuery Status RequestedDoPPXAllocatedExecutionDoPA Running8168B Running122412C Running8168PX Workload with Parallel Statement QueuingQuery Status RequestedDoPPXAllocatedExecutionDoPA Running8168B Running122412C Running8168D Queued12PX Workload with Parallel Statement QueuingQuery Status RequestedDoPPXAllocatedExecutionDoPA Finished8168B Running122412C Running8168D Queued12PX Workload with Parallel Statement QueuingQuery Status RequestedDoPPXAllocatedExecutionDoPA Finished8168B Running122412C Running8168D Running122412PX Workload with Parallel Statement QueuingQuery Status RequestedDoPPXAllocatedExecutionDoPA Finished8168B Running122412C Running8168D Running122412E Queued32PX Workload with Parallel Statement QueuingQuery Status RequestedDoPPXAllocatedExecutionDoPA Finished8168B Finished122412C Finished8168D Finished122412E Queued32PX Workload with Parallel Statement QueuingQuery Status RequestedDoPPXAllocatedExecutionDoPA Finished8168B Finished122412C Finished8168D Finished122412E Running326432Parallel ExecutionParallel Statement Queuing•Parallel Statement Queuing–Can be enabled separately by setting _parallel_statement_queuing=true –Can be used with Resource Manager to create multiple queues for different consumer groups–Set PARALLEL_SERVERS_TARGET based on CPU resources on the systemParallel ExecutionRecommendations•Implement a simple setup to understand what is happening in the system •Base your plan/strategy on the amount of system resources you want to make available for parallel execution•Use resource manager to specify the max DoP for consumer groups •Set tables to the highest DoP that can be used in the resource manager plan。
ORACLE数据库变得非常慢解决方案一例
ORACLE数据库变得非常慢解决方案一例最近在为一个项目做数据库优化,发现ORACLE数据库运行得特别慢,简直让人头大。
今天就来给大家分享一下我是如何一步步解决这个问题的,希望对你们有所帮助。
事情是这样的,那天老板突然过来,一脸焦虑地说:“小王,你看看这个数据库,查询速度怎么这么慢?客户都投诉了!”我二话不说,立刻开始分析原因。
我打开了数据库的监控工具,发现CPU和内存的使用率都很高,看来是数据库的压力确实很大。
然后,我开始查看慢查询日志,发现了很多执行时间很长的SQL语句。
这时,我意识到,问题的根源可能就在这些SQL语句上。
一、分析SQL语句1.对执行时间长的SQL语句进行优化。
我检查了这些SQL语句的写法,发现很多地方可以优化。
比如,有些地方使用了子查询,我尝试将其改为连接查询,以提高查询效率。
2.检查索引。
我发现有些表上没有合适的索引,导致查询速度变慢。
于是,我添加了合适的索引,以提高查询速度。
3.调整SQL语句的顺序。
有些SQL语句的执行顺序不当,导致查询速度变慢。
我调整了这些语句的顺序,使其更加合理。
二、调整数据库参数1.增加缓存。
我发现数据库的缓存设置比较低,导致查询时需要频繁读取磁盘。
我适当增加了缓存大小,以提高查询速度。
2.调整线程数。
我发现数据库的线程数设置较低,无法充分利用CPU资源。
我将线程数调整为合适的值,以提高数据库的处理能力。
3.优化数据库配置。
我对数据库的配置文件进行了调整,比如调整了日志文件的存储路径和大小,以及调整了数据库的备份策略等。
三、检查硬件资源1.检查CPU。
我查看了CPU的使用情况,发现CPU负载较高。
我建议公司采购更强大的CPU,以提高数据库的处理能力。
2.检查内存。
我发现内存的使用率也很高,于是建议公司增加内存容量。
3.检查磁盘。
我检查了磁盘的读写速度,发现磁盘的I/O性能较低。
我建议公司更换更快的磁盘,以提高数据库的读写速度。
四、定期维护1.定期清理数据库。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
一基本概念1实例和数据库(1)什么是实例:数据库启动以后,各个进程调入到内存中,各个进程之间的相互协调构成了实例(2)什么是数据库:各个数据文件的集合: 10.0\oradata\%sid%\目下有各种文件(CTL(控制文件),LOG(日志文件),DBF(数据文件))(3)数据库的物理结构系统的初始化参数:存放的位置为% oracle_home%\product\10.0\Db_1\database\initorcl.ora 数据库日志文件:分为联机日志文件(重做日志文件(redo日志文件):不停的覆盖)和归档日志文件(在数据库热备份的时候使用);联机日志文件写完以后,依次往下写,全部写满,重新覆盖原来的,此时就是非归档形式。
控制文件:控制日志文件和数据文件。
数据库启动的时候,首先启动控制文件,然后由控制文件打开数据文件,对应数据中的形式就是:database mount ,然后是database open。
查看数据库得文件:数据库的连接:sqlplus system/bjsxt as sysdba对应的控制文件从v$controlfile视图中查看。
desc v$controlfile (查看描述)select status ,controlfile from v$controlfile。
(查看内容)对应的数据文件从v$datafile视图中查看。
desc v$datafileselect status, name from v$datafile对应的日志文件从v$logfile视图中查看。
desc v$logfileselect member from v$logfile2内存结构(1)SGA(系统全局区)的各个缓冲区SGA被实例的所有进程所共享,包含高速缓存区(DB Buffer)、大的共享区、共享池、日志缓冲区、固定的SGA。
DB 高速缓冲区:使用系统内存,加快数据库访问数据文件中的数据。
共享池:缓冲执行的SQL语句、程序块、执行计划、常用的数据字典。
Redo buffer:日志文件缓冲区。
大共享区:提供了一个可选的内存块区,当需要备份或者执行大的SQL语句时可能需要它。
固定SGA:完全由oracle内部控制。
查看SGA的使用情况:SELECT NAME, BYTES FROM SYS.V_$SGASTAT ORDER BY NAME ASC3逻辑结构(1)表空间(2)段(3)盘区(4)数据块查看数据文件的信息:desc dba_data_files;select substr(file_name,1,50),tablespace_name,blocks from dba_data_files;查看表空间信息:desc dba_tablespaces;查看段信息:desc dba_segments查看盘区信息:desc dba_extents;二调优工具介绍1SQL_TRACE(1)SQL_TRACE说明:注意:从oracle 10g开始,SQL_TRACE成为了动态参数SQL_TRACE为true,表示运行,会对整个实例产生严重的性能影响,所以在产品环境下,如非必要,一定不要设置这个参数。
如果必须在系统下启动SQL_TRACE,必须保证以下条件对系统性能影响最小:保证25%的cpu idle为user_dump_dest分配足够的空间。
(2)在使用SQL_TRACE之前,几个注意事项需要说明一下: 初始化参数TIMED_STATISTICS参数TIMED_STATISTICS最好设置为true,否则一些重要信息将无法收集设MAX_DUMP_FILE_SIZE在9i中默认为unlimited,表示可以任意大小Alter session set MAX_DUMP_FILE_SIZE=unlimited(3)SQL_TRACE可以通过初始化参数来设置,也可以通过alter system (从10g开始)在全局中设置,也可以在具体的session中设置在参数文件中设置(pfile/spfile)指定:Sql_trace=true;在oracle 10g动态全局指定Alter system set sql_trace=true;在当前session中指定Alter session set sql_trace =true;2使用tkprof工具来查询sql性能工具SQL trace工具集收集正在执行的sql的性能状态数据,并将数据记录到一个跟踪文件中,这个跟踪文件提供很多有用的信息,如cpu时间,总消耗时间,读取磁盘数量,查询中返回的记录数目等。
使用命令查看一下tkprof的帮助fkprof 然后回车在这些参数比较有用的是:fchela (按照elapsed time fetching来对分析的结果排序)sys这个参数设置为no可以阻止所有以sys用户执行的sql被显示出来使用步骤:⏹在数据库上设置TIMED_STATISTICS为TRUE(在9i上默认为true,可以使用命令:show parameter timed_statistics查看);Alter system set timed_statistics=true;⏹启动当前会话的sql_trace:alter session set sql_trace=true;(停止当前会话的sql_trace: alter session set sql_trace=false;)⏹跟踪文件的存放位置由初始化参数user_dump_dest控制,(可以用命令show parameter user_dump_dest来查看).可能通过修改时间来找到最新生成的跟踪文件。
生成的跟踪文件扩展名为.trc.是二进制文件。
找到了对应的跟踪文件orcl_ora_3888.trc.⏹对trace文件使用tkprof工具进行分析Tkprof tracefile outfile [options]例子:tkprof orcl_ora_3576.trc report.txt sort=fchcpu sys=no;Tfprof文件参数解析:⏹CALL:每次SQL语句的处理都分成三个部分(Parse,Execute,Fetch)⏹Parse:这步将SQL语句转换成执行计划,包括检查是否有正确的授权和所需要用到的表、列以及其他引用到的对象是否存在。
⏹Execute:这步是真正的由Oracle来执行语句。
对于insert、update、delete操作,这步会修改数据,对于select操作,这步就只是确定选择的记录。
⏹Fetch:返回查询语句中所获得的记录,这步只有select语句会被执行。
⏹COUNT: 这个语句被parse、execute、fetch的次数。
⏹CPU:这个语句对于所有的parse、execute、fetch所消耗的cpu的时间,以秒为单位。
⏹ELAPSED:这个语句所有消耗在parse、execute、fetch的总的时间。
⏹DISK:从磁盘上的数据文件中物理读取的块的数量。
一般来说更想知道的是正在从缓存中读取的数据而不是从磁盘上读取的数据。
⏹QUERY:在一致性读模式下,所有parse、execute、fetch所获得的buffer的数量。
一致性模式的buffer是用于给一个长时间运行的事务提供一个一致性读的快照,缓存实际上在头部存储了状态。
⏹CURRENT:在current模式下所获得的buffer的数量。
一般在current模式下执行insert、update、delete操作都会获取buffer。
在current模式下如果在高速缓存区发现有新的缓存足够给当前的事务使用,则这些buffer都会被读入了缓存区中。
⏹ROWS: 所有SQL语句返回的记录数目,但是不包括子查询中返回的记录数目。
对于select语句,返回记录是在fetch这步,对于insert、update、delete操作,返回记录则是在execute这步。
问题判断:⏹elapsed/cpu 太大表示执行过程中花费了大量的时间等待某种资源⏹cpu OR elapsed 太大表示执行时间过长,或消耗了大量的CPU时间,应该考虑优化3在pl/slq中使用set timing on与使用sql_trace的区别三调优方式:(SQL)1在数据量比较大表上建立相关的索引Create index abc_b_index on abc(b);2Where 子句的连接顺序⏹ORACLE采用自上而下的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前,那些可以过滤最大数据记录的条件必须写在WHERE子句的末尾。
select empno,ename,job,sal from emp wherejob='PRESIDENT' and sal>1000select empno,ename,job,sal from emp where sal>1000and job='PRESIDENT'注:(select count(*) from emp where sal>1000:(查询的数目为15068))(select count(*) from emp where job='PRESIDENT'; 查询的数目为1952)3Select 子句中避免使用’*’;如果在select子句中查询所有的字段,使用*是比较方便的,但是效率比较低,原因在于ORACLE在解析* 的时候,要将* 依次转化为字段名称,这个转化过程是通过查询数据字典完成的。
4减少访问数据库的次数当执行每条sql语句时,ORACLE在内部执行很多工作:解析SQL,估算索引的利用率,绑定变量,读数据块等。
查询编号为34的员工的姓名,工作,工资;再查询一下编号为35的员工(低效)select ename,job,sal from emp where empno=34;select ename,job,sal from emp where empno=35;在一个sql直接实现查询编号为34和35的员工信息(高效)select ename,job,sal from emp where empno=34 or empno=355使用DECODE函数来减少处理时间(1)DECODE使用说明:decode(条件,值1,翻译值1,值2,翻译值2,...值n,翻译值n,缺省值)该函数的含义如下:IF 条件=值1 THENRETURN(翻译值1)ELSIF 条件=值2 THENRETURN(翻译值2)......ELSIF 条件=值n THENRETURN(翻译值n)ELSERETURN(缺省值)END IF(2)使DECODE可以避免重复扫描相同记录或者重复连接相同的表select count(*),sum(sal) from emp where ename='SMITH' and deptno=20;select count(*),sum(sal) from emp where ename='SMITH' and deptno=10select count(decode(deptno,10,'X',NULL)) D10_COUNT, count(decode(deptno,20,'X',NULL)) D20_COUNT,sum(decode(deptno,10,sal,NULL)) D10_sum,sum(decode(deptno,20,sal,NULL)) D20_sumfrom emp where ename = 'SMITH'6删除重复记录Oracle中,每一条记录都有一个rowid,rowid在整个数据库中是唯一的,rowid确定了每条记录是在ORACLE中的哪一个数据文件、块、行上。