Performance Tuning i Informatica: Komplet selvstudium

⚡ Smart opsummering

Ydelsesjustering i Informatica fjerner det langsomste link i en session, ét lag ad gangen, og arbejder sig fra målet tilbage gennem kilden, kortetping, sessionen og endelig operativsystemet.

🎯 Fast ordre: Informatica anbefaler at søge efter flaskehalse som mål, derefter kilde og derefter kortlæggeping, derefter session, så system.
🧵 Trådstatistikker fortæller historien: Den travleste af læser-, transformations- og forfattertrådene navngiver det lag, der skal arbejdes med.
🚿 Filtrer tidligt: Rækker, der kasseres i kildekvalifikatoren, indgår aldrig i pipelinen, så de koster ingenting downstream.
🗄️ Send arbejde til databasen: Joins, sorterings og filtre kører normalt hurtigere i SQL end i en transformation.
🧊 Cache-disciplin: Færre porte og færre opslagskolonner betyder mindre caches og mindre diskpaging.
🇧🇷 Sessionsindstillinger er vigtige: DTM-bufferstørrelse, bufferblokstørrelse, commit-interval og pushdown-optimering justeres efter kortetping er ren.

Læs mere

Hvad er performance tuning i Informatica?

Performance tuning i Informatica er praksissen med at finde den ene komponent, der begrænser, hvor hurtigt en session kører, fjerne denne begrænsning og derefter gentage øvelsen på den komponent, der bliver den langsomste næste gang. En session er kun så hurtig som dens langsomste lag, så tuning af en transformation, der aldrig var problemet, giver ingen målbar gevinst.

Informatica identificerer fem steder, hvor en flaskehals kan sidde, og anbefaler at kontrollere dem i en fast rækkefølge.

Bestil	lag	Typisk årsag
1	Target	Langsomme skrivninger, korte checkpointintervaller, små databasenetværkspakkestørrelser
2	Kilde	Langsom forespørgsel, manglende indeks, unødvendige kolonner bliver læst
3	Kortping	Dyre eller dårligt placerede transformationer, overdimensionerede cacher
4	Session	Buffer hukommelse, commit-interval, partitionering, indlæsningstype
5	Systemkrav	CPU-mætning, I/O-ventetider, paging på integrationstjenestemaskinen

Rækkefølgen er bevidst. Et mål, der ikke kan absorbere rækker hurtigt nok, vil få alle opstrømslag til at se langsomme ud, så det kontrolleres først. Den fulde metode er dokumenteret i PowerCenter Performance Tuning Guide.

Sådan identificerer du flaskehalse i præstationer

Det spilder mere tid at gætte, hvilket lag der er langsomt, end at måle det. Fire teknikker dækker de fem lag, der er anført ovenfor.

Kør en testsession. Konfigurer en kopi af Session at skrive til et fladt filmål. Hvis sessionen øges mærkbart i hastighed, er målet flaskehalsen. Spejlbilledet af det samme trick, der læser fra en flad filkilde, isolerer en kildeflaskehals.
Analyser trådstatistikker. Data Transformation Manager kører en læsertråd, en eller flere transformationstråde og en skrivetråd. Tråden med den højeste travlhed i sessionsloggen peger direkte på det lag, der skal arbejdes på: læser for kilden, transformation for kortetping, forfatter for målet.
Analyser præstationsdetaljer. Aktivér indsamling af ydeevnedata i sessionen, og læs tællerne. Rækker med mange fejl eller et stort antal rækker i en opslagscache indikerer et kort.ping et problem snarere end et databaseproblem.
Overvåg systemet. Operasystemværktøjer, der viser CPU-forbrug, I/O-ventetider og paging, sammen med Workflow Monitor ressourcevisninger, afslører en maskine, der simpelthen ikke har mere kapacitet.

Når det ansvarlige lag er kendt, bliver rådene på transformationsniveau i de følgende afsnit værd at anvende. Afsnittene er arrangeret i pipeline-rækkefølge, fra det punkt hvor data kommer ind i kortping til det punkt, hvor det er aggregeret.

Kildekvalifikationstransformation

Hver række, som kildekvalifikatoren ikke læser, er en række, som ingen anden transformation behøver at behandle, hvilket gør den til det billigste sted på hele kortet.ping for at spare tid.

Medbring kun de nødvendige kolonner fra kilden. De fleste gange er ikke alle kolonnerne i kildetabellen nødvendige, så medbring kun de påkrævede felter ved at slette de unødvendige kolonner.
Undgå at bruge order by-klausulen indeni Kildekvalifikation SQL-overstyring. Order by-klausulen kræver yderligere behandling, og ydeevnen kan øges ved at undgå den.

Filter transformation

Filtrering følger det samme princip et trin senere i pipelinen: kasser uønskede rækker på det tidligste tidspunkt, hvor kortetping har nok information til at identificere dem.

Brug filtertransformation så tidligt som muligt inde på kortetpingHvis de uønskede data kan kasseres tidligt i kortetping, det ville øge gennemstrømningen.
Brug kildekvalifikatoren til at filtrere dataene. Du kan også bruge SQL-override af kildekvalifikatoren til at filtrere posterne i stedet for at bruge filtertransformation.

Snedker transformation

Tilmelding er den første virkelig dyre operation i et typisk kortping, fordi masterkilden skal cachelagres, før detaljerækker kan matches med den.

Foretræk altid at udføre joins i databasen, hvis det er muligt, da databasejoins er hurtigere end joins oprettet i Informatica. joiner-transformation.
Sorter dataene før sammenføjning, hvis det er muligt, da det reducerer disk I/O, der udføres under sammenføjning.
Lav en tabel med færre rækker som mastertabel.

