MYSQL网页编程之Oracle Tuning的一些总结
任何规模的组织都可能受益于外包服务，并在一个标准化和优化的平台上统一其数据库管理任务。基于其本身的特性，DBaaS提供了敏捷和高效的数据库服务，它可以支持多变的需求。oracle关于Oracle的功能调剂，一样平常包含两个方面，一是指Oracle数据库自己的调剂，好比SGA、PGA的优化设置，二是毗连Oracle的使用程序和SQL语句的优化。做好这两个方面的优化，就能够使一套完全的Oracle使用体系处于优秀的运转形态。本文次要是把一些OracleTuning的文章作了一个复杂的总结，力图以实践可操纵为目标，共同解说部分实际常识，使年夜部分具有一样平常Oracle常识的利用者可以对OracleTuning有所懂得，而且可以依据实践情形对某些参数举行调剂。关于加倍具体的常识，请拜见本文停止部分所说起的保举书本，同时因为该话题内容太多且庞大，本文一定有掉之公允乃至毛病的中央，请不惜见教，并配合前进。
1.SGA的设置
在OracleTuning中，对SGA的设置是关头。SGA，是指SharedGlobalArea,大概是SystemGlobalArea,称为共享全局区大概体系全局区，布局以下图所示。
关于SGA地区内的内存来讲，是共享的、全局的，在UNIX上，必需为oracle设置共享内存段（能够是一个大概多个），由于oracle在UNIX上是多历程；而在WINDOWS上oracle是单历程（多个线程），以是不必设置共享内存段。
1.1SGA的各个构成部分
上面用sqlplus查询举例看一下SGA各个构成部分的情形：
SQL>select*fromv$sga;
NAMEVALUE
------------------------------
FixedSize104936
VariableSize823164928
DatabaseBuffers1073741824
RedoBuffers172032
大概
SQL>showsga
TotalSystemGlobalArea1897183720bytes
FixedSize104936bytes
VariableSize823164928bytes
DatabaseBuffers1073741824bytes
RedoBuffers172032bytes
FixedSize
oracle的分歧平台和分歧版本下大概纷歧样，但关于断定情况是一个流动的值，内里存储了SGA各部分组件的信息，能够看做引诱创建SGA的地区。
VariableSize
包括了shared_pool_size、java_pool_size、large_pool_size等外存设置
DatabaseBuffers
指数据缓冲区，在8i中包括db_block_buffer*db_block_size、buffer_pool_keep、buffer_pool_recycle三部份内存。在9i中包括db_cache_size、db_keep_cache_size、db_recycle_cache_size、db_nk_cache_size。
RedoBuffers
指日记缓冲区，log_buffer。在这里要分外申明一点的是，关于v$parameter、v$sgastat、v$sga查询值大概纷歧样。v$parameter内里的值，是指用户在初始化参数文件内里设置的值，v$sgastat是oracle实践分派的日记缓冲区巨细（由于缓冲区的分派值实践上是团圆的，也不是以block为最小单元举行分派的），v$sga内里查询的值，是在oracle分派了日记缓冲区后，为了回护日记缓冲区，设置了一些回护页，一般我们会发明回护页巨细是8k(分歧情况大概纷歧样)。参考以下内容
SQL>selectsubstr(name,1,10)name,substr(value,1,10)value
2fromv$parameterwherename=log_buffer;
NAMEVALUE
----------------------------------------
log_buffer163840
SQL>select*fromv$sgastatwherepoolisnull;
POOLNAMEBYTES
-----------------------------------------------
fixed_sga104936
db_block_buffers1073741824
log_buffer163840
SQL>select*fromv$sga;
NAMEVALUE
------------------------------
FixedSize104936
VariableSize823164928
DatabaseBuffers1073741824
RedoBuffers172032
172032C163840=8192
（以上实验数据是在HPB.11.11+Oracle8.1.7.4情况下失掉的）
<FONTface=Verdana>
1.2SGA的巨细设置
在对SGA的布局举行复杂剖析今后，上面是关于怎样依据体系的情形准确设置SGA巨细的成绩。
SGA是一块内存地区，占用的是体系物理内存，因而关于一个Oracle使用体系来讲，SGA决不是越年夜越好，这就必要寻觅一个体系优化的均衡点。
1.2.1设置参数前的筹办
在设置SGA的内存参数之前，我们起首要问本人几个成绩
一：物理内存多年夜
二：操纵体系估量必要利用几内存
三：数据库是利用文件体系仍是裸设备
四：有几并发毗连
五：使用是OLTP范例仍是OLAP范例
依据这几个成绩的谜底，我们能够大略地为体系估量一下内存设置。那我们如今来逐一成绩地会商，起首物理内存多年夜是最简单回覆的一个成绩，然后操纵体系估量利用几内存呢？从履历上看，不会太多，一般应当在200M之内（不包括大批历程PCB）。
接上去我们要切磋一个主要的成绩，那就是关于文件体系和裸设备的成绩，这常常简单被我们所疏忽。操纵体系关于文件体系，利用了大批的buffer来缓存操纵体系块。如许当数据库猎取数据块的时分，固然SGA中没有射中，但却实践上多是从操纵体系的文件缓存中猎取的。而假设数据库和操纵体系撑持异步IO，则实践受骗数据库写历程DBWR写磁盘时，操纵体系在文件缓存中标志该块为提早写，比及真正地写进磁盘以后，操纵体系才关照DBWR写磁盘完成。关于这部分文件缓存，所必要的内存大概对照年夜，作为守旧的估量，我们应当思索在0.2――0.3倍内存巨细。可是假如我们利用的是裸设备，则不思索这部分缓存的成绩。如许的情形下SGA就有调年夜的时机。
关于数据库有几并发毗连，这实践上干系到PGA的巨细（MTS下另有large_pool_size）。现实上这个成绩应当说还跟OLTP范例大概OLAP范例相干。关于OLTP范例oracle偏向于可以使用MTS,关于OLAP范例利用自力形式，同时OLAP还大概触及到大批的排序操纵的查询，这些都影响到我们内存的利用。那末一切的成绩综合起来，实践上次要反应在UGA的巨细上。UGA次要包括以下部份内存设置
SQL>showparametersarea_size
NAMETYPEVALUE
---------------------------------------------------
bitmap_merge_area_sizeinteger1048576
create_bitmap_area_sizeinteger8388608
hash_area_sizeinteger131072
sort_area_sizeinteger65536
SQL>
在这部份内存中我们最存眷的一般是sort_area_size，这是当查询必要排序的时分，数据库会话将利用这部份内存举行排序，当内存巨细不敷的时分，利用一时表空间举行磁盘排序。因为磁盘排序效力和内存排序效力相差好几个数目级，以是这个参数的设置很主要。
当呈现大批排序时的磁盘I/O操纵时，能够思索增添sort_area_size的值。sort_area_size是Oracle用于一次排序所需的最年夜内存数，在排序停止可是了局列前往之前，Oracle会开释sort_area_size巨细的内存，可是会保存sort_area_retained_size巨细的内存，晓得最初一行了局列前往今后，才开释一切的内存。
会招致排序的语句有SELECTDISTINCT,MINUS,INTERSECT,UNION和min()、max()、count()操纵；而不会招致排序的语句有UPDATE,带BETWEEN子句的SELECT等等。
这四个参数都是针对会话举行设置的，是单个会话利用的内存的巨细，而不是全部数据库利用的。偶然会瞥见有人曲解了这个参数觉得是全部数据库利用的巨细，这是极为严峻的毛病。假设设置了MTS，则UGA被分派在large_pool_size，也就是说放在了共享内存内里，分歧历程（线程）之间能够共享这部份内存。在这个基本上，我们假定数据库存在并发实行serverprocess为100个，依据下面我们4个参数在oracle8.1.7下的默许值，我们来盘算自力形式下PGA的大抵巨细。因为会话其实不会常常利用create_bitmap_area_size、bitmap_merge_area_size，以是我们一般不合错误四个参数乞降。在思索到除这四个参数外会话所保留的变量、仓库等信息，我们估量为2M，则200个历程最年夜大概利用200M的PGA。
1.2.2一个履历公式
如今，依据下面这些假定，我们来看SGA实践能到达几内存。在1G的内存的服务器上，我们能分派给SGA的内存约莫为400―500M。如果2G的内存，约莫能够分到1G的内存给SGA，8G的内存能够分到5G的内存给SGA。固然我们这里是以默许的排序部份内存sort_area_size=64k举行权衡的，假设我们必要调年夜该参数和hash_area_size等参数，然后我们应当依据并发的历程的数目，来权衡思索这个成绩。
现实上，一般我们更习气经由过程直不雅的公式化来表达如许的成绩：
OS利用内存+SGA+并发实行历程数*(sort_area_size+hash_ara_size+2M)<0.7*总内存
(公式是逝世的，体系是活的，实践使用的调剂不用框公式，这不外是一个参考倡议)
在我们的实践使用中，假设接纳的是裸设备，我们可得当的增年夜SGA(假如必要的话)。因为今朝几近一切的操纵体系都利用假造缓存，以是实践上假如就算SGA设置的对照年夜也不会招致毛病，而是大概呈现频仍的内存页的换进与换出(pagein/out)。在操纵体系一级假如察看到这个征象，那末我们就必要调剂内存的设置。
1.2.3各个参数的设置
那末SGA中的各个参数详细应当依照甚么样的准绳来设置呢，上面举行会商：
log_buffer
关于日记缓冲区的巨细设置，一般我以为没有过量的倡议，由于参考LGWR写的触发前提以后，我们会发明一般凌驾3M意义不是很年夜。作为一个正式体系，大概思索先设置这部分为log_buffer=1―3M巨细，然后针对详细情形再调剂。
large_pool_size
关于年夜缓冲池的设置，假设不利用MTS，倡议在20―30M充足了。这部分次要用来保留并行查询时分的一些信息，另有就是RMAN在备份的时分大概会利用到。假如设置了MTS，则因为UGA部分要移进这里，则必要详细依据session最年夜数目和sort_ares_size等相干会话内存参数的设置来综合思索这部分巨细的设置，一样平常能够思索为session*(sort_area_size+2M)。这里要提示一点，不是必需利用MTS，我们都不主意利用MTS，特别同时在线用户数小于500的情形下。。
java_pool_size
假设数据库没有利用JAVA，我们一般以为保存10―20M巨细充足了。现实上能够更少，乃至起码只必要32k，但详细跟安装数据库的时分的组件相干(好比httpserver)。
shared_pool_size
这是迄今为止最具有争议的一部份内存设置。依照良多文档的形貌，这部份内容应当几近和数据缓冲区差未几巨细。但实践下情况却不是如许的。起首我们要精细精美一个成绩，那就是这部份内存的感化，它是为了缓存已被剖析过的SQL，而使其能被重用，不再剖析。如许做的缘故原由是由于，关于一个新的SQL（shared_pool内里不存在已剖析的可用的不异的SQL），数据库将实行硬剖析，这是一个很损耗资本的历程。而若已存在，则举行的仅仅是软剖析（在共享池中寻觅不异SQL），如许损耗的资本年夜年夜削减。以是我们希冀能多共享一些SQL，而且假如该参数设置不敷年夜，常常会呈现ora-04031毛病，暗示为懂得析新的SQL，没有可用的充足年夜的一连余暇空间，如许天然我们希冀该参数能年夜一些。可是该参数的增年夜，却也有负面的影响，由于必要保护共享的布局，内存的增年夜也会使得SQL的老化的价值更高，带来大批的办理的开支，一切这些大概会招致CPU的严峻成绩。
在一个充实利用绑定变量的对照年夜的体系中，shared_pool_size的开支一般应当保持在300M之内。除非体系利用了大批的存储历程、函数、包，好比oracleerp如许的使用，大概会到达500M乃至更高。因而我们假定一个1G内存的体系，大概思索设置该参数为100M，2G的体系思索设置为150M,8G的体系能够思索设置为200―300M。
关于一个没有充实利用大概没有利用绑定变量体系，这大概给我们带来一个严峻的成绩。所谓没有利用bindvar的SQL，我们称为LiteralSQL。也就是好比如许的两句SQL我们以为是分歧的SQL,必要举行2次硬剖析：
select*fromEMPwherename=‘TOM’;
select*fromEMPwherename=‘JERRY’;
假设把’TOM’和’JERRY’换做变量V，那就是利用了bindvar，我们能够以为是一样的SQL从而能很好地共享。共享SQL原本就是shared_pool_size这部份内存存在的本意，oracle的目标也在于此，而我们不利用bindvar就是违反了oracle的初志，如许将给我们的体系带来严峻的成绩。固然，假如经由过程在操纵体系监控，没有发明严峻的cpu成绩，我们假如发明该共享池射中率不高能够得当的增添shred_pool_size。可是一般我们不主意这部份内存凌驾800M（特别情形下能够更年夜）。
现实上，大概的话我们乃至要想举措制止软剖析，这在分歧的程序言语中完成体例有差别。我们也大概经由过程设置session_cached_cursors参数来取得匡助（这将增年夜PGA）
关于利用绑定变量的话题，鄙人面的使用优化中持续会商。
Databuffer
如今我们来谈数据缓冲区，在断定了SGA的巨细并分派完了后面部分的内存后，其他的，都分派给这部份内存。一般，在同意的情形下，我们都实验使得这部份内存更年夜。这部份内存的感化次要是缓存DBBLOCK，削减乃至制止从磁盘上猎取数据，在8i中一般是由db_block_buffers*db_block_size来决意巨细的。假如我们设置了buffer_pool_keep和buffer_pool_recycle，则应当加上前面这两部份内存的巨细。
能够看出，设置SGA时基础上应当把握的准绳是：
databuffer一样平常能够尽量的年夜
shared_pool_size应当过度
logbuffer在1MB之内就能够了
假定oracle是32bit,服务器RAM年夜于2G，注重你的PGA的情形，,则倡议
shared_pool_size+databuffer+large_pool_size+java_pool_size<1.6G
再详细化，假如512MRAM
倡议shared_pool_size=50M,databuffer=200M
假如1GRAM
shared_pool_size=100M,databuffer=500M
假如2GRAM
shared_pool_size=150M,databuffer=1.2G
物理内存再年夜已跟参数没有干系了
假定64bitORACLE
内存4G
shared_pool_size=200M,databuffer=2.5G
内存8G
shared_pool_size=300M,databuffer=5G
内存12G
shared_pool_size=300M-----800M,databuffer=8G
1.332bit与64bit对SGA的影响
为何在下面SGA巨细设置的履历划定规矩中要分32bitOracle和64bitOracle呢，是由于这干系到SGA巨细的下限成绩。在32bit的数据库下，一般oracle只能利用不凌驾1.7G的内存，即便我们具有12G的内存，可是我们却只能利用1.7G，这是一个莫年夜的遗憾。假设我们安装64bit的数据库,我们就能够利用很年夜的内存，几近不成能到达下限。可是64bit的数据库必需安装在64bit的操纵体系上，惋惜今朝windows上只能安装32bit的数据库，我们经由过程上面的体例能够检察数据库是32bit仍是64bit：
SQL>select*fromv$version;
BANNER
----------------------------------------------------------------
Oracle8iEnterpriseEditionRelease8.1.7.0.0-Production
PL/SQLRelease8.1.7.0.0-Production
CORE8.1.7.0.0Production
TNSfor32-bitWindows:Version8.1.7.0.0-Production
NLSRTLVersion3.4.1.0.0CProduction
在UNIX平台下的显现有所分歧，分明能够看出是64bitOracle，好比在HP-UX平台上：
SQL>select*fromv$version;
BANNER
----------------------------------------------------------------
Oracle8iEnterpriseEditionRelease8.1.7.4.0-64bitProduction
PL/SQLRelease8.1.7.4.0-Production
CORE8.1.7.0.0Production
TNSforHPUX:Version8.1.7.4.0-Production
NLSRTLVersion3.4.1.0.0CProduction
32bit的oracle不管跑在32bit大概64bit的平台都有SGA的限定的，而关于32bit的平台只能跑32bit的oracle，可是在特定的操纵体系下，大概供应了必定的手腕，使得我们可使用凌驾1.7G的内存，到达2G以上乃至更多。因为我们如今一样平常都利用64bitOracle，因而关于怎样在32bit平台上扩大SGA巨细的成绩不再赘述。
1.49i中相干参数的变更
oracle的版本的更新，老是陪伴着参数的变更，而且愈来愈趋势于使得参数的设置更复杂，由于庞大的参数设置使得DBA们常常焦头烂额。关于内存这部分的变更，我们能够考查上面的参数。现实上在9i中数据库自己能够给出一组合适以后运转体系的SGA相干部分的参数调剂值（参考V$DB_CACHE_ADVICE、V$SHARED_POOL_ADVICE），关于PGA也有相干视图V$PGA_TARGET_ADVICE等。
Databuffer
9i中保存了8i中的参数，如设置了新的参数，则疏忽旧的参数。9i顶用db_cache_size来代替db_block_buffers，用db_keep_cache_size代替buffer_pool_keep,用db_recycle_cache_size代替buffer_pool_recycle；这里要注重9i中设置的是实践的缓存巨细而不再是块的数目。别的9i新增添了db_nk_cache_size，这是为了撑持在统一个数据库中利用分歧的块巨细而设置的。关于分歧的表空间，能够界说分歧的数据块的巨细，而缓冲区的界说则依托该参数的撑持。个中n能够为2、4、6、8、16等分歧的值。在这里特地说起的一个参数就是db_block_lru_latches，该参数在9i中已成了保存参数，不保举手工设置。
PGA
在9i内里这部分也有了很年夜的变更。在自力形式下，9i已不再主意利用本来的UGA相干的参数设置，而代之以新的参数。假设workarea_size_policy=AUTO（缺省），则一切的会话的UGA共用一年夜块内存，该内存由pga_aggregate_target设置。在我们依据后面先容的办法评价了一切历程大概利用的最年夜PGA内存以后，我们能够经由过程在初始化参数中设置这个参数，从而不再体贴其他”*_area_size”参数。
SGA_MAX_SIZE
在9i中若设置了SGA_MAX_SIZE，则在总和小于即是这个值内，能够静态的调剂数据缓冲区和共享池的巨细
SQL>showparameterssga_max_size
NAMETYPEVALUE
--------------------------------------------------------
sga_max_sizeunknown193752940
SQL>
SQL>altersystemsetdb_cache_size=30000000;
Systemaltered.
SQL>altersystemsetshared_pool_size=20480000;
Systemaltered.
1.5lock_sga=true的成绩
因为几近一切的操纵体系都撑持假造内存，以是即便我们利用的内存小于物理内存，也不克不及制止操纵体系将SGA换到假造内存（SWAP）。以是我们能够实验使得SGA锁定在物理内存中不被换到假造内存中，如许削减页面的换进和换出，从而进步功能。但在这里遗憾的是，windows是没法制止这类情形的。上面我们来参考在分歧的几个体系下怎样完成lock_sga
AIX5L（AIX4.3.3以上）
logonaixasroot
cd/usr/samples/kernel
./vmtune(信息以下)v_pingshm已是1
./vmtune-S1
然后oracle用户修正initSID.ora中lock_sga=true
从头启动数据库
HPUNIX
Root身份上岸
Createthefile"/etc/privgroup":vi/etc/privgroup
Addline"dbaMLOCK"tofile
Asroot,runthecommand"/etc/setprivgrp-f/etc/privgroup":
$/etc/setprivgrp-f/etc/privgroup
oracle用户修正initSID.ora中lock_sga=true
从头启动数据库
SOLARIS(solaris2.6以上)
8i版本以上数据库默许利用埋没参数use_ism=true，主动锁定SGA于内存中,不必设置lock_sga,假如设置lock_sga=true利用非root用户启动数据库将前往毛病。
WINDOWS
不克不及设置lock_sga=true,能够经由过程设置pre_page_sga=true,使得数据库启动的时分就把一切内存页装载，如许大概起到必定的感化。
2.使用优化
上面我们从手艺的角度动手，来切磋数据库优化方面的成绩。一般作为优化Oracle体系的人，大概是DBA，实在良多时分对使用其实不很懂得乃至能够说是完整不懂得，更不要说对使用程序代码的懂得。现实上呢，一个体系运转的快大概慢信任人人都分明，第一主要的是数据库的计划，然后是使用的计划，SQL语句的编写，最初才是数据库参数的调剂和硬件、收集的成绩，等等。以是在我们不懂得一个体系的时分来优化数据库使用不是一个轻松的简单的事变。那末我们第一步应当怎样做呢？
一般有两类办法：
个中一个办法就是我们经常使用的，利用statspack来举行诊断体系的瓶颈地点。在statspack中oracle给出了几近涵盖oracle年夜部分主要内容的信息。
别的一种体例，就是tracesession。假设某个session运转很慢大概某个用户的某个查询很慢，那末这个时分我们能够经由过程tracesession的体例来诊断究竟是慢在那里，看事实实行企图是如何的，然后在user_dump_dest下依据该session的历程号大概线程号能够找到一个发生的trace文件。经由过程利用tkprof格局化文件以后我们就能够瞥见良多的统计信息，这里包含了实行企图、parse/fetch等步骤损耗cpu的工夫。一般我们是察看query形式下的consistentgets来起首看sql是不是利用了索引，然后看实行企图是否是一般，是否是有调剂的余地。固然假如您没有实践做过的话，这些内容提及来很笼统。这是在不懂得使用和程序下针对特定session的诊断和调剂历程。
tracesession的体例是一种自下而上的办法，从sql动手；而statspack是自顶向下的办法，也就是从微观上先诊断数据库的瓶颈在那里，然后从瓶颈动手来做调剂，这个习气上又能够称为经由过程守候事务（waitevent）动手的办法。
2.1利用statspack
statspack是一本性能诊断工具，起首公布于Oracle8.1.6版本，在8.1.7版本中功效失掉增强。Statspack除查找实例中的功能成绩外，还能够查找使用程序中高负荷的SQL语句，很简单断定Oracle数据库的瓶颈地点，而且纪录数据库功能形态。
在数据库中Statspack的剧本位于$ORACLE_HOME/RDBMS/ADMIN目次下，关于ORACLE8.1.6,是一组以stat开首的文件；关于ORACLE8.1.7,是一组以sp开首的文件。
在Statspack公布之前，我们一般可以利用诊断数据库的工具是两个剧本UTLBSTAT.SQL和UTLESTAT.SQL，BSTAT/ESTAT是一个十分复杂的功能诊断工具。UTLBSTAT取得入手下手时良多V$视图的快照，UTLESTAT经由过程先前的快照和以后视图天生一个报表。
该报表实践上相称于statspack中的两个采样点。
Statspack经由过程一连的采样，可以给我们供应相当主要的趋向剖析数据。这是一个伟大的前进。可以利用Statspack的情况我们就只管不要利用BSTAT/ESTAT的体例来诊断数据库成绩。
2.1.1安装statapack
§步骤一：
为了可以顺遂安装和运转Statspack，起首必要设置以下两个体系参数：
1.job_queue_processes
为了可以创建主动义务，实行数据搜集，该参数必要年夜于0。你能够在初试化参数文件中修正该参数(使该参数在重起后以然无效)。
该参数能够在体系级静态修正(重起后生效)。
SQL>altersystemsetjob_queue_processes=6;
Systemaltered
在Oracle9i傍边，能够指定局限，如both,如许该修正在以后及以后坚持无效(仅当你利用spfile时，假如在9i中仍旧利用pfile，那末变动办法同8i不异):
SQL>altersystemsetjob_queue_processes=6scope=both;
Systemaltered
2.timed_statistics
搜集操纵体系的计时信息，这些信息可被用来显现工夫等统计信息、优化数据库和SQL语句。要避免因从操纵体系哀求工夫而引发的开支，请将该值设置为False。
利用statspack搜集统计信息时倡议将该值设置为TRUE，不然搜集的统计信息约莫只能起到10%的感化，将timed_statistics设置为True所带来的功能影响与优点比拟是微乎其微的。
该参数使搜集的工夫信息存储在在V$SESSTATS和V$SYSSTATS等静态功能视图中。
timed_statistics参数也能够在实例级举行变动
SQL>altersystemsettimed_statistics=true;
Systemaltered
假如你忧虑一向启用timed_statistics关于功能的影响，你能够在利用statspack之前在system变动，采样事后把该参数静态修正成false。
§步骤二：
必要独自为statspack创立一个存储数据的表空间，假如采样距离较短，周期较长，盘算临时利用，那末大概必要一个年夜一点的表空间，假如每一个半个小时采样一次，一连采样一周，数据量是很年夜的。上面的例子中创立了一个500M的测试表空间。
注重:这里创立的表空间不克不及太小，假如太小的话创立工具会失利，倡议最少创建100M表空间。
SQL>createtablespaceperfstat
2datafile/oracle/oradata/oradata/res/perfstat.dbf
3size500M;
Tablespacecreated。
§步骤三：
在sqlplus顶用internal身份上岸，大概具有SYSDBA(connect/assysdba)权限的用户上岸。
注:在Oracle9i中，不存在internal用户，可使用sys用户以sysdba身份毗连。
先转到$ORACLE_HOME/RDBMS/ADMIN目次，反省安装剧本是不是存在，同时我们实行剧本也能够便利些。
$cd$ORACLE_HOME/rdbms/admin
$ls-lsp*.sql
-rw-r--r--1oracleother1774Feb182000spauto.sql
-rw-r--r--1oracleother62545Jun152000spcpkg.sql
-rw-r--r--1oracleother877Feb182000spcreate.sql
-rw-r--r--1oracleother31193Jun152000spctab.sql
-rw-r--r--1oracleother6414Jun152000spcusr.sql
-rw-r--r--1oracleother758Jun152000spdrop.sql
-rw-r--r--1oracleother3615Jun152000spdtab.sql
-rw-r--r--1oracleother1274Jun152000spdusr.sql
-rw-r--r--1oracleother6760Jun152000sppurge.sql
-rw-r--r--1oracleother71034Jul122000spreport.sql
-rw-r--r--1oracleother2191Jun152000sptrunc.sql
-rw-r--r--1oracleother30133Jun152000spup816.sql
$
接上去我们就能够入手下手安装Statspack了。在Oracle8.1.6版本中运转statscre.sql;在Oracle8.1.7版本中运转spcreate.sql。
这时代会提醒你输出缺省表空间和一时表空间的地位,输出我们为perfstat用户创立的表空间和你的一时表空间。安装剧本会主动创立perfstat用户。
$sqlplus
SQL*Plus:Release8.1.7.0.0-ProductiononSatJul2616:27:312003
(c)Copyright2000OracleCorporation.Allrightsreserved.
Enteruser-name:internal
Connectedto:
Oracle8iEnterpriseEditionRelease8.1.7.0.0-Production
WiththePartitioningoption
JServerRelease8.1.7.0.0-Production
SQL>
SQL>@spcreate
...InstallingRequiredPackages
Packagecreated.
Grantsucceeded.
Viewcreated.
Packagebodycreated.
Packagecreated.
Synonymdropped.
Synonymcreated.
……
SpecifyPERFSTATusersdefaulttablespace
Entervaluefordefault_tablespace:perfstat
Usingperfstatforthedefaulttablespace
Useraltered.
Useraltered.
SpecifyPERFSTATuserstemporarytablespace
Entervaluefortemporary_tablespace:temp
Usingtempforthetemporarytablespace
Useraltered.
NOTE:
SPCUSRcomplete.Pleasecheckspcusr.lisforanyerrors.
……
假如安装乐成，你能够接着看到以下的输入信息：
….
CreatingPackageSTATSPACK...
Packagecreated.
Noerrors.
CreatingPackageBodySTATSPACK...
Packagebodycreated.
Noerrors.
NOTE:
SPCPKGcomplete.Pleasecheckspcpkg.lisforanyerrors.
能够检察.lis文件检察安装时的毛病信息。
§步骤四：
假如安装过程当中呈现毛病，那末能够运转spdrop.sql剧本来删除这些安装剧本创建的工具。然后从头运转spcreate.sql来创立这些工具。
SQL>@spdrop
Droppingoldversions(ifany)
Synonymdropped.
Sequencedropped.
Synonymdropped.
Tabledropped.
Synonymdropped.
Viewdropped.
……
NOTE:
SPDUSRcomplete.Pleasecheckspdusr.lisforanyerrors.
（以上的安装历程形貌是在HP11.11+Oracle8.1.7平台上失掉的）
2.1.2测试statspack
运转statspack.snap能够发生体系快照，运转两次，然后实行spreport.sql就能够天生一个基于两个工夫点的呈报。
假如统统一般，申明安装乐成。
SQL>executestatspack.snap
PL/SQLproceduresuccessfullycompleted.
SQL>executestatspack.snap
PL/SQLproceduresuccessfullycompleted.
SQL>@spreport.sql
但是有大概你会失掉以下毛病：
SQL>execstatspack.snap;
BEGINstatspack.snap;END;
*
ERRORatline1:
ORA-01401:insertedvaluetoolargeforcolumn
ORA-06512:at"PERFSTAT.STATSPACK",line978
ORA-06512:at"PERFSTAT.STATSPACK",line1612
ORA-06512:at"PERFSTAT.STATSPACK",line71
ORA-06512:atline1
这是Oracle的一个Bug，Bug号1940915。
该Bug自8.1.7.3后修改。
这个成绩只会呈现在多位的字符集,必要修正spcpkg.sql剧本，$ORACLE_HOME/rdbms/admin/spcpkg.sql，将"substr"修正为"substrb"，然后从头运转该剧本。
该剧本毛病部分：
selectl_snap_id
,p_dbid
,p_instance_number
,substr(sql_text,1,31)
．．．．．．．．．．．
substr会将多位的字符,看成一个byte.substrb则会看成多个byte。在搜集数据时，statpack会将top10的sql前31个字节存进数据表中,若在SQL的前31个字有中文，就会呈现此毛病。
注重：运转spcpkg.sql也必要以internal用户登录sqlplus
2.1.3天生statspack呈报
挪用spreport.sql能够天生剖析呈报：
当挪用spreprot.sql时，体系起首会查询快照列表，然后请求你选择天生呈报的入手下手快照ID(begin_snap)和停止快照ID(end_snap),天生一个呈报.
为了天生一个report,我们最少必要两次采样:
SQL>@spreport
DBIdDBNameInstNumInstance
-------------------------------------------
2749170756RES1res
CompletedSnapshots
SnapSnap
InstanceDBNameIdSnapStartedLevelComment
-------------------------------------------------------------------------
resRES126Jul200316:365
226Jul200316:375
326Jul200317:035
SpecifytheBeginandEndSnapshotIds
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Entervalueforbegin_snap:2
BeginSnapshotIdspecified:2
Entervalueforend_snap:3
EndSnapshotIdspecified:3
SpecifytheReportName
~~~~~~~~~~~~~~~~~~~~~~~
Thedefaultreportfilenameissp_2_3.Tousethisname,
presstocontinue,otherwiseenteranalternative.
Entervalueforreport_name:rep0726.txt
……
EndofReport
在运转spreport.sql天生statspack呈报的过程当中，会有三个中央提醒用户输出：
1、入手下手快照ID；
2、停止快照ID；
3、输入呈报文件的文件名，缺省的文件名是sp__
下面输出的入手下手快照ID是2，入手下手快照ID是3，输入呈报文件的文件名是rep0726.txt
乐成运转一次statspack.snap就会发生一个snapshot，在天生statspack呈报的时分就能够看到这个snapid和snap运转的工夫。运转statspack.snap，就是下面所说的采样，statspack呈报是剖析两个采样点之间各类情形。
2.1.4删除汗青快照数据
后面讲过，乐成运转一次statspack.snap就会发生一个snapshot，这个snapshot的基础信息是寄存在PERFSTAT.stats$snapshot表中的，天生statspack呈报时会查询该表的数据，供用户选择筹办剖析的snapshot。假如运转statspack.snap次数多了今后，该表的数据也会增添，汗青数据会影响一般运转的效果，因而必要准时清算一下汗青快照数据。
删除stats$snapshot数据表中的响应数据，其他表中的数据会响应的级连删除：
SQL>selectmax(snap_id)fromstats$snapshot;
MAX(SNAP_ID)
------------
166
SQL>deletefromstats$snapshotwheresnap_id<=166;
143rowsdeleted
你能够变动snap_id的局限以保存你必要的数据。
在以上删除过程当中，你能够看到一切相干的表都被锁定。
SQL>selecta.object_id,a.oracle_username,b.object_name
fromv$locked_objecta,dba_objectsb
wherea.object_id=b.object_id
/
OBJECT_IDORACLE_USERNAMEOBJECT_NAME
---------------------------------------------------------------------------------------------------------------------
156PERFSTATSNAP$
39700PERFSTATSTATS$LIBRARYCACHE
39706PERFSTATSTATS$ROLLSTAT
39712PERFSTATSTATS$SGA
39754PERFSTATSTATS$PARAMETER
39745PERFSTATSTATS$SQL_STATISTICS
39739PERFSTATSTATS$SQL_SUMMARY
39736PERFSTATSTATS$ENQUEUESTAT
39733PERFSTATSTATS$WAITSTAT
39730PERFSTATSTATS$BG_EVENT_SUMMARY
39724PERFSTATSTATS$SYSTEM_EVENT
39718PERFSTATSTATS$SYSSTAT
39715PERFSTATSTATS$SGASTAT
39709PERFSTATSTATS$ROWCACHE_SUMMARY
39703PERFSTATSTATS$BUFFER_POOL_STATISTICS
39697PERFSTATSTATS$LATCH_MISSES_SUMMARY
39679PERFSTATSTATS$SNAPSHOT
39682PERFSTATSTATS$FILESTATXS
39688PERFSTATSTATS$LATCH
174PERFSTATJOB$
20rowsselected
Oracle还供应了体系剧本用于Truncate这些统计信息表，这个剧本名字是:sptrunc.sql(8i、9i都不异)
该剧本次要内容以下，内里看到的就是statspack相干的一切体系表：
truncatetableSTATS$FILESTATXS;
truncatetableSTATS$LATCH;
truncatetableSTATS$LATCH_CHILDREN;
truncatetableSTATS$LATCH_MISSES_SUMMARY;
truncatetableSTATS$LATCH_PARENT;
truncatetableSTATS$LIBRARYCACHE;
truncatetableSTATS$BUFFER_POOL_STATISTICS;
truncatetableSTATS$ROLLSTAT;
truncatetableSTATS$ROWCACHE_SUMMARY;
truncatetableSTATS$SGA;
truncatetableSTATS$SGASTAT;
truncatetableSTATS$SYSSTAT;
truncatetableSTATS$SESSTAT;
truncatetableSTATS$SYSTEM_EVENT;
truncatetableSTATS$SESSION_EVENT;
truncatetableSTATS$BG_EVENT_SUMMARY;
truncatetableSTATS$WAITSTAT;
truncatetableSTATS$ENQUEUESTAT;
truncatetableSTATS$SQL_SUMMARY;
truncatetableSTATS$SQL_STATISTICS;
truncatetableSTATS$SQLTEXT;
truncatetableSTATS$PARAMETER;
deletefromSTATS$SNAPSHOT;
deletefromSTATS$DATABASE_INSTANCE;
commit;
2.1.5一些主要剧本
1．经由过程导出保留及共享数据
在诊断体系成绩时，大概必要向专业人士供应原始数据，这时候我们能够导出Statspack表数据，
个中我们大概用到：spuexp.par
其内容次要为：
file=spuexp.dmplog=spuexp.logcompress=ygrants=yindexes=yrows=yconstraints=yowner=PERFSTATconsistent=y
我们能够导出以下：
expuserid=perfstat/my_perfstat_passwordparfile=spuexp.par
2．删除数据
spdrop.sql在实行时次要挪用两个剧本:spdtab.sql、spdusr.sql
前者删除表及同义词等数据，后者删除用户
3．Oracle92中新增添的剧本
1）用于晋级statspack工具的剧本,这些剧本必要以具有SYSDBA权限的用户运转,晋级前请先
备份存在的Schema数据:
spup90.sql:用于晋级9.0版本的形式至9.2版本。
spup817.sql:假如从Statspack8.1.7晋级,必要运转这个剧本
spup816.sql:从Statspack8.1.6晋级,必要运转这个剧本，然后运转spup817.sql
2）sprepsql.sql用于依据给定的SQLHash值天生SQL呈报
2.1.6调剂statspack的搜集门限
Statspack有两品种型的搜集选项：
1．级别（level）：把持搜集数据的范例
Statspack共有三种快照级别，默许值是5
a.level0:一样平常功能统计。包含守候事务、体系事务、体系统计、回滚段统计、行缓存、SGA、会话、锁、缓冲池统计等等。
b.level5:增添SQL语句。除包含level0的一切内容，还包含SQL语句的搜集，搜集了局纪录在stats$sql_summary中。
c.level10:增添子锁存统计。包含level5的一切内容。而且还会将附加的子锁存存进stats$lathc_children中。在利用这个级别时必要稳重，倡议在Oraclesupport的引导下举行。
能够经由过程statspack包修正缺省的级别设置
SQL>executestatspack.snap(i_snap_level=>0,i_modify_parameter=>’true’);
经由过程如许的设置，今后的搜集级别都将是0级。
假如你只是想本次改动搜集级别，能够疏忽i_modify_parameter参数。
SQL>executestatspack.snap(i_snap_level=>10);
2．快照门限：设置搜集的数据的阈值。
快照门限只使用于stats$sql_summary表中猎取的SQL语句。
由于每个快照城市搜集良多数据，每行都代表猎取快照时数据库中的一个SQL语句，以是stats$sql_summary很快就会成为Statspack中最年夜的表。
门限存储在stats$statspack_parameter表中。让我们了却一下各类门限：
a.executions_th这是SQL语句实行的数目(默许值是100)
b.disk_reads_tn这是SQL语句实行的磁盘读进数目（默许值是1000）
c.parse_calls_th这是SQL语句实行的剖析挪用的数目（默许值是1000）
d.buffer_gets_th这是SQL语句实行的缓冲区猎取的数目（默许值是10000）
任何一个门限值凌驾以上参数就会发生一笔记录。
经由过程挪用statspack.modify_statspack_parameter函数我们能够改动门限的默许值。
比方：
SQL>executestatspack.modify_statspack_parameter(i_buffer_gets_th=>100000,i_disk_reads_th=>100000;
2.2对statspack呈报的剖析
从下面的形貌能够看出，发生一个statspack呈报是对照复杂的，可是怎样读懂statspack呈报却不是那末简单，必要对Oracle的系统架构、内存布局、守候事务和使用体系有充实的懂得，加上不休的理论，才干基础读懂statspack呈报而且从呈报中找到调剂优化Oracle的路子。
上面接合一个实践的statspack呈报，大抵剖析一下。
2.2.1基础信息剖析
DBNameDBIdInstanceInstNumReleaseOPSHost
---------------------------------------------------------------------
RES2749170756res18.1.7.0.0NOres
SnapIdSnapTimeSessions
---------------------------------
BeginSnap:226-Jul-0316:37:0838
EndSnap:326-Jul-0317:03:2338
Elapsed:26.25(mins)
Statspack呈报起首形貌了数据库的基础情形，好比数据库名、实例名、实例个数、oracle版本号等等；然后是该呈报的入手下手快照和停止快照的信息，包含snapid,snaptime等等；最初是该呈报经由的工夫跨度，单元是分钟(mins)。
CacheSizes
~~~~~~~~~~~
db_block_buffers:61440log_buffer:163840
db_block_size:8192shared_pool_size:52428800
然后形貌了Oracle内存布局中几个主要的参数。
2.2.2内存信息剖析
LoadProfile
~~~~~~~~~~~~PerSecondPerTransaction
------------------------------
Redosize:4,834.8711,116.67
Logicalreads:405.53932.43
Blockchanges:60.03138.02
Physicalreads:138.63318.75
Physicalwrites:54.27124.79
Usercalls:62.69144.13
Parses:19.1444.00
Hardparses:2.265.20
Sorts:1.834.20
Logons:0.210.47
Executes:21.1048.50
Transactions:0.43
%BlockschangedperRead:14.80RecursiveCall%:34.45
Rollbackpertransaction%:0.00RowsperSort:20.57
Redosize:是日记的天生量，分为每秒和每事件所发生的，一般在很忙碌的体系中日记天生量大概到达上百k，乃至几百k；
Logicalreads:逻辑读实践上就是logicalIO=buffergets暗示的寄义，我们能够如许以为，block在内存中，我们每次读一块内存，就相称于一次逻辑读；
Parses和Hardparses:Parse和hardparse一般是很简单出成绩的部分，80%的体系的慢都是因为这个缘故原由所招致的。
所谓parse分softparse和hardparse，softparse是当一条sql传出去后，必要在sharedpool中找是不是有不异的sql，假如找到了，那就是softparse，假如没有找着，那就入手下手hardparse，实践上hardparse次要是反省该sql所触及到的一切的工具是不是无效和权限等干系，hardparse以后才依据rule/cost形式天生实行企图，再实行sql。
而hardparse的本源，基础都是因为不利用bindvar所招致的，不利用bindvar违反了oracle的sharedpool的计划的准绳，违反了这个计划用来共享的头脑，如许招致shared_pool_size内里射中率下落。因而不利用bindvar，将招致cpu利用率的成绩，极有使得功能急剧下落。
另有就是为了保护internalstructure，必要利用latch，latch是一种Oracle初级布局,用于回护内存资本，是一种外部性命周期很短的lock，大批利用latch将损耗大批的cpu资本。
Sorts:暗示排序的数目；
Executes:暗示实行次数；
Transactions:暗示事件数目；
Rollbackpertransaction%:暗示数据库中事件的回退率。假如不是由于营业自己的缘故原由，一般应当小于10%为好，回退是一个很损耗资本的操纵。
InstanceEfficiencyPercentages(Target100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BufferNowait%:100.00RedoNoWait%:99.98
BufferHit%:65.82In-memorySort%:99.65
LibraryHit%:91.32SoftParse%:88.18
ExecutetoParse%:9.28LatchHit%:99.99
ParseCPUtoParseElapsd%:94.61%Non-ParseCPU:99.90
BufferHit%:数据缓冲区射中率，一般应当年夜于90%；
LibraryHit%:libaraycache的射中率，一般应当年夜于98%；
In-memorySort%:排序在内存的比例，假如这个比例太小，能够思索增年夜sort_area_size，使得排序在内存中举行而不是在temp表空间中举行；
SoftParse%:软剖析的百分比，这个百分比也应当很年夜才好，由于我们要只管削减hardparse。softparse百分比=soft/(soft+hard)；
ExecutetoParse%:这个数字也应当是越年夜越好，靠近100%最好。有些呈报中这个值是负的，看上往很奇异。现实上这暗示一个成绩，sql假如被ageout的话便可能呈现这类情形，也就是sql老化，或实行altersystemflushshared_pool等。
SharedPoolStatisticsBeginEnd
------------
MemoryUsage%:90.6387.19
%SQLwithexecutions>1:71.5375.39
%MemoryforSQLw/exec>1:59.4565.17
%SQLwithexecutions>1:这个暗示SQL被实行次数多于一次的比率，也应当年夜为好，小则暗示良多sql只被实行了一次，申明没有利用bindvar；
2.2.3守候事务剖析
接上去，statspack呈报中形貌的是守候事务（WaitEvents），这是Oracle中对照庞大难明的观点。
Oracle的守候事务是权衡Oracle运转情况的主要根据及目标。
守候事务的观点是在Oracle7.0.1.2中引进的，大抵有100个守候事务。在Oracle8.0中这个数量增添到了约莫150个，在Oracle8i中约莫有200个事务,在Oracle9i中约莫有360个守候事务。
次要有两品种其余守候事务，即余暇（idle）守候事务和非余暇（non-idle）守候事务。
余暇事务指Oracle正守候某种事情,在诊断和优化数据库的时分,我们不必过量注重这部分事务。
罕见的余暇事务有:
?dispatchertimer
?lockelementcleanup
?Nullevent
?parallelquerydequeuewait
?parallelqueryidlewait-Slaves
?pipeget
?PL/SQLlocktimer
?pmontimer-pmon
?rdbmsipcmessage
?slavewait
?smontimer
?SQL*Netbreak/resettoclient
?SQL*Netmessagefromclient
?SQL*Netmessagetoclient
?SQL*Netmoredatatoclient
?virtualcircuitstatus
?clientmessage
非余暇守候事务专门针对Oracle的举动,指数据库义务或使用运转过程当中产生的守候，这些守候事务是我们在调剂数据库的时分应当存眷与研讨的。
一些罕见的非余暇守候事务有:
?dbfilescatteredread
?dbfilesequentialread
?bufferbusywaits
?freebufferwaits
?enqueue
?latchfree
?logfileparallelwrite
?logfilesync
上面接合statspack中的一些守候事务举行报告。
Top5WaitEvents
~~~~~~~~~~~~~~~~~Wait%Total
EventWaitsTime(cs)WtTime
---------------------------------------------------------------------------
dbfilescatteredread26,87712,85052.94
dbfileparallelwrite4723,67415.13
logfileparallelwrite9751,5606.43
directpathwrite1,5711,5436.36
controlfileparallelwrite6521,2905.31
-------------------------------------------------------------
dbfilescatteredread:DB文件分离读取。这个守候事务很罕见，常常在top5中呈现，这暗示，一次从磁盘读数据出去的时分读了多于一个block的数据，而这些数据又被分离的放在不一连的内存块中，由于一次读出去的是多于一个block的。
一般来讲我们能够以为是全表扫描范例的读，由于依据索引读表数据的话一次只读一个block，假如这个数字过年夜，就标明该表找不到索引，大概只能找到无限的索引，多是全表扫描过量，必要反省sql是不是公道的使用了索引，大概是不是必要创建公道的索引。
当全表扫描被限定在内存时，它们很少会进进一连的缓冲区内，而是分离于全部缓冲存储器中。只管在特定前提下实行全表扫描大概比索引扫描更无效，但假如呈现这类守候时，最好反省一下这些全表扫描是不是需要,是不是能够经由过程创建符合的索引来削减关于年夜表全表扫描所发生的年夜范围数据读取。
关于常常利用的小表，应当只管把他们pin在内存中，制止不用要的老化扫除及反复读取。
dbfilesequentialread:DB文件一连读取。一般显现单个块的读取(一般指索引读取)，暗示的是读进磁盘的block被放在一连的内存块中。
现实上年夜部分基础代表着单个block的读进，能够说意味着IO大概说经由过程索引读进的对照多。由于一次IO若读进多个的block，放进一连的内存块的概率是很小的，散布在分歧block的大批纪录被读进就会碰到此事务。由于依据索引读数据的话，假定100笔记录，依据索引，不算索引自己的读，而依据索引每一个值往读一下表数据，实际上最多大概发生100buffergets，而假如是fulltablescan，则100条数据完整大概在一个block内里，则几近一次就读过这个block了，就会发生这么年夜的差别。
这类守候的数量良多时，大概显现表的毗连按次欠安，大概不加选择地举行索引。
关于初级事件处置（high-transaction）、调剂优秀（welltuned）的体系，这一数值很年夜是很一般的，但在某些情形下，它大概表示着体系中存在成绩。
你应该将这一守候统计量与Statspack呈报中的已知成绩（如效力较低的SQL）接洽起来。反省索引扫描，以包管每一个扫描都是需要的，并反省多表毗连的毗连按次。
DB_CACHE_SIZE也是这些守候呈现频次的决意要素。有成绩的散列地区（Hash-area）毗连应该呈现在PGA内存中，但它们也会损耗大批内存，从而在按次读取时招致大批守候。它们也大概以间接路径读／写守候的情势呈现。
FreeBufferWait:开释缓冲区。
这类守候标明体系正在守候内存中的缓冲，由于内存中已没有可用的缓冲空间了。假如一切SQL都失掉了调优，这类守候大概暗示你必要增年夜DB_BUFFER_CACHE。开释缓冲区守候也大概暗示不加选择的SQL招致数据溢出了带有索引块的缓冲存储器，没无为守候体系处置的特定语句留有缓冲区。
这类情形一般暗示正在实行相称多半量的DML（拔出／更新／删除），而且大概申明DBWR写的速率不敷快，缓冲存储器大概充斥了不异缓冲器的多个版本，从而招致效力十分低。为懂得决这个成绩，大概必要思索增添反省点、使用更多的DBWR历程，大概增添物理磁盘的数目。
BufferBusyWait:缓冲区忙。
该守候事务暗示正在守候一个以unshareable体例利用的缓冲区，大概暗示以后正在被读进buffercache。也就是当历程想猎取大概操纵某个block的时分却发明被其余历程在利用而呈现守候。一样平常来讲BufferBusyWait不该年夜于1%。
反省缓冲守候统计部分（或V$WAITSTAT），看一上等待是不是位于段头。假如是，能够思索增添自在列表（freelist，关于Oracle8iDMT）大概增添freelistgroups.
其修正语法为：
SQL>altertablesp_itemstorage(freelists2);
Tablealtered。
关于Oracle8i而言，增添freelist参数，在良多时分能够分明减缓守候，假如利用LMT，也就是LocalManangementTablespace，区段的办理就绝对复杂还能够思索修正数据块的pctusedpctfree值，好比增年夜pctfree能够扩展数据的散布，在某种水平上就能够削减热门块的合作。
<P>“对于MySQL数据库，无论是在开发方面，还是支持方面，现在有大量强大的MySQL学习教程可以选择。每一个新手开发者可以轻松地使用MySQL数据库进行开发。 从项目平台的选择上讲，我们关心的，应该是一款产品能不能满足任务需求，而不是网上怎么说。 Mirror可以算是SQLServer的Dataguard了。但是能不能被大伙用起来就不知道了。 XML字段类型更好的解决了XML数据的操作。XQuery确实不错，但是个人对其没好感。（CSDN的开发者应该是相当的熟了！） 需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。 相信各位对数据库和怎么样学习数据库都有一些经验和看法，也会有人走了一些弯路总结出自己的经验来，希望大家能把各自的看法和经验拿出来分享，给别人一份帮助，给自己一份快乐 以前的DTS轻盈简单。但是现在的SSIS虽然功能强大了很多，但是总是让人感觉太麻烦。看看论坛中询问SSIS的贴子就知道。做的功能太强大了，往往会有很多用户不会用了 现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层. SP4是一个累积性的ServicePack，包含自以前的ServicePack发布以来所有的修补程序（包括MS03-031安全公告）。
页:
[1]