Suorituskyvyn viritys Informaticassa: täydellinen opetusohjelma

by: David Carter David Carter
Hours Päivitetty

⚡ Älykäs yhteenveto

Informatican suorituskyvyn viritys poistaa istunnon hitaimman linkin kerros kerrallaan, kohteesta takaisin lähteen, kartan, kautta.ping, istunto ja lopuksi käyttöjärjestelmä.

  • 🎯 Kiinteä järjestys: Informatica suosittelee pullonkaulojen etsimistä ensin kohteena, sitten lähteenä ja lopuksi kartoituksena.ping, sitten istunto ja sitten järjestelmä.
  • 🧵 Ketjun tilastot kertovat totuuden: Lukija-, transformaatio- ja kirjoittajaketjuista kiireisin nimeää kerroksen, joka kaipaa työtä.
  • 🚿 Suodata aikaisin: Lähdemääritteessä hylätyt rivit eivät koskaan mene putkeen, joten ne eivät maksa mitään loppupäässä.
  • 🗄️ Työn siirtäminen tietokantaan: Liitokset, lajittelut ja suodatukset toimivat yleensä nopeammin SQL:ssä kuin transformaatiossa.
  • 🧊 Välimuistin kurinalaisuus: Vähemmän portteja ja hakusarakkeita tarkoittaa pienempiä välimuisteja ja vähemmän levyn sivutusta.
  • ⚙️ Istuntoasetukset ovat tärkeitä: DTM-puskurin koko, puskurilohkon koko, commit-väli ja puskurin optimointi säädetään mapin jälkeen.ping on puhdas.
Lue lisää

Suorituskyvyn viritys Informaticassa

Mitä on suorituskyvyn viritys Informaticassa?

Informaticassa suorituskyvyn virittäminen tarkoittaa käytäntöä, jossa etsitään yksi komponentti, joka rajoittaa istunnon suoritusnopeutta, poistetaan kyseinen rajoitus ja toistetaan harjoitus seuraavaksi hitaimmalle komponentille. Istunto on aina vain niin nopea kuin sen hitain kerros, joten sellaisen transformaation virittäminen, joka ei koskaan ollut ongelma, ei tuota mitattavissa olevaa hyötyä.

Informatica tunnistaa viisi kohtaa, joissa pullonkaula voi sijaita, ja suosittelee niiden tarkistamista kiinteässä järjestyksessä.

Tilaus kerros Tyypillinen syy
1 Target Hitaat kirjoitusprosessit, pienet tarkistuspistevälit, pienet tietokantaverkon pakettien koot
2 Lähde Hidas kysely, puuttuvat indeksit, tarpeettomia sarakkeita luetaan
3 karttaping Kalliit tai huonosti sijoitetut muunnokset, ylisuuret välimuistit
4 istunto Buffer muisti, commit-väli, osiointi, lataustyyppi
5 järjestelmä Suorittimen kyllästyminen, I/O-odotukset, sivutus Integration Service -koneessa

Järjestys on tarkoituksellinen. Kohde, joka ei pysty imemään rivejä riittävän nopeasti, saa jokaisen ylävirran tason näyttämään hitaalta, joten se tarkistetaan ensin. Koko menetelmä on dokumentoitu kohdassa PowerCenterin suorituskyvyn viritysopas.

Kuinka tunnistaa suorituskyvyn pullonkaulat

Hitaan kerroksen arvaaminen vie enemmän aikaa kuin sen mittaaminen. Neljä tekniikkaa kattavat viisi yllä lueteltua kerrosta.

  • Suorita testisessio. Määritä kopio Istunto kirjoittaakseen tasaiselle tiedostolle. Jos istunto nopeutuu huomattavasti, kohde on pullonkaula. Saman tempun peilikuva, joka lukee tasaiselle tiedostolle lähteestä, eristää lähteen pullonkaulan.
  • Analysoi ketjun tilastoja. Data Transformation Manager suorittaa lukijasäikeen, yhden tai useamman muunnossäikeen ja kirjoittajasäikeen. Istuntolokissa eniten kiireinen säie osoittaa suoraan käsiteltävään tasoon: lukija lähdettä varten, muunnos karttaa varten.ping, kohteen kirjoittaja.
  • Analysoi suorituskyvyn yksityiskohtia. Ota käyttöön suorituskykytietojen kerääminen istunnossa ja lue laskurit. Korkea virhemäärä riveissä tai suuri määrä rivejä hakuvälimuistissa viittaavat vastaavuuteen.ping ongelma pikemminkin kuin tietokantaongelma.
  • Valvo järjestelmää. Operajärjestelmätyökalut, jotka näyttävät suorittimen käytön, I/O-odotukset ja sivutuksen sekä Työnkulun valvonta resurssinäkymät paljastavat koneen, jonka kapasiteetti on yksinkertaisesti loppu.

