《Oracle执行计划详细解读》课件

Oracle执行计划解读

培训教师：谢高兴

时间：2006.4.27

BEGINOracle执行计划解读培训教师：谢高兴时间SQL执行过程1,解析SQL2,执行3,显示结果集4,转换字段数据检查安全性检查SQL语法查询重新书写创建执行计划捆绑执行计划执行执行计划读取结果集SQL执行过程1,解析SQL2,执行3,显示结果集4,转换字执行计划执行计划:Oracle内部的机器级代码,决定如何访问存储器，得到需要的结果集。执行计划的主要内容：访问方式，访问顺序。执行计划执行计划:Oracle内部的机器级代码,决定得到执行计划的方式1.Explain（解释）2.Autotrace(自动跟踪)3.其他工具基本格式：explain

plan

set

STATEMENT_ID='testplan'ForSelect…..(Select,insert,update等数据操作语句均可)基本使用方式：SQL>setautotraceon;(SQLPLUS中使用)得到执行计划的方式1.Explain（解释）2.Autotr准备：创建Plan_table表createtableplan_table(statement_idvarchar2(30),timestampdate,remarksvarchar2(80),operationvarchar2(30),optionsvarchar2(30),object_nodevarchar2(128),object_ownervarchar2(30),object_namevarchar2(30),object_instanceinteger,object_typevarchar2(30),optimizervarchar2(255),search_columnsinteger,idinteger,parent_idinteger,positioninteger,costinteger,cardinalityinteger,bytesinteger,other_tagvarchar2(255),partition_startvarchar2(255),partition_stopvarchar2(255),partition_idinteger,otherlong,distributionvarchar2(30));准备：创建Plan_table表createtablepAUTOTRACESQL>setautotraceon;SQL>select*fromdual;D-XExecutionPlan----------------------------------------------------------0SELECTSTATEMENTOptimizer=CHOOSE10TABLEACCESS(FULL)OF'DUAL'Statistics----------------------------------------------------------0recursivecalls0dbblockgets3consistentgets0physicalreads0redosize372bytessentviaSQL*Nettoclient511bytesreceivedviaSQL*Netfromclient2SQL*Netroundtripsto/fromclient0sorts(memory)0sorts(disk)1rowsprocessedSQL>统计信息执行计划结果数据AUTOTRACESQL>setautotraceo使用Explain1,删除上次解析数据2,执行解析delete

from

plan_table

where

STATEMENT_ID='testplan';explainplansetSTATEMENT_ID='testplan'forselect*fromdual;3,显示执行计划selectlpad('',5*(level-1))||operationoperation,options,object_name,cost,positionfromplan_tablestartwithid=0andSTATEMENT_ID='testplan'connectbypriorid=parent_id;使用Explain1,删除上次解析数据2,执行解析delet第一个执行计划对应SQL语句：select*fromdual;执行计划:第一个执行计划对应SQL语句：select*from怎样看执行计划执行计划其实是一棵树，层次最深的最先执行，层次相同，上面的先执行。显示时已经按照层次缩进，因此从最里面的看起。最后一组就是驱动表。例：驱动表

selectcount(*)

from

prm_adjustpricemain,prm_adjustprice_bdetail

wheremain.cadjpriceid=detail.CADJPRICEIDandmain.DADJPRICEDATE>=

'2004-04-18'

anddetail.CINVENTORYIDin

