MYSQL教程之用orabm测试oracle服务器的TPS值
当然，或许这并不是我们拒绝MySQL的一个有说服力的MySQL学习教程，但是对于一些比较守旧的IT经理来说，在为一些关键业务选择平台的时候，平台的成熟性却是必须要考虑的一个因素，在这一点上，MySQL无疑毫无优势。oracle|服务器研发论坛
会商主题
葛宏宾109649/user/zte_ltd
今天16:16.
主题:
.
用orabm测试oracle服务器的TPS值
.
分类:
测试
用orabm测试oracle服务器的TPS值
1、orabm简介
Orabm是一个开源的oracle功能测试工具，，包括了一套SQL剧本和几个命令路程序。
作者GeoffIngram，是《High-PerformanceOracle:ProvenMethodsforAchievingOptimumPerformanceandAvailability》一书的作者。
该工具能够从作者的主页（http://www.dbcool.com/）取得，详细下载地点是http://www.linxcel.co.uk/orabm/orabm.tar
2、安装orabm
下载的orabm是一个tar包，一样平常能够将该文件上传到oracle服务器上，便利间接运转SQL剧本。
本次测试的情况是：AIX5.2，oracle9.2.0.1，操纵体系用户是oracle
利用orabm的用户必需具有oracle的相干情况变量，本次测试顶用的是oracle用户。
（1）解包
$tarxvforabm.tar
xorabm,0bytes,0tapeblocks
xorabm/src,0bytes,0tapeblocks
xorabm/src/orabmload.pc,24200bytes,48tapeblocks
xorabm/src/orabm.c,9346bytes,19tapeblocks
xorabm/src/init.ora,1442bytes,3tapeblocks
xorabm/src/BUILD_FROM_SOURCE.txt,863bytes,2tapeblocks
xorabm/install,0bytes,0tapeblocks
xorabm/install/orabm_analyze.sql,1068bytes,3tapeblocks
xorabm/install/orabm_cache.sql,1116bytes,3tapeblocks
xorabm/install/orabm_ind.sql,1124bytes,3tapeblocks
xorabm/install/orabm_query_cache.sql,497bytes,1tapeblocks
xorabm/install/orabm_serverside_stress.sql,8528bytes,17tapeblocks
xorabm/install/orabm_tab.sql,2321bytes,5tapeblocks
xorabm/install/orabm_tab_rm.sql,197bytes,1tapeblocks
xorabm/install/orabm_user.sql,233bytes,1tapeblocks
xorabm/bin,0bytes,0tapeblocks
xorabm/bin/orabm_tps.awk,182bytes,1tapeblocks
xorabm/bin/orabm_tps.sh,70bytes,1tapeblocks
xorabm/bin/solaris,0bytes,0tapeblocks
xorabm/bin/solaris/orabmload,85940bytes,168tapeblocks
xorabm/bin/solaris/orabm,53140bytes,104tapeblocks
......
解包完成今后就能够入手下手安装了，实在次要就是运转SQL剧本创建测试情况。
安装进度表以下：
#OperationCommand
1createtheORABMuser(assumesTOOLStablespace,TEMPtemporarytablespace)sqlplussystem/pwd@orabm_user
2createthetablessqlplussystem/pwd@orabm_tab
3loadthedata$orabmloadWarehouses1
4createtheindexessqlplussystem/pwd@orabm_ind
5analyzethetablesandindexessqlplussystem/pwd@orabm_analyze
6createthestress-testPL/SQLproceduressqlplussystem/pwd@orabm_serverside_stress
7cachethetableandindexdataintheSGAsqlplussystem/pwd@orabm_cache
（2）建数据库用户和表
对应于安装进度表的第1、2两个步骤
注重：因为所建用户ORABM的缺省表空间是TOOLS，因而最幸亏安装之前（最少在装载数据之前）将TOOLS表空间扩展到150MB摆布。固然一样平常TOOLS表空间都设置为AUTOEXTENT，可是仍是会影响装载数据的速率，前面的步骤会看到装载的数据是对照年夜的。
$ls
orabm_analyze.sqlorabm_serverside_stress.sql
orabm_cache.sqlorabm_tab.sql
orabm_ind.sqlorabm_tab_rm.sql
orabm_query_cache.sqlorabm_user.sql
$sqlplus"/assysdba"@orabm_user
SQL*Plus:Release9.2.0.1.0-ProductiononWedJan2614:32:482005
Copyright(c)1982,2002,OracleCorporation.Allrightsreserved.
Connectedto:
Oracle9iEnterpriseEditionRelease9.2.0.1.0-64bitProduction
WiththePartitioningandOLAPoptions
JServerRelease9.2.0.1.0-Production
Usercreated.
Grantsucceeded.
Useraltered.
Useraltered.
Revokesucceeded.
DisconnectedfromOracle9iEnterpriseEditionRelease9.2.0.1.0-64bitProduction
WiththePartitioning,OLAPandOracleDataMiningoptions
JServerRelease9.2.0.4.0–Production
$sqlplus"/assysdba"@orabm_tab
SQL*Plus:Release9.2.0.1.0-ProductiononWedJan2614:32:482005
Copyright(c)1982,2002,OracleCorporation.Allrightsreserved.
Connectedto:
Oracle9iEnterpriseEditionRelease9.2.0.1.0-64bitProduction
WiththePartitioningandOLAPoptions
JServerRelease9.2.0.1.0-Production
Tablecreated.
Tablecreated.
Tablecreated.
Tablecreated.
Tablecreated.
Tablecreated.
Tablecreated.
Tablecreated.
Tablecreated.
DisconnectedfromOracle9iEnterpriseEditionRelease9.2.0.1.0-64bitProduction
WiththePartitioning,OLAPandOracleDataMiningoptions
JServerRelease9.2.0.1.0-Production
（3）装载数据
对应于安装进度表中的第3个步骤
依照步骤形貌，原本这个应当在oracle服务器上运转orabmload来完成，可是程序包中的orabmload程序只要linux、solaris、windows三个平台下的，没有AIX平台下的。
但orabm是开源的程序，在src目次下就是源程序
$ls-l
total88
-rw-r--r--1oracledba863Nov072002BUILD_FROM_SOURCE.txt
-rw-r--r--1oracledba1442Nov072002init.ora
-rw-r--r--1oracledba9346Nov072002orabm.c
-rw-r--r--1oracledba24200Nov072002orabmload.pc
个中orabm.c、orabmload.c是两个使用程序的源程序，BUILD_FROM_SOURCE.txt是编译申明。我依照编译申明上的引导，make了一下，可是最初运转程序的时分堕落，大概是另有甚么编译选项不合错误吧。上面是运转毛病：
$./orabmloadWarehouse1
exec():0509-036Cannotloadprogram./orabmloadbecauseofthefollowingerrors
:
0509-150Dependentmodule/home/oracle/OraHome1/lib32/libclntsh.a(shr.
o)couldnotbeloaded.
0509-124Theprogramisadiscontinued64-bitobjectfile.
------------跋文------------
前面发明是程序链接的库文件错了，不该该链接/home/oracle/OraHome1/lib32/目次，这是为32位程序筹办的，应当链接/home/oracle/OraHome1/lib/，缺省就是64位。
按此修正了一下主机用户oracle的.profile文件，然后从头登录，再编译一下，最初运转是没有成绩的。
------------跋文停止------------
还好的是，orabm事后供应windows版本的数据装载程序，在orabm/bin/windows目次下就是。
将orabm拷贝大概FTP到windows平台的呆板上，设置好oracle毗连，便可装载数据了，以下：
E: emp>setLOCAL=ccbver
E: emp>orabmloadWarehouse1
ConnectedtoORACLEasuser:ORABM
usingtimestamp=20050126103630
TPCCDataLoadStarted...
LoadingItem
....................20000
....................40000
....................60000
....................80000
....................100000
ItemDone.
LoadingWarehouse
LoadingStockWid=1
....................20000
....................40000
....................60000
....................80000
....................100000
StockDone.
LoadingDistrict
LoadingCustomerforDID=1,WID=1
...CustomerDone.
LoadingCustomerforDID=2,WID=1
...CustomerDone.
LoadingCustomerforDID=3,WID=1
...CustomerDone.
LoadingCustomerforDID=4,WID=1
...CustomerDone.
LoadingCustomerforDID=5,WID=1
...CustomerDone.
LoadingCustomerforDID=6,WID=1
...CustomerDone.
LoadingCustomerforDID=7,WID=1
...CustomerDone.
LoadingCustomerforDID=8,WID=1
...CustomerDone.
LoadingCustomerforDID=9,WID=1
...CustomerDone.
LoadingCustomerforDID=10,WID=1
...CustomerDone.
LoadingOrdersforD=1,W=1
.1000
.2000
.3000
OrdersDone.
LoadingOrdersforD=2,W=1
.1000
.2000
.3000
OrdersDone.
LoadingOrdersforD=3,W=1
.1000
.2000
.3000
OrdersDone.
LoadingOrdersforD=4,W=1
.1000
.2000
.3000
OrdersDone.
LoadingOrdersforD=5,W=1
.1000
.2000
.3000
OrdersDone.
LoadingOrdersforD=6,W=1
.1000
.2000
.3000
OrdersDone.
LoadingOrdersforD=7,W=1
.1000
.2000
.3000
OrdersDone.
LoadingOrdersforD=8,W=1
.1000
.2000
.3000
OrdersDone.
LoadingOrdersforD=9,W=1
.1000
.2000
.3000
OrdersDone.
LoadingOrdersforD=10,W=1
.1000
.2000
.3000
OrdersDone.
...DATALOADINGCOMPLETEDSUCCESSFULLY
乐成装载数据，必要的工夫大概有点长。
（4）建索引、剖析表和索引、建压力测试存储历程、将数据装载到cache
对应于安装进度表中的第4、5、6、7步骤
这几个步骤都是实行SQL剧本，在oracle服务器上实行便可。
$cdinstall
$ls
orabm_analyze.sqlorabm_ind.sqlorabm_serverside_stress.sqlorabm_tab_rm.sql
orabm_cache.sqlorabm_query_cache.sqlorabm_tab.sqlorabm_user.sql
$sqlplus"/assysdba"@orabm_ind
SQL*Plus:Release9.2.0.1.0-ProductiononWedJan2614:32:482005
Copyright(c)1982,2002,OracleCorporation.Allrightsreserved.
Connectedto:
Oracle9iEnterpriseEditionRelease9.2.0.1.0-64bitProduction
WiththePartitioningandOLAPoptions
JServerRelease9.2.0.1.0-Production
......
$sqlplus"/assysdba"@orabm_analyze
...........
$sqlplus"/assysdba"@orabm_serverside_stress
......
$sqlplus"/assysdba"@orabm_cache
......
这前面实行的SQL剧本都不会有甚么成绩，记着步骤按次便可。
至此，orabm的安装已完成了。
3、测试TPS值
Orabm安装完成今后，就能够入手下手测试oracle服务器的TPS值了。
一样的，在本次测试中，因为使用程序没有AIX版本，以是只能在windows平台作为oracle客户端来实行测试程序了。
（1）orabm的道理
我们先经由过程作者主页上的一段话来懂得一下orabm的道理。
Orabmworksbyrunningauser-specifiednumberofdatabasetransactionsineachofauser-specifiednumberofconcurrentdatabasesessions.
Orabm经由过程在用户指定的并发下运转指定命量的事件来测试体系功能.
ThetransactionsareexecutedbytheORABM_SERVERSIDE_STRESSstoredprocedure,undertheschemaORABM.
事件经由过程实行orabm用户的ORABM_SERVERSIDE_STRESS历程来完成.
Foreachconcurrentsession,ORABM_SERVERSIDE_STRESSrunsthenumberoftransactionsspecifiedontheorabmcommandline,andreturnsthetransactionspersecond(TPS)valueforthatsessionduringthesamplingintervaloncompletion.
关于每一个并发session,ORABM_SERVERSIDE_STRESS运转在orabm命令行指定命量的事件，并前往在完成一切义务的采样距离内每秒的事件数目.
Toensurethatallconcurrentsessionsareprocessingtransactionsduringthesamplinginterval,theTPSvalueonlyincludesresultsfromthemiddle80%oftransactions:thefirst10%andlast10%areignored.
为了包管正确性,TPS值只取两头的80%数据,头尾的10%都将被疏忽.
ThetransactionsarelooselybasedontheTPC-COrder-StatusandStock-Leveltransactions,usingapredefineddistributionoftransactions.
事件是松懈的,基于尺度的TPC-C测试的定单、库存事件模子,利用预界说的事件散布.
Thetransactionsplit,whichisbasedondatareturnedbytheDBMS_RANDOMpackage,shouldbe:
事件基于DBMS_RANDOM包的前往值举行支解,应当是:
Stock-Level:Order-by-Customer-Name:Order-by-Customer-Id
50%:30%:20%
ThestringreturnedbyORABM_SERVERSIDE_STRESSincludesthetransactionsplitduringthetest,toensurethatthetransactiondistributioniscorrect,subjecttorandomfluctuationse.g.:
为了确保事件散布的准确性,ORABM_SERVERSIDE_STRESS的输入包括事件支解比例,输入了局具有随机动摇,比方:
...sl=4042(50.5%)on=2384(29.8%)oi=1573(19.7%)...
Onceyouhavesetupthetesttables,data,andindexes,yourereadytorunorabm.Thefollowingcommandshowsorabmrunning20000transactionsinasinglesessionagainsttheOracledatabaseidentifiedbyORACLE_SIDintheUNIXenvironment:
在乐成安装了orabm以后,在UNIX下界说好了ORACLE_SID情况变量以后,我们能够以下运转orabm命令举行测试:
$orabm120000
ThiscommandlinerunsthesameworkloadagainstaremotedatabaseidentifiedbytheOracleNetaliaslinxceld1.co.ukfromaWindowscommandbox:
以下是在WINDOWS下远程运转体例:
C:>orabm120000linxceld1.co.uk
Note:runningagainstaremotedatabasehaslittle(ifany),affectonthetransactionthroughput,becauseallprocessingtakesplaceontheDBMSserver.
ExecutionofasingleOrabmsessionshouldshowasingleCPUatcloseto100%utilization,providedthatalltableandindexdataispresentintheOracleblockbuffercacheandnootherworkloadisrunningonthedatabaseserver.OnUNIXorLinux,youcanusethe“top”commandtoconfirmthis,orcheckthatno"dbfilesequentialread"eventwaitsaretakingplacefortheOraclesessionusinginfointheV$SESSION_EVENTview-theseindicatewaitsforphysicalI/O.
假如一切的测试表和相干索引都已Cache到内存中,体系上没有其他义务运转,那末你能够看到单个OrabmSession会利用快要100%的CPU资本.在Linux大概Unix上，可使用Top来检察CPU利用情形,大概审查数据库中不存在"dbfilesequentialread"守候事务.
Alternatively,ifyourOracleDBMSisrunningonLinux,youcanusethegkrellmperformancemonitortoshowthatCPUutilizationofasingleCPUisat~100%andnophysicalI/Oistakingplace.Gkrellmcanbedownloadedfrom:
http://web.wt.net/~billw/gkrellm/gkrellm.html
Heresanexampleofthecommandlineyouwouldusetorun10000transactionsagainstalocalOracledatabaseforthreeiterations.Inthefirstiteration,onesessionruns,intheseconditerationtwoconcurrentsessionsrun,andinthethirditeration,sixconcurrentsessionsrun:
以下是一个测试例子,对当地数据库举行三个阶段测试,分离以1,2,6个并发实行10000个事件.
$orabm1,2,610000
Keepinmindthatthespecifiednumberoftransactionsisrunineachconcurrentsession.
注重,这里界说的10000个事件是对每一个session来讲的.
Note:youshouldspecifysufficienttransactionssuchthattheTPSresultsproduceddontfluctuatesignificantlybetweenrunsforagivennumberofsessions;100000isagoodvaluetochoose.
注重：你应当界说充足的事件以便TPS了局在分歧数目并发下动摇只管小,一般100,000是一个好的选择.
ResultsOutput
Outputisappendedtoalogfileorabm.database.log,wheredatabaseiseithertheORACLE_SIDorTNSaliasthatidentifiesthedatabasewherethetestwasrune.g.orabm.t92.log.Foreachiteration,theTPSvalueforeachconcurrentsessionappearsbetweenbeginandendmarkers.Forexample,thefollowingshowsthecontentsofthelogfortwoconcurrentsessions-inthiscasetheseconditerationforthepreviouscommandlineexample-wheretxn(all)displaysthetotaltransactioncount,andxn(sam)andt(sam)showthetotaltransactionsandtimeforthemiddle80%oftransactionsforwhichsamplingtookplace:
输入了局的申明:
txn(all)----代表TotaltransactionCount,总的事件数目.
xn(sam)-----采样的事件数目
t(sam)------采样事件运转的工夫.
---beginsess=2txn=10000ORACLE_SID=t92FriNov820:31:482002
T92.WORLDtxn(all)=10000xn(sam)=7999t(sam)=44tps=182...
T92.WORLDtxn(all)=10000xn(sam)=7999t(sam)=45tps=178...
---end-FriNov820:32:462002
ThetotalTPSforthisiterationisthesumoftheTPSforthetwoconcurrentsessions(182+178=360).
关于以上输入,在2个并发下,TPS值为182+178=360
Ashellscript(orabm_tps.sh)canbeusedtoprocessoutputfromthelogonUNIXandLinux.ThescriptaggregatestheTPSvaluesforconcurrentsessionsinasingleiterationintoatotalTPSvalueforthatiteration.Theoutputbasedontheloginfofromthepreviouscommandline(3iterationswith1,then2,then6concurrentsessions)shows:
也能够用shellscript(orabm_tps.sh)举行输入日记剖析.
$orabm_tps.shorabm.t92.log
ORACLE_SID=t92sess=1tps=182
ORACLE_SID=t92sess=2tps=360
ORACLE_SID=t92sess=6tps=364
Inthisexampletheserverwasa2CPUmodel-asaresult,2concurrentsessionsrunninginorabmareenoughtocompletelyutilizeallavailableCPUcapacity.
在这个例子中,Server有两个CPU,测试中两个并发足以损耗一切的CPU资本.
AdditionalsessionsshouldresultinthetotalTPSremainingunchanged,orevenfallingslightlyastheoperatingsystemperformscontextswitchestosharetheoverloadedCPUresourcebetweenmoreready-to-runsessionsthanavailableCPUs.
持续增添并发其实不会招致TPS值得增添,乃至有大概会下落.
（2）测试TPS值
上面我们来详细跑一下程序。在跑程序之前，要注重一下：后面的例子应当能够看到，在windows平台下运转orabmload时，设置了LOCAL变量，这个变量相称于UNIX平台下的ORACLE_SID，此次运转orabm程序，却有所分歧，见上面的运转日记：
E: emp>orabm1,2,6,1010000
ORACLE_SIDnotset
E: emp>setLOCAL=ccbver
E: emp>orabm1,2,6,1010000
ORACLE_SIDnotset
E: emp>setORACLE_SID=ccbver
E: emp>orabm1,2,6,1010000
---beginsess=1txn=10000ORACLE_SID=ccbverWedJan2611:03:452005
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=17tps=471sl=3918(49%)on=2483(31%)o
i=1598(20%)end=260105-10:05:58
---end-WedJan2611:04:092005
---beginsess=2txn=10000ORACLE_SID=ccbverWedJan2611:04:092005
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=17tps=471sl=3999(50%)on=2441(30.5%)
oi=1559(19.5%)end=260105-10:06:19
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=17tps=471sl=4025(50.3%)on=2396(30%)
oi=1578(19.7%)end=260105-10:06:19
---end-WedJan2611:04:312005
---beginsess=6txn=10000ORACLE_SID=ccbverWedJan2611:04:312005
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=43tps=186sl=4041(50.5%)on=2372(29.7
%)oi=1586(19.8%)end=260105-10:07:13
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=43tps=186sl=4017(50.2%)on=2404(30.1
%)oi=1578(19.7%)end=260105-10:07:13
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=42tps=190sl=3917(49%)on=2505(31.3%)
oi=1577(19.7%)end=260105-10:07:14
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=43tps=186sl=4016(50.2%)on=2394(29.9
%)oi=1589(19.9%)end=260105-10:07:14
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=43tps=186sl=4038(50.5%)on=2316(29%)
oi=1645(20.6%)end=260105-10:07:14
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=47tps=170sl=4011(50.1%)on=2380(29.8
%)oi=1608(20.1%)end=260105-10:07:15
---end-WedJan2611:05:262005
---beginsess=10txn=10000ORACLE_SID=ccbverWedJan2611:05:262005
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=72tps=111sl=3969(49.6%)on=2390(29.9
%)oi=1640(20.5%)end=260105-10:08:45
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=72tps=111sl=4061(50.8%)on=2407(30.1
%)oi=1531(19.1%)end=260105-10:08:45
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=73tps=110sl=3996(50%)on=2444(30.6%)
oi=1559(19.5%)end=260105-10:08:46
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=72tps=111sl=4089(51.1%)on=2334(29.2
%)oi=1576(19.7%)end=260105-10:08:46
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=71tps=113sl=3935(49.2%)on=2468(30.9
%)oi=1596(20%)end=260105-10:08:46
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=74tps=108sl=4015(50.2%)on=2380(29.8
%)oi=1604(20.1%)end=260105-10:08:47
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=72tps=111sl=4008(50.1%)on=2446(30.6
%)oi=1545(19.3%)end=260105-10:08:47
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=76tps=105sl=3939(49.2%)on=2454(30.7
%)oi=1606(20.1%)end=260105-10:08:48
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=76tps=105sl=4061(50.8%)on=2333(29.2
%)oi=1605(20.1%)end=260105-10:08:48
CCBVERtxn(all)=10000xn(sam)=7999t(sam)=77tps=104sl=3932(49.2%)on=2432(30.4
%)oi=1635(20.4%)end=260105-10:08:48
---end-WedJan2611:06:592005
本来还要设置ORACLE_SID变量！
我跑的这个例子是分四个案例：
第一个是1个并发session跑10000个事件；
第二个是2个并发session跑10000个事件；
第三个是6个并发session跑10000个事件；
第四个是10个并发session跑10000个事件。
测试程序运转停止后，会天生一个orabm.{ORACLE_SID}.log的文件，好比下面这个例子，天生的文件是orabm.ccbver.log，该文件是累加的，假如持续跑测试程序，其测试了局会累加到这个文件中。
（3）格局化输入
实在从下面的运转了局中已差未几能够看出TPS的值了，把并发session的TPS值相加便可。不外，orabm程序包中有一个格局化输入了局的SHELL剧本，能够看得加倍分明。
固然，得把日记文件上传到服务器上往运转，究竟是SHELL程序嘛。
看了局：
$./orabm_tps.shorabm.ccbver.log
ORACLE_SID=ccbversess=1tps=471
ORACLE_SID=ccbversess=2tps=942
ORACLE_SID=ccbversess=6tps=1104
ORACLE_SID=ccbversess=10tps=1089
能够看出，这台呆板的TPS值也许在1100摆布。
厥后把事件数变成100000，再跑了一下，了局也差未几，以下：
$./orabm_tps.shorabm.ccbver.log
ORACLE_SID=ccbversess=1tps=530
ORACLE_SID=ccbversess=2tps=979
ORACLE_SID=ccbversess=6tps=1106
ORACLE_SID=ccbversess=10tps=1097
如果互联网服务提供商，支撑数据的云服务，或它们之间任一点网络被堵塞或中断，他们就会遇到与数据延迟或应用程序故障有关的问题。如果问题发生在企业内部，解决方案提供商可以排除故障找出原因。 这就引发了对varchar和char效率讨论的老问题。到底如何分配varchar的数据，是否会出现大规模的碎片？ 换言之，只有在不断的失败中尝试成功，而关于失败的总结却是很少的 索引视图2k就有。但是2005对其效率作了一些改进但是schema.viewname的作用域真是太限制了它的应用面。还有一大堆的环境参数和种种限制都让人对它有点却步。 多走走一此相关论坛，多看一些实例开发，多交流0经验，没什么的，我也是刚学没多久!加油 作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！ 一直以来个人感觉SQLServer的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。（有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。） 多走走一此相关论坛，多看一些实例开发，多交流0经验，没什么的，我也是刚学没多久!加油 需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。
页:
[1]