Det tredje punkt er det, der oftest overses. Integrationstjenesten cacher masterkilden, så hvis den mindre tabel nomineres som master, holdes cachen lille.

Opslagstransformation

Et opslag forespørger enten databasen én gang pr. række eller opbygger en cache i hukommelsen, og begge ruter belønner en mindre, bedre indekseret opslagskilde.

Opret et indeks for kolonnen i en opslagstabel som bruges i opslagstilstand. Da opslagstabellen vil blive forespørget om at slå de matchende data op, vil tilføjelse af et indeks øge ydeevnen.
Hvis det er muligt, brug join i databasen i stedet for at bruge opslagstransformation. Da databasesammenføjninger er hurtigere, øges ydeevnen.
Slet unødvendige kolonner fra opslagstabellen, og behold kun de nødvendige kolonner. Dette vil reducere omkostningerne ved at hente de ekstra kolonner fra databasen.

Aggregator transformation

An aggregator holder data i en cache, mens den grupperer rækker, så alt, der reducerer den mængde, der når den, reducerer den cache, den har brug for.

Filtrer dataene, før du aggregerer dem. Hvis du bruger filtertransformation i kortetping, og filtrer derefter dataene, før du bruger aggregatoren, da det vil reducere den unødvendige aggregeringsoperation.
Begræns antallet af porte, der bruges i aggregatortransformationen. Dette vil reducere mængden af data, som aggregatortransformationen gemmer i cachen.

Sessionsniveaujustering i Informatica

Når kortetping Selve funktionen er ren, men de resterende gevinster kommer fra sessionsegenskaberne. Disse indstillinger er værd at ændre én ad gangen, med en tidsbestemt kørsel efter hver ændring, fordi flere af dem bytter hukommelse for hastighed.

Lokal område	Hvad den kontrollerer	Hvornår skal man ændre det
DTM-bufferstørrelse	Samlet hukommelse, som integrationstjenesten allokerer til kilde- og måldatablokke	Øg når sessionen håndterer mange partitioner, kilder eller mål
Buffer blok størrelse	Størrelsen på en individuel hukommelsesblok	Forøg for usædvanligt store rækker; reducer når den fysiske hukommelse er begrænset
Commit-interval	Hvor mange rækker skrives, før en commit udstedes	Hæv den, når forfattertråden bruger sin tid på at vente på databasekontrolpunkter
Pushdown-optimering	Hvor meget af kortetping Logikken konverteres til SQL og udføres af databasen	Bruges når kilde og mål befinder sig i den samme effektive database

Buffer Hukommelsen følger en dokumenteret beregning snarere end gætværk. Integrationstjenesten allokerer mindst to blokke til hver kilde- og målpartition, så antallet af sessionsbufferblokke ganges med to (samlede kilder + samlede mål), og DTM-bufferstørrelsen er blokantallet ganget med bufferblokstørrelsen og divideret med 0.9.

Pushdown-optimering fortjener en advarsel. Det hjælper kun, når databasen virkelig er hurtigere end integrationstjenestens maskine, og transformationslogikken kan udtrykkes i SQL; logik, der ikke kan oversættes, forbliver i sessionen, så gevinsten er ofte mindre end forventet. Mål før og efter i stedet for at aktivere den som standard.

Ofte Stillede Spørgsmål

Partitionering hjælper, når integrationstjenestemaskinen har en ekstra CPU, og kilden og målet kan betjene parallelle forbindelser. På en mættet maskine eller mod et enkelttrådet mål tilføjer ekstra partitioner overhead uden at forkorte kørslen.

Indstil indeks- og datacachen til at være stor nok til at indeholde hele opslagskilden, ellers overføres integrationstjenesten til disken. Sessionslogfiler rapporterer den faktisk nødvendige cachestørrelse, så kør én gang med automatisk dimensionering, og læs værdien tilbage.

Hver indsættelse opretholder også alle indeks og begrænsninger på målet, og den omkostning stiger med tabelstørrelsen. Forældet databasestatistik forværrer tingene. Skrivertråden bliver derefter den travleste tråd, hvilket er den klassiske flaskehalssignatur for målet.

Ja, fordi transformationen kan frigive hver gruppe, så snart den slutter, i stedet for at cache alt. De indgående rækker skal allerede være sorteret efter grupperingsportene, og sessionen mislykkes, hvis de ikke er det.

For en stor mængde kun-indlæg, slipping Det er normalt hurtigere at oprette indekser og begrænsninger først og derefter genopbygge dem. SQL-kommandoer før og efter sessionen på sessionsegenskaberne er det normale sted at scripte begge trin.

Massetilstand omgår meget af databaseloggingen og indlæses hurtigere, men den forhindrer gendannelse og fungerer ikke med alle mål eller med opdateringsstrategier. Normal tilstand skriver gennem den sædvanlige loggede sti og kan stadig gendannes.

Modeller, der er trænet på historiske kørselstider, markerer en session, der er afviget fra sin normale varighed længe før nogen bemærker det, og klyngerelaterede fejl. De peger på den kørsel, der ændrede sig – det ansvarlige lag skal stadig bekræftes ud fra trådstatistikker.

Den kan omskrive en forespørgsel, foreslå indekskandidater og forklare en udførelsesplan, der er indsat i editoren. Den kan ikke se arkivet eller sessionsloggen, så enhver omskrivning skal valideres i forhold til den faktiske plan og rækkeantal.