MSSQL网页编程之关于shared pool的深切切磋(二)
支持AIX、FreeBSD、HP-UX、Linux、MacOS、NovellNetware、OpenBSD、OS/2Wrap、Solaris、Windows等多种操作系统关于sharedpool的深切切磋(二)
Sunday,2004-08-2221:23Eygle
link:
http://www.eygle.com/internal/shared_pool-2.htm
我们持续把后面的成绩睁开一下.
实在我们能够从数据库外部监控sharedpool的空间碎片情形.
这触及到一个外部视图x$ksmsp
X$KSMSP的称号寄义为:ernaltorageemoryManagementGAHea
个中每行都代表着sharedpool中的一个chunk
起首纪录一下测试情况：
SQL>select*fromv$version;
BANNER
----------------------------------------------------------------
Oracle9iEnterpriseEditionRelease9.2.0.3.0-Production
PL/SQLRelease9.2.0.3.0-Production
CORE9.2.0.3.0Production
TNSforLinux:Version9.2.0.3.0-Production
NLSRTLVersion9.2.0.3.0-Production
我们看一下x$ksmsp的布局:
SQL>descx$ksmspNameNull?Type-----------------------------------------------------------------------------ADDRRAW(4)INDXNUMBERINST_IDNUMBERKSMCHIDXNUMBERKSMCHDURNUMBERKSMCHCOMVARCHAR2(16)KSMCHPTRRAW(4)KSMCHSIZNUMBERKSMCHCLSVARCHAR2(8)KSMCHTYPNUMBERKSMCHPARRAW(4)
我们存眷以下几个字段:
KSMCHCOM是正文字段,每一个内存块被分派今后，正文会增加在该字段中.
x$ksmsp.ksmchsiz代表块巨细
x$ksmsp.ksmchcls列代表范例，次要有四类，申明以下:
free
Freechunks--不包括任何工具的chunk,能够不受限定的被分派.
recr
Recreatablechunks--包括能够被一时移出内存的工具,在必要的时分，这个工具能够
被从头创立.比方,很多存储共享sql代码的内存都是能够重修的.
freeabl
Freeablechunks--包括session周期或挪用的工具,随后能够被开释.这部份内存偶然候
能够全体或部分提早开释.可是注重，因为某些工具是两头历程发生的，这些工具不克不及
一时被移出内存(由于不成重修).
perm
Permanentmemorychunks--包括永世工具.一般不克不及自力开释.
我们能够经由过程查询x$ksmsp视图来考查sharedpool中存在的内存片的数目
不外注重:Oracle的某些版本(如:10.1.0.2)在某些平台上(如:HP-UXPA-RISC64-bit)查
询该视图大概招致过分的CPU耗用,这是因为bug引发的.
我们看一下测试:
初始启动数据库,x$ksmsp中存在2259个chunkSQL>selectcount(*)fromx$ksmsp;COUNT(*)----------2259实行查询:SQL>selectcount(*)fromdba_objects;COUNT(*)----------10491此时sharedpool中的chunk数目增添SQL>selectcount(*)fromx$ksmsp;COUNT(*)----------2358
这就是因为sharedpool中举行sql剖析，哀求空间，进而招致哀求free空间,分派、支解
从而发生了更多，更细碎的内存chunk
由此我们能够看出，假如数据库体系中存在大批的硬剖析，一直哀求分派free的shredpool内存
除必需的sharedpoollatch等合作外，还不成制止的会招致sharedpool中发生更多的内存碎片
(固然，在内存接纳时，你大概看到chunk数目削减的情形)
我们看以下测试:
起首从头启动数据库:SQL>startupforce;ORACLEinstancestarted.TotalSystemGlobalArea47256168bytesFixedSize451176bytesVariableSize29360128bytesDatabaseBuffers16777216bytesRedoBuffers667648bytesDatabasemounted.Databaseopened.创立一张一时表用以保留之前x$ksmsp的形态:SQL>CREATEGLOBALTEMPORARYTABLEe$ksmspONCOMMITPRESERVEROWSAS2SELECTa.ksmchcom,3SUM(a.CHUNK)CHUNK,4SUM(a.recr)recr,5SUM(a.freeabl)freeabl,6SUM(a.SUM)SUM7FROM(SELECTksmchcom,COUNT(ksmchcom)CHUNK,8DECODE(ksmchcls,recr,SUM(ksmchsiz),NULL)recr,9DECODE(ksmchcls,freeabl,SUM(ksmchsiz),NULL)freeabl,10SUM(ksmchsiz)SUM11FROMx$ksmspGROUPBYksmchcom,ksmchcls)a12where1=013GROUPBYa.ksmchcom;Tablecreated.保留以后sharedpool形态:SQL>INSERTINTOE$KSMSP2SELECTa.ksmchcom,3SUM(a.CHUNK)CHUNK,4SUM(a.recr)recr,5SUM(a.freeabl)freeabl,6SUM(a.SUM)SUM7FROM(SELECTksmchcom,COUNT(ksmchcom)CHUNK,8DECODE(ksmchcls,recr,SUM(ksmchsiz),NULL)recr,9DECODE(ksmchcls,freeabl,SUM(ksmchsiz),NULL)freeabl,10SUM(ksmchsiz)SUM11FROMx$ksmsp12GROUPBYksmchcom,ksmchcls)a13GROUPBYa.ksmchcom14/41rowscreated.实行查询:SQL>selectcount(*)fromdba_objects;COUNT(*)----------10492对照前后sharedpool内存分派的变更:SQL>selecta.ksmchcom,a.chunk,a.sum,b.chunk,b.sum,(a.chunk-b.chunk)c_diff,(a.sum-b.sum)s_diff2from3(SELECTa.ksmchcom,4SUM(a.CHUNK)CHUNK,5SUM(a.recr)recr,6SUM(a.freeabl)freeabl,7SUM(a.SUM)SUM8FROM(SELECTksmchcom,COUNT(ksmchcom)CHUNK,9DECODE(ksmchcls,recr,SUM(ksmchsiz),NULL)recr,10DECODE(ksmchcls,freeabl,SUM(ksmchsiz),NULL)freeabl,11SUM(ksmchsiz)SUM12FROMx$ksmsp13GROUPBYksmchcom,ksmchcls)a14GROUPBYa.ksmchcom)a,e$ksmspb15wherea.ksmchcom=b.ksmchcomand(a.chunk-b.chunk)016/KSMCHCOMCHUNKSUMCHUNKSUMC_DIFFS_DIFF----------------------------------------------------------------------------KGLhandles31310208030298416113664KGLSheap27436575227036042445328KQRPO389198548377192580125968freememory9322920769023813043-89228librarycache10053982849653814164016868sqlarea28754745226949005218574006rowsselected.
我们复杂剖析一下以上了局:
起首freememory的巨细削减了89228(增添到别的五个组件中),这申明sql剖析存储占用了必定的内存空间
而chunk从90增添为93，这申明内存碎片增添了.
鄙人面的部分中,我会动手先容一下KGLhandles,KGLSheap这两个十分主要的sharedpool中的内存布局.
线上或者测试环境经常出现的误操作总是让DBA同学那么闹心。 如果处理少量数据,比如几百条记录的数据,我不知道这两种情况哪个效率更高,如果处理大量数据呢?比如有表中有20万条记录. 这就引发了对varchar和char效率讨论的老问题。到底如何分配varchar的数据，是否会出现大规模的碎片？ 但换公司用MSSQL2K感觉自己好像根本就不了解MSSQL。什么DTS触发器以前根本没用过。 大家注意一点。如下面的例子： 其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史，而且SQLServer2005的row_number比Oracle的更先进。因为它把Orderby集成到了一起，不用像Oracle那样还要用子查询进行封装。 还不是性能有问题！否则面向对象的数据库早就实现了！建议使用CLR的地方一般是和应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法，并且用到了大量的指针和高级数据模型。 如果，某一版本可以提供强大的并发响应，但是没有Oracle的相应版本稳定，或者价格较贵，那么，它就是不适合的。
页:
[1]