Kun vastuullinen kerros on tiedossa, seuraavissa osioissa annettujen muunnostason neuvojen soveltaminen on hyödyllistä. Osiot on järjestetty liukuhihnan mukaiseen järjestykseen siitä pisteestä, jossa data saapuu järjestelmään. karttaping siihen pisteeseen asti, että se kasaantuu.

Lähteen tarkentimen muunnos

Jokainen rivi, jota lähdetarkenne ei lue, on rivi, jota minkään muun muunnoksen ei tarvitse käsitellä, mikä tekee siitä halvimman paikan koko kartalla.ping ajan säästämiseksi.

  • Tuo lähteestä vain vaaditut sarakkeet. Useimmiten kaikkia lähdetaulukon sarakkeita ei vaadita, joten tuo vain pakolliset kentät poistamalla tarpeettomat sarakkeet.
  • Vältä order by -lauseen käyttöä lausekkeen sisällä Lähteen tarkentaja SQL-ohitus. Order by -lauseke vaatii lisäkäsittelyä, ja suorituskykyä voidaan parantaa välttämällä sitä.

AIHEESEEN LIITTYVÄT ARTIKKELIT

Suodattimen muunnos

Suodatus noudattaa samaa periaatetta myöhemmin putkessa: ei-toivotut rivit hylätään mahdollisimman pian siinä vaiheessa, kun karttaping on riittävästi tietoa heidän tunnistamisekseen.

  • Käyttää suodattimen muunnos mahdollisimman aikaisin kartan sisälläpingJos ei-toivotut tiedot voidaan poistaa kartan alkuvaiheessaping, se lisäisi läpivirtausta.
  • Käytä lähdetarkennetta tietojen suodattamiseen. Voit myös käyttää lähdetarkenteen SQL-ohitusfunktiota tietueiden suodattamiseen suodatinmuunnoksen käyttämisen sijaan.

Puusepän muutos

Liittyminen on ensimmäinen todella kallis operaatio tyypillisessä kartassaping, koska päälähde on tallennettava välimuistiin ennen kuin yksityiskohtarivit voidaan yhdistää siihen.

  • Suosi aina liitosten tekemistä tietokannassa, jos mahdollista, koska tietokantaliitokset ovat nopeampia kuin Informaticassa luodut liitokset. liitosmuunnos.
  • Lajittele tiedot ennen liittymistä, jos mahdollista, koska se vähentää liittämisen aikana suoritettua levyn I/O:ta.
  • Tee päätaulukoksi taulukko, jossa on vähemmän rivejä.

Kolmas kohta on se, joka useimmiten unohtuu. Integrointipalvelu tallentaa päälähteen välimuistiin, joten pienemmän taulukon nimeäminen päälähteeksi pitää välimuistin pienenä.

Hakumuunnos

Haku joko kyselee tietokantaa kerran riviä kohden tai rakentaa välimuistin muistiin, ja molemmat reitit palkitsevat pienemmän, paremmin indeksoidun hakulähteen.

  • Luo sarakkeelle indeksi kohdassa hakutaulukko jota käytetään hakuehdossa. Koska hakutaulukkoon tehdään kysely vastaavan datan etsimiseksi, indeksin lisääminen parantaisi suorituskykyä.
  • Jos mahdollista, käytä hakumuunnosten sijaan liittämistä tietokantaan. Koska tietokantaliitokset ovat nopeampia, suorituskyky paranee.
  • Poista tarpeettomat sarakkeet hakutaulukosta ja säilytä vain vaaditut sarakkeet. Tämä vähentää ylimääräisten sarakkeiden hakemista tietokannasta.

Aggregaattorin muunnos

An Kerääjä pitää tietoja välimuistissa samalla kun se ryhmittelee rivejä, joten kaikki, mikä vähentää siihen saapuvaa tallennustilaa, vähentää tarvitsemaansa välimuistia.

  • Suodata tiedot ennen niiden yhdistämistä. Jos käytät suodatinmuunnosta kartallaping, suodata sitten tiedot ennen aggregaattorin käyttöä, koska se vähentää tarpeetonta aggregointioperaatiota.
  • Rajoita aggregaattoritransformaatiossa käytettävien porttien määrää. Tämä vähentää aggregaattoritransformaation välimuistiin tallentaman datan määrää.

Istuntotason viritys Informaticassa

Kun karttaping itsessään on siisti, loput hyödyt tulevat istunnon ominaisuuksista. Näitä asetuksia kannattaa muuttaa yksi kerrallaan, ja jokaisen muutoksen jälkeen on tehtävä ajastettu suoritus, koska useat niistä vaihtavat muistia nopeuden vuoksi.

