数据库系统概念全套配套课件PPT ch24.ppt 48页

'Chapter24:AdvancedApplicationDevelopment Chapter24:AdvancedApplicationDevelopmentPerformanceTuningPerformanceBenchmarksStandardizationE-CommerceLegacySystems PerformanceTuningAdjustingvariousparametersanddesignchoicestoimprovesystemperformanceforaspecificapplication.Tuningisbestdonebyidentifyingbottlenecks,andeliminatingthem.Cantuneadatabasesystemat3levels:Hardware--e.g.,adddiskstospeedupI/O,addmemorytoincreasebufferhits,movetoafasterprocessor.Databasesystemparameters--e.g.,setbuffersizetoavoidpagingofbuffer,setcheckpointingintervalstolimitlogsize.Systemmayhaveautomatictuning.Higherleveldatabasedesign,suchastheschema,indicesandtransactions(morelater) BottlenecksPerformanceofmostsystems(atleastbeforetheyaretuned)usuallylimitedbyperformanceofoneorafewcomponents:thesearecalledbottlenecksE.g.,80%ofthecodemaytakeup20%oftimeand20%ofcodetakesup80%oftimeWorthspendingmosttimeon20%ofcodethattake80%oftimeBottlenecksmaybeinhardware(e.g.,disksareverybusy,CPUisidle),orinsoftwareRemovingonebottleneckoftenexposesanotherDe-bottleneckingconsistsofrepeatedlyfindingbottlenecks,andremovingthemThisisaheuristic IdentifyingBottlenecksTransactionsrequestasequenceofservicesE.g.,CPU,DiskI/O,locksWithconcurrenttransactions,transactionsmayhavetowaitforarequestedservicewhileothertransactionsarebeingservedCanmodeldatabaseasaqueueingsystemwithaqueueforeachserviceTransactionsrepeatedlydothefollowingrequestaservice,waitinqueuefortheservice,andgetservicedBottlenecksinadatabasesystemtypicallyshowupasveryhighutilizations(andcorrespondingly,verylongqueues)ofaparticularserviceE.g.,diskvs.CPUutilization100%utilizationleadstoverylongwaitingtime:Ruleofthumb:designsystemforabout70%utilizationatpeakloadutilizationover90%shouldbeavoided QueuesInADatabaseSystem TunableParametersTuningofhardwareTuningofschemaTuningofindicesTuningofmaterializedviewsTuningoftransactions TuningofHardwareEvenwell-tunedtransactionstypicallyrequireafewI/OoperationsTypicaldisksupportsabout100randomI/OoperationspersecondSupposeeachtransactionrequiresjust2randomI/Ooperations.Thentosupportntransactionspersecond,weneedtostripedataacrossn/50disks(ignoringskew)NumberofI/OoperationspertransactioncanbereducedbykeepingmoredatainmemoryIfalldataisinmemory,I/OneededonlyforwritesKeepingfrequentlyuseddatainmemoryreducesdiskaccesses,reducingnumberofdisksrequired,buthasamemorycost HardwareTuning:Five-MinuteRuleQuestion:whichdatatokeepinmemory:Ifapageisaccessedntimespersecond,keepingitinmemorysavesn*price-per-disk-driveaccesses-per-second-per-diskCostofkeepingpageinmemoryprice-per-MB-of-memoryages-per-MB-of-memoryBreak-evenpoint:valueofnforwhichabovecostsareequalIfaccessesaremorethensavingisgreaterthancostSolvingaboveequationwithcurrentdiskandmemorypricesleadsto:5-minuterule:ifapagethatisrandomlyaccessedisusedmorefrequentlythanoncein5minutesitshouldbekeptinmemory(bybuyingsufficientmemory!) HardwareTuning:One-MinuteRuleForsequentiallyaccesseddata,morepagescanbereadpersecond.Assumingsequentialreadsof1MBofdataatatime:1-minuterule:sequentiallyaccesseddatathatisaccessedonceormoreinaminuteshouldbekeptinmemoryPricesofdiskandmemoryhavechangedgreatlyovertheyears,buttheratioshavenotchangedmuchSorulesremainas5minuteand1minuterules,not1houror1secondrules! HardwareTuning:ChoiceofRAIDLevelTouseRAID1orRAID5?DependsonratioofreadsandwritesRAID5requires2blockreadsand2blockwritestowriteoutonedatablockIfanapplicationrequiresrreadsandwwritespersecondRAID1requiresr+2wI/OoperationspersecondRAID5requires:r+4wI/OoperationspersecondForreasonablylargerandw,thisrequireslotsofdiskstohandleworkloadRAID5mayrequiremoredisksthanRAID1tohandleload!ApparentsavingofnumberofdisksbyRAID5(byusingparity,asopposedtothemirroringdonebyRAID1)maybeillusory!Thumbrule:RAID5isfinewhenwritesarerareanddataisverylarge,butRAID1ispreferableotherwiseIfyouneedmorediskstohandleI/Oload,justmirrorthemsincediskcapacitiesthesedaysareenormous! TuningtheDatabaseDesignSchematuningVerticallypartitionrelationstoisolatethedatathatisaccessedmostoften--onlyfetchneededinformation.E.g.,splitaccountintotwo,(account-number,branch-name)and(account-number,balance).Branch-nameneednotbefetchedunlessrequiredImproveperformancebystoringadenormalizedrelationE.g.,storejoinofaccountanddepositor;branch-nameandbalanceinformationisrepeatedforeachholderofanaccount,butjoinneednotbecomputedrepeatedly.Pricepaid:morespaceandmoreworkforprogrammertokeeprelationconsistentonupdatesBettertousematerializedviews(moreonthislater..)ClustertogetheronthesamediskpagerecordsthatwouldmatchinafrequentlyrequiredjoinComputejoinveryefficientlywhenrequired. TuningtheDatabaseDesign(Cont.)IndextuningCreateappropriateindicestospeedupslowqueries/updatesSpeedupslowupdatesbyremovingexcessindices(tradeoffbetweenqueriesandupdates)Choosetypeofindex(B-tree/hash)appropriateformostfrequenttypesofqueries.ChoosewhichindextomakeclusteredIndextuningwizardslookatpasthistoryofqueriesandupdates(theworkload)andrecommendwhichindiceswouldbebestfortheworkload TuningtheDatabaseDesign(Cont.)MaterializedViewsMaterializedviewscanhelpspeedupcertainqueriesParticularlyaggregatequeriesOverheadsSpaceTimeforviewmaintenanceImmediateviewmaintenance:doneaspartofupdatetxntimeoverheadpaidbyupdatetransactionDeferredviewmaintenance:doneonlywhenrequiredupdatetransactionisnotaffected,butsystemtimeisspentonviewmaintenanceuntilupdated,theviewmaybeout-of-datePreferabletodenormalizedschemasinceviewmaintenanceissystemsresponsibility,notprogrammersAvoidsinconsistenciescausedbyerrorsinupdateprograms TuningtheDatabaseDesign(Cont.)HowtochoosesetofmaterializedviewsHelpingonetransactiontypebyintroducingamaterializedviewmayhurtothersChoiceofmaterializedviewsdependsoncostsUsersoftenhavenoideaofactualcostofoperationsOverall,manualselectionofmaterializedviewsistediousSomedatabasesystemsprovidetoolstohelpDBAchooseviewstomaterialize“Materializedviewselectionwizards” TuningofTransactionsBasicapproachestotuningoftransactionsImprovesetorientationReducelockcontentionRewritingofqueriestoimproveperformancewasimportantinthepast,butsmartoptimizershavemadethislessimportantCommunicationoverheadandqueryhandlingoverheadssignificantpartofcostofeachcallCombinemultipleembeddedSQL/ODBC/JDBCqueriesintoasingleset-orientedquerySetorientation->fewercallstodatabaseE.g.,tuneprogramthatcomputestotalsalaryforeachdepartmentusingaseparateSQLquerybyinsteadusingasinglequerythatcomputestotalsalariesforalldepartmentatonce(usinggroupby)Usestoredprocedures:avoidsre-parsingandre-optimizationofquery TuningofTransactions(Cont.)ReducinglockcontentionLongtransactions(typicallyread-only)thatexaminelargepartsofarelationresultinlockcontentionwithupdatetransactionsE.g.,largequerytocomputebankstatisticsandregularbanktransactionsToreducecontentionUsemulti-versionconcurrencycontrolE.g.,Oracle“snapshots”whichsupportmulti-version2PLUsedegree-twoconsistency(cursor-stability)forlongtransactionsDrawback:resultmaybeapproximate TuningofTransactions(Cont.)LongupdatetransactionscauseseveralproblemsExhaustlockspaceExhaustlogspaceandalsogreatlyincreaserecoverytimeafteracrash,andmayevenexhaustlogspaceduringrecoveryifrecoveryalgorithmisbadlydesigned!Usemini-batchtransactionstolimitnumberofupdatesthatasingletransactioncancarryout.E.g.,ifasinglelargetransactionupdateseveryrecordofaverylargerelation,logmaygrowtoobig.*Splitlargetransactionintobatchof“mini-transactions,""eachperformingpartoftheupdatesHoldlocksacrosstransactionsinamini-batchtoensureserializabilityIflocktablesizeisaproblemcanreleaselocks,butatthecostofserializability*Incaseoffailureduringamini-batch,mustcompleteitsremainingportiononrecovery,toensureatomicity. PerformanceSimulationPerformancesimulationusingqueuingmodelusefultopredictbottlenecksaswellastheeffectsoftuningchanges,evenwithoutaccesstorealsystemQueuingmodelaswesawearlierModelsactivitiesthatgooninparallelSimulationmodelisquitedetailed,butusuallyomitssomelowleveldetailsModelservicetime,butdisregarddetailsofserviceE.g.,approximatediskreadtimebyusinganaveragediskreadtimeExperimentscanberunonmodel,andprovideanestimateofmeasuressuchasaveragethroughput/responsetimeParameterscanbetunedinmodelandthenreplicatedinrealsystemE.g.,numberofdisks,memory,algorithms,etc. PerformanceBenchmarksSuitesoftasksusedtoquantifytheperformanceofsoftwaresystemsImportantincomparingdatabasesystems,especiallyassystemsbecomemorestandardscompliant.Commonlyusedperformancemeasures:Throughput(transactionspersecond,ortps)Responsetime(delayfromsubmissionoftransactiontoreturnofresult)Availabilityormeantimetofailure PerformanceBenchmarks(Cont.)SuitesoftasksusedtocharacterizeperformancesingletasknotenoughforcomplexsystemsBewarewhencomputingaveragethroughputofdifferenttransactiontypesE.g.,supposeasystemrunstransactiontypeAat99tpsandtransactiontypeBat1tps.GivenanequalmixtureoftypesAandB,throughputisnot(99+1)/2=50tps.Runningonetransactionofeachtypetakestime1+.01seconds,givingathroughputof1.98tps.Tocomputeaveragethroughput,useharmonicmean:nInterference(e.g.,lockcontention)makeseventhisincorrectifdifferenttransactiontypesrunconcurrently1/t1+1/t2+…+1/tn DatabaseApplicationClassesOnlinetransactionprocessing(OLTP)requireshighconcurrencyandclevertechniquestospeedupcommitprocessing,tosupportahighrateofupdatetransactions.Decisionsupportapplicationsincludingonlineanalyticalprocessing,orOLAPapplicationsrequiregoodqueryevaluationalgorithmsandqueryoptimization.ArchitectureofsomedatabasesystemstunedtooneofthetwoclassesE.g.,TeradataistunedtodecisionsupportOtherstrytobalancethetworequirementsE.g.,Oracle,withsnapshotsupportforlongread-onlytransaction BenchmarksSuitesTheTransactionProcessingCouncil(TPC)benchmarksuitesarewidelyused.TPC-AandTPC-B:simpleOLTPapplicationmodelingabanktellerapplicationwithandwithoutcommunicationNotusedanymoreTPC-C:complexOLTPapplicationmodelinganinventorysystemCurrentstandardforOLTPbenchmarking BenchmarksSuites(Cont.)TPCbenchmarks(cont.)TPC-D:complexdecisionsupportapplicationSupercededbyTPC-HandTPC-RTPC-H:(Hforadhoc)basedonTPC-DwithsomeextraqueriesModelsadhocquerieswhicharenotknownbeforehandTotalof22querieswithemphasisonaggregationprohibitsmaterializedviewspermitsindicesonlyonprimaryandforeignkeysTPC-R:(Rforreporting)sameasTPC-H,butwithoutanyrestrictionsonmaterializedviewsandindicesTPC-W:(WforWeb)End-to-endWebservicebenchmarkmodelingaWebbookstore,withcombinationofstaticanddynamicallygeneratedpages TPCPerformanceMeasuresTPCperformancemeasurestransactions-per-secondwithspecifiedconstraintsonresponsetimetransactions-per-second-per-dollaraccountsforcostofowningsystemTPCbenchmarkrequiresdatabasesizestobescaledupwithincreasingtransactions-per-secondReflectsrealworldapplicationswheremorecustomersmeansmoredatabasesizeandmoretransactions-per-secondExternalauditofTPCperformancenumbersmandatoryTPCperformanceclaimscanbetrusted TPCPerformanceMeasuresTwotypesoftestsforTPC-HandTPC-RPowertest:runsqueriesandupdatessequentially,thentakesmeantofindqueriesperhourThroughputtest:runsqueriesandupdatesconcurrentlymultiplestreamsrunninginparalleleachgeneratesqueries,withoneparallelupdatestreamCompositequeryperhourmetric:squarerootofproductofpowerandthroughputmetricsCompositeprice/performancemetric OtherBenchmarksOODBtransactionsrequireadifferentsetofbenchmarks.OO7benchmarkhasseveraldifferentoperations,andprovidesaseparatebenchmarknumberforeachkindofoperationReason:hardtodefinewhatisatypicalOODBapplicationBenchmarksforXMLbeingdiscussed StandardizationThecomplexityofcontemporarydatabasesystemsandtheneedfortheirinteroperationrequireavarietyofstandards.syntaxandsemanticsofprogramminglanguagesfunctionsinapplicationprograminterfacesdatamodels(e.g.,objectoriented/objectrelationaldatabases)Formalstandardsarestandardsdevelopedbyastandardsorganization(ANSI,ISO),orbyindustrygroups,throughapublicprocess.DefactostandardsaregenerallyacceptedasstandardswithoutanyformalprocessofrecognitionStandardsdefinedbydominantvendors(IBM,Microsoft)oftenbecomedefactostandardsDefactostandardsoftengothroughaformalprocessofrecognitionandbecomeformalstandards Standardization(Cont.)Anticipatorystandardsleadthemarketplace,definingfeaturesthatvendorsthenimplementEnsurecompatibilityoffutureproductsButattimesbecomeverylargeandunwieldysincestandardsbodiesmaynotpayenoughattentiontoeaseofimplementation(e.g.,SQL-92orSQL:1999)Reactionarystandardsattempttostandardizefeaturesthatvendorshavealreadyimplemented,possiblyindifferentways.Canbehardtoconvincevendorstochangealreadyimplementedfeatures.E.g.,OODBsystems SQLStandardsHistorySQLdevelopedbyIBMinlate70s/early80sSQL-86firstformalstandardIBMSAAstandardforSQLin1987SQL-89addedfeaturestoSQL-86thatwerealreadyimplementedinmanysystemsWasareactionarystandardSQL-92addedmanynewfeaturestoSQL-89(anticipatorystandard)Defineslevelsofcompliance(entry,intermediateandfull)EvennowfewdatabasevendorshavefullSQL-92implementation SQLStandardsHistory(Cont.)SQL:1999Addsvarietyofnewfeatures---extendeddatatypes,objectorientation,procedures,triggers,etc.BrokenintoseveralpartsSQL/Framework(Part1):overviewSQL/Foundation(Part2):types,schemas,tables,query/updatestatements,security,etc.SQL/CLI(CallLevelInterface)(Part3):APIinterfaceSQL/PSM(PersistentStoredModules)(Part4):proceduralextensionsSQL/Bindings(Part5):embeddedSQLfordifferentembeddinglanguages SQLStandardsHistory(Cont.)MorepartsundergoingstandardizationprocessPart7:SQL/Temporal:temporaldataPart9:SQL/MED(ManagementofExternalData)InterfacingofdatabasetoexternaldatasourcesAllowsotherdatabases,evenfiles,canbeviewedaspartofthedatabasePart10SQL/OLB(ObjectLanguageBindings):embeddingSQLinJavaMissingpartnumbers6and8coverfeaturesthatarenotnearstandardizationyet DatabaseConnectivityStandardsOpenDataBaseConnectivity(ODBC)standardfordatabaseinterconnectivitybasedonCallLevelInterface(CLI)developedbyX/Openconsortiumdefinesapplicationprogramminginterface,andSQLfeaturesthatmustbesupportedatdifferentlevelsofcomplianceJDBCstandardusedforJavaX/OpenXAstandardsdefinetransactionmanagementstandardsforsupportingdistributed2-phasecommitOLE-DB:APIlikeODBC,butintendedtosupportnon-databasesourcesofdatasuchasflatfilesOLE-DBprogramcannegotiatewithdatasourcetofindwhatfeaturesaresupportedInterfacelanguagemaybeasubsetofSQLADO(ActiveDataObjects):easy-to-useinterfacetoOLE-DBfunctionality ObjectOrientedDatabasesStandardsObjectDatabaseManagementGroup(ODMG)standardforobject-orienteddatabasesversion1in1993andversion2in1997,version3in2000provideslanguageindependentObjectDefinitionLanguage(ODL)aswellasseverallanguagespecificbindingsObjectManagementGroup(OMG)standardfordistributedsoftwarebasedonobjectsObjectRequestBroker(ORB)providestransparentmessagedispatchtodistributedobjectsInterfaceDefinitionLanguage(IDL)fordefininglanguage-independentdatatypesCommonObjectRequestBrokerArchitecture(CORBA)definesspecificationsofORBandIDL XML-BasedStandardsSeveralXMLbasedStandardsforE-commerceE.g.,RosettaNet(supplychain),BizTalkDefinecatalogs,servicedescriptions,invoices,purchaseorders,etc.XMLwrappersareusedtoexportinformationfromrelationaldatabasestoXMLSimpleObjectAccessProtocol(SOAP):XMLbasedremoteprocedurecallstandardUsesXMLtoencodedata,HTTPastransportprotocolStandardsbasedonSOAPforspecificapplicationsE.g.,OLAPandDataMiningstandardsfromMicrosoft E-CommerceE-commerceistheprocessofcarryingoutvariousactivitiesrelatedtocommercethroughelectronicmeansActivitiesinclude:Presaleactivities:catalogs,advertisements,etc.Saleprocess:negotiationsonprice/qualityofserviceMarketplace:e.g.,stockexchange,auctions,reverseauctionsPaymentforsaleDeliveryrelatedactivities:electronicshipping,orelectronictrackingoforderprocessing/shippingCustomersupportandpost-saleservice E-CatalogsProductcatalogsmustprovidesearchingandbrowsingfacilitiesOrganizeproductsintointuitivehierarchyKeywordsearchHelpcustomerwithcomparisonofproductsCustomizationofcatalogNegotiatedpricingforspecificorganizationsSpecialdiscountsforcustomersbasedonpasthistoryE.g.,loyaltydiscountLegalrestrictionsonsalesCertainitemsnotexposedtounder-agecustomersCustomizationrequiresextensivecustomer-specificinformation MarketplacesMarketplaceshelpinnegotiatingthepriceofaproductwhentherearemultiplesellersandbuyersSeveraltypesofmarketplacesReverseauctionAuctionExchangeRealworldmarketplacescanbequitecomplicatedduetoproductdifferentiationDatabaseissues:AuthenticatebiddersRecordbuy/sellbidssecurelyCommunicatebidsquicklytoparticipantsDelayscanleadtofinanciallosstosomeparticipantsNeedtohandleverylargevolumesoftradeattimesE.g.,attheendofanauction TypesofMarketplaceReverseauctionsystem:singlebuyer,multiplesellers.Buyerstatesrequirements,sellersbidforsupplyingitems.Lowestbidderwins.(alsoknownastendersystem)Openbiddingvs.closedbiddingAuction:Multiplebuyers,singlesellerSimplestcase:onlyoneinstanceofeachitemisbeingsoldHighestbidderforanitemwinsMorecomplicatedwithmultiplecopies,andbuyersbidforspecificnumberofcopiesExchange:multiplebuyers,multiplesellersE.g.,stockexchangeBuyersspecifymaximumprice,sellersspecifyminimumpriceexchangematchesbuyandsellbids,decidingonpriceforthetradee.g.,averageofbuy/sellbids OrderSettlementOrdersettlement:paymentforgoodsanddeliveryInsecuremeansforelectronicpayment:sendcreditcardnumberBuyersmaypresentsomeoneelse’screditcardnumbersSellerhastobetrustedtobillonlyforagreed-onitemSellerhastobetrustednottopassonthecreditcardnumbertounauthorizedpeopleNeedsecurepaymentsystemsAvoidabove-mentionedproblemsProvidegreaterdegreeofprivacyE.g.,notrevealbuyersidentitytosellerEnsurethatanyonemonitoringtheelectronictransmissionscannotaccesscriticalinformation SecurePaymentSystemsAllinformationmustbeencryptedtopreventeavesdroppingPublic/privatekeyencryptionwidelyusedMustpreventperson-in-the-middleattacksE.g.,someoneimpersonatessellerorbank/creditcardcompanyandfoolsbuyerintorevealinginformationEncryptingmessagesalonedoesn’tsolvethisproblemMoreonthisinnextslideThree-waycommunicationbetweenseller,buyerandcredit-cardcompanytomakepaymentCreditcardcompanycreditsamounttosellerCreditcardcompanyconsolidatesallpaymentsfromabuyerandcollectsthemtogetherE.g.,viabuyer’sbankthroughphysical/electroniccheckpayment SecurePaymentSystems(Cont.)Digitalcertificatesareusedtopreventimpersonation/man-in-themiddleattackCertificationagencycreatesdigitalcertificatebyencrypting,e.g.,seller’spublickeyusingitsownprivatekeyVerifiessellersidentitybyexternalmeansfirst!SellersendscertificatetobuyerCustomerusespublickeyofcertificationagencytodecryptcertificateandfindsellerspublickeyMan-in-the-middlecannotsendfakepublickeySellerspublickeyusedforsettingupsecurecommunicationSeveralsecurepaymentprotocolsE.g.,SecureElectronicTransaction(SET) DigitalCashCredit-cardpaymentdoesnotprovideanonymityTheSETprotocolhidesbuyersidentityfromsellerButevenwithSET,buyercanbetracedwithhelpofcreditcardcompanyDigitalcashsystemsprovideanonymitysimilartothatprovidedbyphysicalcashE.g.,DigCashBasedonencryptiontechniquesthatmakeitimpossibletofindoutwhopurchaseddigitalcashfromthebankDigitalcashcanbespentbypurchaserinpartsmuchlikewritingacheckonanaccountwhoseownerisanonymous LegacySystemsLegacysystemsareolder-generationsystemsthatareincompatiblewithcurrentgenerationstandardsandsystemsbutstillinproductionuseE.g.,applicationswritteninCobolthatrunonmainframesToday’shotnewsystemistomorrowslegacysystem!PortinglegacysystemapplicationstoamoremodernenvironmentisproblematicVeryexpensive,sincelegacysystemmayinvolvemillionsoflinesofcode,writtenoverdecadesOriginalprogrammersusuallynolongeravailableSwitchingoverfromoldsystemtonewsystemisaproblemmoreonthislaterOneapproach:buildawrapperlayerontopoflegacyapplicationtoallowinteroperationbetweennewersystemsandlegacyapplicationE.g.,useODBCorOLE-DBaswrapper LegacySystems(Cont.)RewritinglegacyapplicationrequiresafirstphaseofunderstandingwhatitdoesOftenlegacycodehasnodocumentationoroutdateddocumentationreverseengineering:processofgoingoverlegacycodetoComeupwithschemadesignsinERorOOmodelFindoutwhatproceduresandprocessesareimplemented,togetahighlevelviewofsystemRe-engineering:reverseengineeringfollowedbydesignofnewsystemImprovementsaremadeonexistingsystemdesigninthisprocess LegacySystems(Cont.)SwitchingoverfromoldtonewsystemisamajorproblemProductionsystemsareineveryday,generatingnewdataStoppingthesystemmaybringallofacompany’sactivitiestoahalt,causingenormouslossesBig-bangapproach:ImplementcompletenewsystemPopulateitwithdatafromoldsystemNotransactionswhilethisstepisexecutedscriptsarecreatedtodothisquicklyShutdownoldsystemandstartusingnewsystemDangerwiththisapproach:whatifnewcodehasbugsorperformanceproblems,ormissingfeaturesCompanymaybebroughttoahalt LegacySystems(Cont.)Chicken-littleapproach:ReplacelegacysystemonepieceatatimeUsewrapperstointeroperatebetweenlegacyandnewcodeE.g.,replacefrontendfirst,withwrappersonlegacybackendOldfrontendcancontinueworkinginthisphaseincaseofproblemswithnewfrontendReplacebackend,onefunctionalunitatatimeAllpartsthatshareadatabasemayhavetobereplacedtogether,orwrapperisneededondatabasealsoDrawback:significantextradevelopmentefforttobuildwrappersandensuresmoothinteroperationStillworthitifcompany’slifedependsonsystem EndofChapter'