(selectpk_invmandocfrom

bd_invmandoc

where

bd_invmandoc.SEALFLAG='N');怎样看执行计划执行计划其实是一棵树，层次最深的最先执行，层次表访问方式散列获取：全表扫描：ROWID访问：读取表的每一条记录，顺序地从第一个数据块开始知道结尾标志。ROWID包含记录的数据块号和数据块中的偏移量。因此它是获取一条记录的最快的方法。使用散列算法得到符号关键值的来确定记录所在的数据块。它能减少数据读入量，但是存在重新定位记录的问题，只能在静态表中使用。表访问方式散列获取：全表扫描：ROWID访问：读取表的每一条索引访问方式快速全索引扫描：索引扫描：从索引中读取一个或多个ROWID。索引值通常按照升序方式扫描。有些查询可以不扫描表只扫描索引就能得到期望的查询结果。所有查询字段都在索引中指定;查询返回大于索引所有记录数的10%;进行Count(*)操作。Oracle索引索引访问方式快速全索引扫描：索引扫描：从索引中读取一个或多个表连接操作11,嵌套循环连接-NESTEDLOOP两个表，一个小的内部表和一个外部表一般情况下速度较快，特别是中间结果集非常小的情况下速度快。外部表索引内部表外部表表连接操作11,嵌套循环连接-NESTEDLOOP两个表，表连接操作22,散列连接-HASHJOIN两个表，一个较小的驱动表和一个大表中间结果集非常大的情况下速度较快。Hash_Area_SizeRAM驱动表大表散列访问ROWIDRAM溢出使用临时表空间表连接操作22,散列连接-HASHJOIN两个表，一个较小表连接操作33,排序合并连接-MERGEJOIN两个表都使用全表扫描，分别进行排序，然后再合并成查询的结果集。极少情况适合。只有包含两个表的决大多数记录的查询适合。A表全表扫描B表全表扫描A表排序B表排序输出结果集合并表连接操作33,排序合并连接-MERGEJOIN两个表都使Step1:全表扫描对查询影响最大的就是全表扫描-TableAccessFull.计执行划中所有的全表扫描都值得怀疑.除非是数据量非常小的表可能引起全表扫描的原因：表上没有索引没有WHERE条件对索引字段使用了内置函数，如To(Dcredate)=‘2005-02-15’Like操作符而参数以“%”开始表记录非常少Step1:全表扫描对查询影响最大的就是全表扫描-TableStep2:驱动表－1驱动表最内层的驱动表是不是能在执行过程中得到最小的中间数据集？例如：查询销售订单明细，涉及三个表，订单主表，订单附表,存货基本档案表。条件中包含：订单日期等于某天和存货编码等于某个值。方案一：如果以订单主表为驱动表，可以使用日期上的索引过滤出所有的当天的订单，然后关联附表，最后再关联到存货档案表，过滤出相应存货。订单附表订单主表存货档案表日期索引主表PK索引存货主键索引Step2:驱动表－1驱动表最内层的驱动表是不是能在执行过程Step2:驱动表－2方案二：如果以存货档案为驱动表，可以使用编码上的索引过滤出所有存货，然后关联订单附表，得到所有存货符合条件的订单附表记录，最后再用订单附表上的主表主键关联主表，判断订单主表上的日期是否符合条件，最后得到结果集。订单附表订单主表存货档案表编码索引存货ID索引主表主键索引结论：如果按照存货去过滤，得到订单附表上符合条件记录会较少，认为方案二更优。Step2:驱动表－2方案二：如果以存货档案为驱动表，可以使Step3:不该建的索引错误索引：对于只有少数一个可能值的列，不应该建索引。如单据状态，单据主表上的部门人员，附表上的仓库，库存组织等。索引不是越多越好。数据的插入，删除和修改都需要维护索引表，也是有成本的。建议建索引的列。所有可能用做查询条件的日期列,客户列；附表上的主表主键列，存货列，来源单据列；基本档案的编码列等。Step3:不该建的索引错误索引：对于只有少数一个可能值的列Step4:复合索引列顺序对复合索引，应将重复值少的列作为先导列例如订单附表上有来源单据类型(srctype)和来源单据ID(srcid),建立索引的顺序应该是srcid,srctype.如果将srctype列作为先导列，可能在查询时，没有srcid的条件也使用这个索引扫描，其结果是扫描了大半个表，比全表扫描还慢。Step4:复合索引列顺序对复合索引，应将重复值少的列作为先Step5:非最优索引对一个表存在多个索引的列作为条件，解析中可能使用了非最优索引使用提示，指定使用某个索引(存在SQL兼容问题，不推荐)将索引尽可能多的使用条件使用内置函数或运算使不想使用的条件列失效。整型数据列+0字符型加trim函数例如：在进行调拨的时候需要判断这个仓库中此存货不存在没有记帐的出库单

Selectcount(*)fromXXXwherepk_inv=:1andstatus=0这个查询会用到存货索引，但是速度还是慢。但是仔细分析会发现，其实实际运行中没记帐的出库单比例很少，如果在存货索引上再加上状态列，可以过滤更少的数据，速度将大大提高。Step5:非最优索引对一个表存在多个索引的列作为条件，解析Step6:数据非均匀分布对于某些SQL可能存在时快时慢，这个即可能是数据的分布不均导致举例：做销售订单时，去判断此客户是否存在未结算订单。SQL语句：这个语句在做多数客户的时候没有感觉，但是在做某一两个客户时速度奇慢，查其执行计划，也使用了主表上的客户索引。Select..Fromso_order,so_order_b,..whereso_order.pk=so_order_b.pkandccustomerid=:1and……..最后发现情况是这样的：企业是做批发业务的，政策法规上不允许直接销售给个人，内部职工需要购买时都是按照统一个特定的客户开票，因此数据库中数据严重不均，此客户的订单数量大于总数的10%。一进行这样的查询就严重占用数据库资源，导致系统相应速度慢。解决的办法：这种行为都是现金交易根本不需要进行检查，查询的结果永远是空。程序绕过这个检查就行了。Step6:数据非均匀分布对于某些SQL可能存在时快时慢，这Step7:EXIST查询基本格式例：selectcount(*)

from

prm_adjustpricemain,prm_adjustprice_bdetail

wheremain.cadjpriceid=detail.CADJPRICEIDandmain.cadjpriceidin

('1','2')

and

exists

(select

*

from

bd_invmandoc

where

bd_invmandoc.SEALFLAG='N‘

anddetail.CINVENTORYID=bd_invmandoc.pk_invmandoc);不要将主表的其他条件写在子查询中，这样可能使外层查询没有条件而进行全表扫描。如果想按照子查询中的表作为驱动表进行查询，需要改造成IN子句。Select..From主表where主表条件andexists(Select*from子表where子表条件and主表关联字段＝子表PK)Step7:EXIST查询基本格式例：selectcoStep8:IN查询基本格式例：

selectcount(*)

from

prm_adjustpricemain,prm_adjustprice_bdetail

wheremain.cadjpriceid=detail.CADJPRICEIDandmain.cadjpriceidin

('1','2')

anddetail.CINVENTORYIDin

(selectpk_invmandoc

from

bd_invmandoc

where

bd_invmandoc.SEALFLAG='N');如果不是想按照子查询中的表作为驱动表进行查询，建议改造成EXIST子句，特别是自查询存在较多重复数据时。Select..From主表where主表条件and主表关联字段in(Select子表PKfrom子表where子表条件)Step8:IN查询基本格式例：selectcount(Step9:NOTIN尽量不要使用NOTINNOTIN都可以改造成NOTEXISTSNOTIN中子查询如果对某个记录返回空，整个结果集都会为空Step9:NOTIN尽量不要使用NOTINNOTINStep10:视图视图不要存在视图套视图情况视图中不要使用Distinct视图中希望作为条件的关联列和结果列，不要进行运算。如月份的加减。不要使用条件太复杂的视图。Step10:视图视图不要存在视图套视图情况视图中不要使用DStepOver当所有的调整都无效时：那就是算法的问题！StepOver当所有的调整都无效时：那就是算法的问题！实例采购计划查询时，先查询出采购计划，然后查询执行数据，再追加到采购计划数据中。查询执行数据SQL如下：

select

planbill.cplanbid,sum(

po_planexe.npraysnum),sum……from

(SELECTpo_plan_b.cplanbid,po_plan_h.pk_corp,po_plan_b.cobj1id,po_plan_b.cobj2id,po_plan_b.cobj3id,po_plan_h.dstartdate,po_plan_h.denddate,aa.invclasscodeFROMpo_plan_h,po_plan_b,bd_invclaawherepo_plan_h.cplanhid=po_plan_b.cplanhidandpo_plan_h.dr=0andpo_plan_b.dr=0andaa.pk_invcl(+)=po_plan_b.cobj2idandpo_plan_h.dprocessdate<='2005-04-19')planbill,

po_planexe,

bd_invclinvclass

where

po_planexe.pk_corp=planbill.pk_corpand

po_planexe.dr=

0

and

(

po_planexe.cdeptid=planbill.cobj1idorplanbill.cobj1idis

null)

and

(

po_planexe.cinvmandocid=planbill.cobj3idorplanbill.cobj3idis

null

)

andinvclass.pk_invcl=

po_planexe.cinvclassid

and

((invclass.invclasscodelikeplanbill.invclasscode||'%'

andplanbill.invclasscodeis

not

null

)

orplanbill.cobj2idis

null

)

and

po_planexe.dstartdate>=planbill.dstartdate

and

po_planexe.denddate<=planbill.denddate

group

byplanbill.cplanbid;实例采购计划查询时，先查询出采购计划，然后查询执行数据，再追实例-续1各表数据关系如下：采购计划主表采购计划子表执行情况表cobjid1cobjid2cobjid3部门ID存货分类ID存货ID存货分类表实例-续1各表数据关系如下：采购计划主表采购计划子表执行情况实例-续2查看执行计划如下：－成本优化器模式下的计划，全是全表扫描实例-续2查看执行计划如下：－成本优化器模式下的计划，全是全实例-续3第一反应：加规则提示select

/*+rule*/planbill.cplanbid,sum…….好像有提高，只有一个FullScan了。但是这个计划执行起来更差，原因是：内部驱动表bd_invcl到执行计划表没有用到任何条件，结果集是两个表的完全关联实例-续3第一反应：加规则提示实例-续4看看内部的子查询情况SELECT

po_plan_b.cplanbid,…,aa.invclasscode

FROM

po_plan_h,

po_plan_b,

bd_invclaa

where

po_plan_h.cplanhid=

po_plan_b.cplanhidand

po_plan_h.dr=

0

and

po_plan_b.dr=

0

andaa.pk_invcl(

+

)

=

po_plan_b.cobj2id

and

po_plan_h.dprocessdate<=

'2005-04-19'

实例-续4看看内部的子查询情况实例-续5发现计划表上相应日期列没有索引。子表上的主表字段也没有索引。加上索引。CREATEINDEXPO_PLAN_H_IDX1ONPO_PLAN_H(DPROCESSDATE);CREATEINDEXIDX_PO_PLAN_B_1ONPO_PLAN_B(CPLANHID);内部子查询已经没有太大问题。但是整个查询仍然没有起色。实例-续5发现计划表上相应日期列没有索引。子表上的主表字段也实例-续6在内部也都用上了索引，但是效果仍不好，速度照样慢.看到执行表使用的索引是I_MPP_PLANEXEX_4索引列（DSTARTDATE,DENDDATE）-删除先关联了执行表，然后再关联最外层的存货分类表，对数据没有起到过滤作用实例-续6在内部也都用上了索引，但是效果仍不好，速度照样慢.实例-续7仔细分析一下外围关联条件：

where

po_planexe.pk_corp=planbill.pk_corpand

po_planexe.dr=

0

and

(

po_planexe.cdeptid=planbill.cobj1idorplanbill.cobj1idis

null)

and

(

po_planexe.cinvmandocid=planbill.cobj3idorplanbill.cobj3idis

null

)

andinvclass.pk_invcl=

po_planexe.cinvclassid

and

((invclass.invclasscodelikeplanbill.invclasscode||'%'

andplanbill.invclasscodeis

not

null

)

orplanbill.cobj2idis

null

)

and

po_planexe.dstartdate>=planbill.dstartdate

and

po_planexe.denddate<=planbill.denddate这里的po_planexe.cdeptid=planbill.cobj1idorplanbill.cobj1idis

null和

po_planexe.cinvmandocid=planbill.cobj3idorplanbill.cobj3idis

null是无法使用执行表上的部门和存货索引。（部门上单独加索引？？？）采购计划表上有一个逻辑是：存货和存货分类两个列是互斥的，且必有一个不为空.我们可以使用这个逻辑将条件分开，而不是写在一起。and((

po_planexe.cinvmandocid=planbill.cobj3idandplanbill.cobj2idis

null

)or(po_planexe.cinvclassid=invclass.pk_invcl…..))但是，对存货不需要存货分类表，而对存货分类因为可以不定义到最末级，因此必须关联两次存货分类表。最后可行的解决办法是将两个查询UNION达到解决问题实例-续7仔细分析一下外围关联条件：实例-续8先按照计划表上有存货的进行查询select

/*+rule*/planbill.cplanbid,…..from

(

SELECT

po_plan_b.cplanbid,

po_plan_h.pk_corp,

FROM

po_plan_h,

po_plan_b

where

po_plan_h.cplanhid=

po_plan_b.cplanhidand

po_plan_h.dr=

0

and

po_plan_b.dr=

0

and

po_plan_h.dprocessdate<=

'2005-04-19'

)planbill,

po_planexe

where

po_planexe.pk_corp=planbill.pk_corpand

po_planexe.dr=

0

and

(

po_planexe.cdeptid=planbill.cobj1idorplanbill.cobj1idis

null)

and

po_planexe.cinvmandocid=planbill.cobj3idandplanbill.cobj2idis

null

and

po_planexe.dstartdate>=planbill.dstartdate

and

po_planexe.denddate<=planbill.denddate

group

byplanbill.cplanbid实例-续8先按照计划表上有存货的进行查询实例-续9执行计划如下，看到已经能得到比较优化的结果。查询时间1秒（3305行）实例-续9执行计划如下，看到已经能得到比较优化的结果。查询时实例-续10按照存货分类查询的呢？按照编码进行like查询已证明比较慢。那么我们可以考虑建立一个存货分类上下级关系的完全对照表，使用对照表关联。CREATE

TABLE

temp_inv2up(pkid NUMBER(10)

NOT

NULL,//主键ID用处不大pk_invcl CHAR(20)

NOT

NULL,//子分类pk_upinvcl CHAR(20)

NOT

NULL,//上级分类CONSTRAINTPK_temp_inv2upPRIMARY

KEY

(pkid));CREATE

INDEXtemp_inv2up_idxinvONUAP0318.TEMP_INV2UP(PK_INVCL);CREATE

INDEXTEMP_INV_UPIDXON

TEMP_INV2UP(PK_UPINVCL);create

sequencetemp_invseqstart

with

1;//生成主键ID用//按照分类编码关联出上下级对照表数据insert

into

temp_inv2up(pkid,pk_invcl, pk_upinvcl)

selecttemp_invseq.nextval,bas.pk_invcl,up.pk_invclfrom

bd_invclbas,bd_invclup

wherebas.invclasscodelikeup.invclasscode||'%';实例-续10按照存货分类查询的呢？按照编码进行like查询已实例-续11按照存货分类查询:select

/*+rule*/planbill.cplanbid,sum..

from

(

SELECT

po_plan_b.cplanbid,

po_plan_h.pk_corp,

…

FROM

po_plan_h,

po_plan_b

where

po_plan_h.cplanhid=

po_plan_b.cplanhidand

po_plan_h.dr=

0

and

po_plan_b.dr=

0

and

po_plan_h.dprocessdate<=

'2005-04-19'

)planbill,

po_planexe,

temp_inv2up

where

po_planexe.pk_corp=planbill.pk_corpand

po_planexe.dr=

0

and

(

po_planexe.cdeptid=planbill.cobj1idorplanbill.cobj1idis

null)

andplanbill.cobj3idis

null

and

temp_inv2up.pk_invcl=

po_planexe.cinvclassid

and

temp_inv2up.PK_UPINVCL=planbill.COBJ2ID

and

po_planexe.dstartdate>=planbill.dstartdate

and

po_planexe.denddate<=planbill.denddate

group

byplanbill.cplanbid;实例-续11按照存货分类查询:实例-续12按照存货分类查询的执行计划:效果不错。实例-续12按照存货分类查询的执行计划:效果不错。实例-成果按照这种方式优化后，分别union前分别加rule提示，查询时间小于2秒。再去掉规则提示，让Oracle按照成本优化器解析，执行时间0.297秒。代码业务逻辑并没有改变，执行结果也相同。！！！OVER!实例-成果按照这种方式优化后，分别union前分别加rule￥1111111111111111111111111111111222222222222222222222222222222222222222222222222222222223333333333333333333333333333333333333333333333333333333333333333333344444＄§¦β↓×√㎜ɡ©≥≧ɑ←‰®↓←≠¥θ￥®÷㎝½¼￥＄§¦β↓×√㎜②￥◎…ɡ©≥≧ɑ←‰®ɡ©≥≧￥◎…ɡ©≥≧ɑ←‰®ɡ©≥≧－￥¾½¼￥＄§¦β↓×√㎜½¼￥＄§¦β↓×√㎜↓←≠¥θ￥®÷㎝②￥◎…ɡ©≥≧ɑ←‰®½¼￥＄§¦β↓×√㎜ɡ©≥≧ɑ←‰®↓←≠¥θ￥®÷㎝½¼￥＄§¦β↓×√㎜②￥◎…ɡ©≥≧ɑ←‰®ɡ©≥≧￥◎…ɡ©≥≧ɑ←‰®ɡ©≥≧－￥¾½¼￥＄§¦β↓×√㎜½¼￥＄§¦β↓×√㎜≧ɑ←‰ɡ©≥←‰®½¼↓←≠¥θ￥®÷㎝②￥◎…ɡ©≥≧ɑ←‰®½¼￥＄§¦β↓×√㎜ɡ©≥≧ɑ←‰®↓←≠¥θ￥®÷㎝½¼￥＄§¦β↓×√㎜②￥◎…ɡ©≥≧ɑ←‰®ɡ©≥≧￥◎…ɡ©≥≧ɑ←‰®ɡ©≥≧－￥¾½¼￥＄§¦β↓×√㎜½¼￥＄§¦β↓×√㎜￥＄§¦β↓×√㎜½¼￥＄§¦β↓×√㎜￥＄§¦β↓×√㎜½¼￥＄§¦β↓×√㎜↓×√㎜↓←②￥←‰®½¼←‰®½¼←‰®½¼←‰®½¼←‰®½¼←‰®½↓←≠¥θ￥®÷㎝②￥◎…ɡ©≥≧ɑ←‰®½¼￥＄§¦β↓×√㎜ɡ©≥≧ɑ←‰®↓←≠¥θ￥®÷㎝½¼￥＄§¦β↓×√㎜②￥◎…ɡ©≥≧ɑ←‰®ɡ©≥≧￥◎…ɡ©≥≧ɑ←‰®ɡ©≥≧－￥¾½¼￥＄§¦β↓×√㎜½¼￥＄§¦β↓×√㎜￥＄§¦β↓×√㎜½¼￥＄§¦β↓×√㎜￥＄§¦β↓×√㎜½¼￥＄§¦β↓×√㎜↓×√㎜↓←②￥←‰®½¼←‰®½¼←‰®½¼←‰®½¼←‰®½¼←‰®½¼↓←≠¥θ￥®÷㎝②￥◎…ɡ©≥≧ɑ←‰®½¼￥＄§¦β↓×√㎜ɡ©≥≧ɑ←‰®↓←≠¥θ￥®÷㎝½¼￥＄§¦β↓×√㎜②￥◎…ɡ©≥≧ɑ←‰®ɡ©≥≧￥◎…ɡ©≥≧ɑ←‰®ɡ©≥≧－￥¾½¼￥＄§¦β↓×√㎜½¼￥＄§¦β↓×√㎜￥＄§¦β↓×√㎜½¼￥＄§¦β↓×√请删除后使用，谢谢请删除后使用，谢谢请删除后使用，谢谢请删除后使用，谢谢请删除后使用，谢谢请删除后使用，谢谢请删除后使用，谢谢请删除后使用，谢谢￥1111111111111111111111111111141dskdfibsdkbfndsldkhslhokdhsodhvkskdnvklsoifyoishigibivbisbdvibsidbvoisbvoibsoivbiosbviohsivhkjshivuhiuhfiugruysdbvslkdbvlkbokbvkozbxkjcbjkbvjkbkjvbkjccbvkjbcxzvhoisdbvibsdivbisdvknflksnlkvnsodskdfibsdkbfndsldkhslhokdhsodhvkskdnvklsoifyoishigibivbisbdvibsidbvoisbvoibsoivbiosbviohsivhkjshivuhiuhfiugruysdbvslkdbvlkbokbvkozbxkjcbjkbvjkbkjvbkjccbvkjbcxzvhoisdbvibsdivbisdvknflksnlkvnsodskdfibsdkbfndsldkhslhokdhsodhvkskdnvklsoifyoishigibivbisbdvibsidbvoisbvoibsoivbiosbviohsivhkjshivuhiuhfiugruysdbvslkdbvlkbokbvkozbxkjcbjkbvjkbkjvbkjccbvkjbcxzvhoisdbvibsdivbisdvknflksnlkvnsodskdfibsdkbfndsldkhslhokdhsodhvkskdnvklsoifyoishigibivbisbdvibsidbvoisbvoibsoivbiosbviohsivhkjshivuhiuhfiugruysdbvslkdbvlkbokbvkozbxkjcbjkbvjkbkjvbkjccbvkjbcxzvhoisdbvibsdivbisdvknflksnlkvnsodskdfibsdkbfndsldkhslhokdhsodhvkskdnvklsoifyoishigibivbisbdvibsidbvoisbvoibsoivbiosbviohsivhkjshivuhiuhfiugruysdbvslkdbvlkbokbvkozbxkjcbjkbvjkbkjvbkjccbvkjbcxzvhoisdbvibsdivbisdvknflksnlkvnsoxkbvoxlknvlkxncklvhsiudlknvknsklvnlksnvkjbsijvbksjvkskvbkjsbdvkklsvlnkclnvlknczxklnvlksndkvnksdvlkslkvlkczvlknspivhsojvposvnsknvlksnklhissoiyuregohkenklfvnosihvlmsdlvvnlknxclkvlkscnvlksdnkjvbsdkvklsndlkhsdoihfoisdnlnslkbvoishdovnlkznkjvgsoidnvposdnklvbkjsdhgoivhsonvlsnvhoisnvlnskvoisnvnsdlkhviusshoinvpnksgivhnosnvlkbxslkvnlkbxkvblkcxnvlknxlkvnoidskdfibsdkbfndsldkhslhokdhsodh42dsfdbsy384y982ythb3oibt4oy39y409705923y09y53b2lkboi2y58wy0ehtoibwoify98wy049ywh4b3oiut89u983yf9ivh98y98sv98hv98ys9f698y9v698yv98x98tb98fyd98gyd98h98ds98nt98d8genklgb4klebtlkb5ktkeirh893y89ey698vhkrnelkhgi8eyokbnkdhf98hodfhxvy78fd678t9fdu90gys98y9shihixyv78dfhvifndovhf9f8yv9onvkobkwkjfegiudsfdbsy384y982ythb3oibt4oy39y409705923y09y53b2lkboi2y58wy0ehtoibwoify98wy049ywh4b3oiut89u983yf9ivh98y98sv98hv98ys9f698y9v698yv98x98tb98fyd98gyd98h98ds98nt98d8genklgb4klebtlkb5ktkeirh893y89ey698vhkrnelkhgi8eyokbnkdhf98hodfhxvy78fd678t9fdu90gys98y9shihixyv78dfhvifndovhf9f8yv9onvkobkwkjfegiudsfdbsy384y982ythb3oibt4oy39y409705923y09y53b2lkboi2y58wy0ehtoibwoify98wy049ywh4b3oiut89u983yf9ivh98y98sv98hv98ys9f698y9v698yv98x98tb98fyd98gyd98h98ds98nt98d8gendsfdbsy384y982ythb3oibt4oy39y44345643453425gvmkbmvbmcf45643453425gvmkbmvbmcf45643453425gvmkbmvbmcf45643453425gvmkbmvbmcffgjhghkggggggggggggggggggg45643453425gvmkbmvbmcf45643453425gvmkbmvbmcfgkkkkkkkkkkkkkkkk45643453425gvmkbmvbmcf45643453425gvmkbmvbmcf45643453425gvmkbmvbmcf45643453425gvmkbmvbmcf45643453425gvmkbmvbmcfgkkkkkkkkkkkkkkkkkkkk45643453425gvmkbmvbmcf45643453425gvmkbmvbmcf45643453425gvmkbmvbmcf45643453425gvmkbmvbmcf45643453425gvmkbmvbmcf4564345344dsfdbsy384y982ythb3oibt4oy39y409705923y09y53b2lkboi2y58wy0ehtoibwoify98wy049ywh4b3oiut89u983yf9ivh98y98sv98hv98ys9f698y9v698yv98x98tb98fyd98gyd98h98ds98nt98d8genklgb4klebtlkb5ktkeirh893y89ey698vhkrnelkhgi8eyokbnkdhf98hodfhxvy78fd678t9fdu90gys98y9shihixyv78dfhvifndovhf9f8yv9onvkobkwkjfegiudsfdbsy384y982ythb3oibt4oy39y409705923y