Asetus Mitä se hallitsee Milloin sitä kannattaa muuttaa
DTM-puskurin koko Integrointipalvelun lähde- ja kohdedatalohkoille varaaman muistin kokonaismäärä Lisää, kun istunto käsittelee useita osioita, lähteitä tai kohteita
Buffer lohkokoko Yksittäisen muistilohkon koko Lisää epätavallisen suurilla riveillä; pienennä, kun fyysistä muistia on rajoitetusti
Vahvistusväli Kuinka monta riviä kirjoitetaan ennen commitin antamista Nosta se, kun kirjoittajaketju odottaa tietokannan tarkistuspisteitä
Alaspäin työntyvän optimoinnin Kuinka suuri osa kartastaping logiikka muunnetaan SQL-muotoon ja tietokanta suorittaa sen Käytä, kun lähde- ja kohdetietokannat ovat samassa tehokkaassa tietokannassa

Buffer muisti noudattaa dokumentoitua laskentaa arvailun sijaan. Integrointipalvelu varaa vähintään kaksi lohkoa kullekin lähde- ja kohdeosiolle, joten istuntopuskurilohkojen määrä kerrotaan (lähteiden kokonaismäärä + kohteiden kokonaismäärä) kahdella ja DTM-puskurin koko on lohkojen määrä kerrottuna puskurilohkon koolla ja jaettuna 0.9:llä.

Alaspäin suuntautuvassa optimoinnissa on syytä olla varovainen. Se auttaa vain silloin, kun tietokanta on aidosti nopeampi kuin Integration Service -kone ja muunnoslogiikka voidaan ilmaista muodossa SQL; logiikka, jota ei voida kääntää, jää istuntoon, joten vahvistus on usein odotettua pienempi. Mittaa ennen ja jälkeen sen sijaan, että otat sen käyttöön oletusarvoisesti.

UKK

Osiointi auttaa, kun Integration Service -koneella on ylimääräistä suoritinta ja lähde- ja kohdekone voivat palvella rinnakkaisyhteyksiä. Kyllästetyllä koneella tai yksisäikeistä kohdetta vasten ylimääräiset osiot lisäävät työmäärää lyhentämättä suoritusaikaa.

Aseta indeksi- ja datavälimuisti riittävän suuriksi koko hakulähteen säilyttämiseksi. Muussa tapauksessa Integration Service -sivut tallennetaan levylle. Istuntolokit raportoivat todellisen välimuistin koon, joten suorita se kerran automaattisella koonmäärityksellä ja lue arvo takaisin.

Jokainen lisäys ylläpitää myös kaikkia kohteen indeksejä ja rajoitteita, ja tämä kustannus kasvaa taulukon koon kasvaessa. Vanhentuneet tietokannan tilastot pahentavat tilannetta. Kirjoitussäikeestä tulee tällöin kiireisin säie, joka on klassinen kohteen pullonkaula-allekirjoitus.

Kyllä, koska muunnos voi vapauttaa jokaisen ryhmän heti sen päättymisen jälkeen sen sijaan, että se tallentaisi kaiken välimuistiin. Saapuvien rivien on oltava jo lajiteltuja ryhmittelyporttien mukaan, ja istunto epäonnistuu, jos näin ei ole.

Suuren, pelkän insertin sisältävän kuorman kohdalla pudotaping indeksit ja rajoitteet ensin ja niiden uudelleenrakentaminen jälkeenpäin on yleensä nopeampaa. Istunnon ominaisuuksissa olevat istuntoa edeltävät ja sen jälkeiset SQL-komennot ovat normaali paikka molempien vaiheiden skriptaamiseen.

Joukkotila ohittaa suuren osan tietokannan lokikirjauksesta ja latautuu nopeammin, mutta se estää palautumisen eikä toimi kaikkien kohteiden tai päivitysstrategioiden kanssa. Normaalitila kirjoittaa tavallisen lokitiedostopolun kautta ja pysyy palautettavissa.

Historiallisilla suoritusajoilla koulutetut mallit merkitsevät istunnon, joka on poikennut normaalista kestostaan ​​kauan ennen kuin kukaan huomaa sitä, sekä klusteriin liittyvät virheet. Ne osoittavat muuttuneeseen suoritukseen – vastuussa oleva kerros on vielä vahvistettava säikeiden tilastoista.

Se voi kirjoittaa kyselyn uudelleen, ehdottaa indeksiehdokkaita ja selittää editoriin liitetyn suoritussuunnitelman. Se ei voi nähdä repositoriota tai istuntolokia, joten kaikki uudelleenkirjoitukset on validoitava todellisen suunnitelman ja rivimäärien perusteella.

Tiivistä tämä viesti seuraavasti: