Når du aktiverer registervariabelen DB2_FORCE_FCM_BP, er det ett færre delt |minnesegment tilgjengelig for andre brukere, spesielt for |databasebufferområder. Hvis registervariabelen DB2_FORCE_FCM_BP aktiveres, reduseres derfor den |maksimale størrelsen på databasebufferområder. Legg merke til at siden det er svært mange |tilgjengelige delte minnesegmenter i et 64-bits miljø, vil denne reduksjonen av antall |delte minnesegmenter vanligvis bare kunne utgjøre et problem i 32-bits miljøer.
| | |Når en tabell blir opprettet, blir statistikken for systemkatalogen satt til -1 for å |vise at tabellen ikke har noen statistikk. Frem til det blir samlet inn statistikk, bruker |DB2 UDB standardverdiene for kompilering og optimalisering av SQL-setninger. | Oppdatering av tabell- eller |indeksstatistikk kan mislykkes hvis de nye verdiene er inkonsistente med |standardverdiene. Derfor bør du kjøre kommandoen runstats på en tabell eller |indeks før du manuelt oppdaterer statistikk for tabellen eller indeksen.
| | |SQL-feilmeldingen SQL1169N har en ny årsakskode 5 som indikerer at en kolonne for en |forklaringstabell er for liten.
|Følgende tekst er en oppdatering til Administration |Guide: Performance, Chapter 6. Understanding the SQL compiler.
|MDC roll out may be used even if a RID index is part of the optimization |plan regardless of the presence of a WHERE clause in the DELETE statement. |As a result, when listing the conditions that must be met to allow roll out |and the use of a more efficient way to delete rows, the condition that a "RID index was not chosen by the optimizer to find the rows to be deleted, |unless there is no WHERE clause in the DELETE statement" should be removed.
|Further, you are able to tell if MDC roll out is in effect because db2expln output shows the phrase "Cell Delete". | Note that db2exfmt does not show this information.
|The following text is an update to Appendix A. |DB2 Registry and Environment Variables:
|The description of DB2_MDC_ROLLOUT should be changed such that the condition |that a "RID index was not chosen by the optimizer to find the rows to be |deleted, unless there is no WHERE clause in the DELETE statement" should |be removed from the list.
| | |Hvis du oppdaterer verdiene for konfigurasjonsparameterne newlogpath, mirrorpath eller overflowlogpath, |i et DB2 UDB Enterprise Server Edition-miljø, blir nodenummeret bli tilføyd til banenavnet uavhengig av |antall noder på systemet. Dette gjelder for både enkeltpartisjons- og flerpartisjonssystemer i et DB2 UDB Enterprise Server Edition-miljø.
| | |Standardverdien for DB2_COLLECT_TS_REC_INFO er ON. I DB2 UDB V 8.1 opprettingspakke 7 ble standardverdien for registervariabelen DB2_COLLECT_TS_REC_INFO |endret til ON. I den gjeldende dokumentasjonen står |det at standardverdien for denne variabelen er OFF, men det er altså feil.
En Governor-forekomst (styrer) består av en forgrunnsfunksjon og en eller flere demoner. Hver forekomst du starter av styreren, er spesifikk for en forekomst av databasesystemet. Når du starter styreren, startes som standard en styrerdemon på hver partisjon for en partisjonert database. Du kan imidlertid oppgi at en demon skal startes på en enkelt partisjon som du ønsker å overvåke.
Hver styrerdemon samler inn informasjon om applikasjonene som kjøres mot databasen. Deretter sjekker den denne informasjonen mot reglene du oppgir i styrerens konfigurasjonsfil for denne databasen.
Hvis du vurderer å bruke en tabellomorganisering av typen in-place (i stedet for klassisk tabellomorganisering), må du huske på at in-place-tabellomorganisering krever mer loggplass.
Siden in-place-tabellomorganisering logger sine aktiviteter slik at det er mulig å utføre gjenoppretting etter en uventet feil, krever den mer loggplass enn klassisk omorganisering.
Det er mulig at in-place-omorganisering krever loggplass som er flere ganger størrelsen på den omorganiserte tabellen. Hvor mye plass som kreves, avhenger av hvor mange rader som blir flyttet, og hvor mange og hvor store indekser det er på tabellen.
Anbefaling: Velg in-place-tabellomorganisering for 24x7-drift der det er vanskelig å stoppe systemet for vedlikehold.
Med en tilkoblet (online) tabellomorganisering av en DMS-tabell er det mulig å starte en tilkoblet reservekopiering av en tabellplass der tabellen ligger, mens omorganiseringen utføres. Det kan oppstå lock wait-situasjoner for omorganiseringsoperasjonen i TRUNCATE-fasen.
Les beskrivelsene av REORG TABLE-syntaksen hvis du vil vite mer om hvordan du utfører disse metodene for tabellomorganisering.
På AIX 5L 64-bit støtter nå registervariabelen DB2_LARGE_PAGE_MEM nøkkelordet FCM.
Som standard på AIX 5L(TM) 64-bit er FCM-minnet i DBMS-minnesettet. Når registervariabelen DB2_FORCE_FCM_BP er aktivert, er imidlertid FCM-minnet i et eget minnesett. På AIX 5L 64-bit støtter DB2_LARGE_PAGE_MEM spesifikasjonen av DBMS-minnesettet. Når FCM-minnet er i DBMS-minnesettet, og støtten for store sider er aktivert for det minnesettet, vil FCM-minnet bruke store sider. Når FCM-minnet er i et eget minnesett, må FCM-nøkkelordet tilføyes til verdien for registervariabelen DB2_LARGE_PAGE_MEM for å aktivere store sider for FCM-minne.
Fra og med DB2 Universal Database (UDB) versjon 8.2.2 (tilsvarer versjon 8.1 opprettingspakke 9), godtar konfigurasjonsfilen som blir oppgitt med registervariabelen DB2_RESOURCE_POLICY, et SCHEDULING_POLICY-element. SCHEDULING_POLICY-elementet kan brukes på noen plattformer til å velge dette:
Registervariablene DB2PRIORITIES og DB2NTPRICLASS kan brukes hver for seg til å styre operativsystemets planleggingspolicy og definere DB2-agentprioriteter.
Spesifikasjonen av et SCHEDULING_POLICY-element i konfigurasjonsfilen for ressurspolicyen gir imidlertid ett enkelt sted for å oppgi både planleggingspolicyen og de tilhørende agentprioritetene.
Valg av planleggingspolicyen AIX SCHED_FIFO2 med økt prioritet for lese- og skriveprosessene for db2-loggen:
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>SCHED_FIFO2</POLICY_TYPE>
<PRIORITY_VALUE>60</PRIORITY_VALUE>
<EDU_PRIORITY>
<EDU_NAME>db2loggr</EDU_NAME>
<PRIORITY_VALUE>56</PRIORITY_VALUE>
</EDU_PRIORITY>
<EDU_PRIORITY>
<EDU_NAME>db2loggw</EDU_NAME>
<PRIORITY_VALUE>56</PRIORITY_VALUE>
</EDU_PRIORITY>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>Erstatning for DB2NTPRICLASS=H i Windows.
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>Systemvariablene DB2_MAPPED_BASE og DB2DBMSADDR er tilføyd i opprettingspakke 8.
Disse registervariablene bør bare brukes av erfarne brukere.
DB2 UDB prøver å flytte de delte bibliotekene til den virtuelle adressen 0x10000000 hvis denne variabelen ikke er definert.
Registervariabelen kan også defineres til en hvilken som helst virtuell adresse (heksadesimal) innenfor det 31- og 32-bits adresseområdet.
db2set DB2_MAPPED_BASE=
Denne meldingen kan forekomme flere ganger i filen db2diag.log fordi denne endringen må gjøre en gang per logisk node:
ADM0506I DB2 has automatically updated the "mapped_base" kernel parameter from "0x40000000(hex) 1073741824(dec)" to the recommended value "0x10000000(hex) 268435456(dec)".
Denne meldingen vil bare bli vist hvis defineringen av registervariabelen var vellykket, og den vil inneholde adressen som de delte bibliotekene ble flyttet til.
db2set DB2DBMSADDR=
Denne variabelen kan defineres sammen med DB2_MAPPED_BASE eller for seg selv for å finjustere bruken av adresseområdet for DB2 UDB-prosesser. Denne variabelen endrer plasseringen av forekomstens delte minne fra den gjeldende plasseringen på den virtuelle adressen 0x20000000 til den nye verdien som blir oppgitt.
Registervariabelen DB2TCP_CLIENT_RCVTIMEOUT har blitt tilføyd i versjon 8.2.
Ytelsesvariabelen DB2_LARGE_PAGE_MEM har blitt tilføyd i versjon 8.2.
| Variabelnavn | Operativsystem | Verdier |
|---|---|---|
| Beskrivelse | ||
| DB2_LARGE_PAGE_MEM |
AIX 5.x 64-bit Linux |
Standard=NULL
Bruk * for å oppgi at alle minneområder som kan brukes skal bruke minne med store sider, eller en kommaseparert liste med bestemte minneområder som skal bruke minne med store sider. Tilgjengelige områder varierer avhengig av operativsystemet. På AIX 5.x 64-bit kan disse områdene spesifiseres: DB, DBMS og PRIVATE. På Linux kan disse områdene spesifiseres: DB. |
|
Minne med store sidestørrelser støttes bare for DB2 Universal Database (UDB) for AIX 5L, 64-bit Edition og DB2 UDB for Linux. Registervariabelen DB2_LARGE_PAGE_MEM brukes til å aktivere støtte for store sidestørrelser på AIX 5.x eller en Linux-arkitektur riktig kernelstøtte. Denne registervariabelen gjør at variabelen DB2_LGPAGE_BP, som bare kan brukes til å aktivere store sidestørrelser for databasens delte minneområde, utgår. Dette kan nå gjøres ved å definere DB2_LARGE_PAGE_MEM=DB. Dokumentasjon som omtaler aktivering av store sidestørrelser med registervariabelen DB2_LGPAGE_BP kan leses som om det stod DB2_LARGE_PAGE_MEM=DB. Bruk av store sidestørrelser er i utgangspunktet ment å gi ytelsesforbedringer i applikasjoner med høy ytelse. Applikasjoner med stort behov for minnetilgang, og som bruker store mengder virtuelt minne, kan oppnå ytelsesforbedring ved bruk av store sidestørrelser. Hvis du vil aktivere DB2 for å bruke store sidestørrelser, må du først konfigurere operativsystemet til å bruke store sidestørrelser. Aktivering av store private sider øker minnebruken til DB2 UDB betydelig, siden hver DB2 UDB-agent vil oppta minst 1 stor side (16 MB) av det fysiske minnet. Betingelsene nedenfor må være oppfylt for å aktivere store sider for privat agentminne på 64-bits DB2 UDB for AIX (innstillingen DB2_LARGE_PAGE_MEM=PRIVATE), i tillegg til konfigurering av store sider på operativsystemet:
På 64-bits DB2 UDB for AIX reduserer denne variabelen størrelsen på det delte minnesegmentet for databasen til minimumskravet. Standardinnstillingen er å opprette en segment på 64 GB. Se databasekonfigurasjonsparameteren for delt minnestørrelse (database_memory) hvis du vil ha flere opplysninger. På denne måten unngår man reservering av mer delt minne i RAM enn det som sannsynligvis blir brukt. Ved å definere denne variabelen, begrenses muligheten til å øke konfigurasjonen av det totale delte minnet for databasen (for eksempel å øke størrelsen på bufferområder). På Linux kreves det i tillegg at biblioteket libcap.so er tilgjengelig. Dette biblioteket må være installer for at dette alternativet skal fungere. Hvis dette alternativet slås på, og biblioteket ikke finnes på systemet, vil DB2 UDB deaktivere de store sidene i kjernen og fortsette som før. Oppgi denne kommandoen for å kontrollere om store sider i kjernen er tilgjengelig på Linux: cat /proc/meminfo Hvis det er tilgjengelig, skal disse tre linjene vises (tallen vil være forskjellige, avhengig av mengden minne som er konfigurert på maskinen): HugePages_Total: 200
HugePages_Free: 200
Hugepagesize: 16384 KB
Hvis disse linjene ikke vises, eller verdien for HugePages_Total er 0, må operativsystemet eller kjernen konfigureres. |
||
Denne oppdateringen gjelder for emnet "SQL compiler variables" i Appendix A "DB2 registry and environment variables" i boken Administration Guide: Performance:
Hvis begge eller en av DB2-kompilatorvariablene DB2_MINIMIZE_LISTPREFETCH og DB2_INLIST_TO_NLJN, er satt til ON, vil de forbli aktive selv om REOPT(ONCE) blir oppgitt.
Dette er oppdateringer til dokumentasjonen for konfigurasjonsparametere:
Konfigurasjonsparameteren Autentiseringstype (authentication) for databasesystemet godtar også disse verdiene:
Tjeneren godtar kryptert SERVER-autentiseringsoppsett og kryptering av brukerdata. Autentiseringen virker på samme måte som SERVER_ENCRYPT.
Disse brukerdataene blir kryptert når du bruker denne autentiseringstypen:
Tjeneren godtar kryptert SERVER-autentiseringsoppsett og kryptering av brukerdata. I tillegg gir denne autentiseringstypen kompatibilitet med tidligere produkter som ikke støtter autentiseringstypen DATA_ENCRYPT. Disse produktene får tillatelse til å koble seg til med autentiseringstypen SERVER_ENCRYPT og trenger ikke å kryptere brukerdata. Produkter som støtter den nye autentiseringstypen, må bruke den. Denne autentiseringstypen er bare gyldig i tjenerens konfigurasjonsfil for databasesystemet og er ikke gyldig når den brukes på kommandoen CATALOG DATABASE.
Fra og med DB2 Universal Database versjon 8.2 endres standardverdien for konfigurasjonsparameteren Regler for innvirkning på forekomst (util_impact_lim) fra 100 til 10.
Disse konfigurasjonsparameterne for databasesystemet kan godta gruppenavn på 30 byte (eller mindre) på alle plattformer:
Tabellen i emnet "Sammendrag av konfigurasjonsparametere for databasesystemet" inneholder feil datatyper for disse konfigurasjonsparameterne. Riktig verdi i alle tilfeller er char(30).
Maksimumsstørrelse for konfigurasjonsparameteren Størrelse på minnesegment for utvidet lager (estore_seg_size) på Windows-baserte plattformer er 16 777 216.
Riktig øvre grense for konfigurasjonsparameteren HADR-tidsgrenseverdi (hadr_timeout) er 4 294 967 295.
I dokumentasjonen for konfigurasjonsparameteren Største minneområde for låsliste (locklist) står det at maksimumsverdien for 64-bits og 32-bits Windows-tjenere som betjener bare lokale klienter, er 60 000. Denne verdien er feil, og skal være 524 288.
Verdiområdet for konfigurasjonsparameteren Antall reservekopier av database (num_db_backups er feil. Riktig område er 0 - 32 767.
Etter migreringen til DB2 Universal Database (UDB) versjon 8.2 fra versjon 8.1 bruker DB2 UDB en ny konfigurasjonsparameterfil på 16 kB med navnet SQLDBCONF. (I versjon 8.1 var konfigurasjonsparameterfilen på bare 4 kB og hadde navnet SQLDBCON).
Fra og med versjon 8.1 er registervariabelen DB2_HASH_JOIN satt til ON som standard.
HASH-JOIN-variabelen bør brukes, men den må justeres for å få best mulig ytelse.
HASH-JOIN-ytelsen blir best hvis du kan unngå HASH-sløyfer og overflyt til lager. Når du skal tilpasse HASH-JOIN-ytelsen, må du anslå den maksimale minnestørrelsen som er tilgjengelig for sheapthres-parameteren, og deretter tilpasse sortheap-parameteren. Øk parameterverdien til du unngår så mange HASH-sløyfer og lageroverflyt som mulig, samtidig som du ikke når opp til grensen som er definert med sheapthres-parameteren.
Du finner mer informasjon om dette i emnet "Join methods" i boken Administration Guide: Performance.
Funksjonaliteten som tidligere ble oppnådd gjennom DB2NTNOCACHE kan oppnås på tabellplassnivå ved å oppgi leddet NO FILE SYSTEM CACHING for setningen CREATE TABLESPACE eller ALTER TABLESPACE. Se i SQL Reference hvis du vil ha flere opplysninger. Registervariabelen DB2NTNOCACHE vil bli fjernet i en fremtidig utgave.
Forklaringstabeller kan være felles for flere brukere. Imidlertid kan forklaringstabellene være definert for en bruker, og kallenavn kan defineres for hver tilleggsbruker som bruker samme navn for å peke på de definerte tabellene. Forklaringstabellene kan også defineres under skjemaet SYSTOOLS. Forklaringsfunksjonen bruker SYSTOOLS-skjemaet som standard hvis ingen andre forklaringstabeller eller kallenavn blir funnet under brukerens sesjons-ID for dynamisk SQL eller setningens autorisasjons-ID for statisk SQL. Alle brukerne som deler felles forklaringstabeller må ha tillatelse til å sette inn data i tabellene. Lesetillatelser for felles forklaringstabeller bør også være begrenset, som for brukere som analyserer forklaringsinformasjonen.
Forklaringsdata registreres hvis du ber om det når en SQL-setning kompileres. Du bør vurdere hvordan du har tenkt å bruke den registrerte informasjon når du ber om forklaringsdata.
Forklaringstabellinformasjon registreres i disse tilfellene:
Parameteren collate_info kan bare vises ved hjelp av APIen db2CfgGet. Den kan ikke vises ved hjelp av kommandolinjebehandler eller Kontrollsenter.
Denne parameteren sørger for 260 byte med sorteringsinformasjon for databasen. De første 256 byte spesifiserer sorteringsrekkefølgen for databasen, der byte "n" inneholder prioriteten til kodeverdien som har en underliggende desimalfremstilling lik "n" i kodesettet til databasen.
De siste 4 byte inneholder intern informasjon om typen sorteringsrekkefølge. De siste 4 byte i collate_info er et heltall. Dette heltallet tar hensyn til endian-rekkefølgen til plattformen. Mulige verdier:
Hvis du bruker denne typen intern informasjon, er det nødvendig å vurdere bytereversering ved henting av informasjon for en database som bruker en annen plattform.
Du kan oppgi sorteringsrekkefølgen når databasen blir opprettes.
Fra og med DB2 Universal Database (UDB) versjon 8.2 kan du bruke AUTOMATISK størrelse på forhåndshenting for en tabellplass. DB2 UDB oppdaterer automatisk størrelse på forhåndshenting når antall containere endres for tabellplassen.
Syntaksen for registervariabelen DB2_PARALLEL_IO er utvidet slik at den gjenkjenner containere med ulike egenskaper for parallell I/U-behandling. Ved hjelp av den utvidede syntaksen kan containere for ulike tabellplasser ha ulike egenskaper for parallell I/U-behandling. Egenskapene for parallell I/U-behandling for hver tabellplass blir bruke når det er oppgitt AUTOMATISK størrelse på forhåndshenting for tabellplassen. Hvis registervariabelen DB2_PARALLEL_IO er aktivert, men den utvidede syntaksen som identifiserer bestemte egenskaper for parallell I/U-behandling ikke er brukt, antar systemet et standardnivå for parallellbehandlingen. Standardnivået er RAID 5 (6+1).
Informasjonen om størrelsen på forhåndshenting som brukes av optimalisatoren, blir bare oppdatert når det blir gitt en ALTER TABLESPACE-setning som endrer størrelsen på forhåndshenting for en tabellplass eller endrer antall containere (med ADD/DROP/BEGIN NEW STRIPE SET/ADD TO NEW STRIPE SET). Hvis registerinnstillingene for antall fysiske lagre per container endres, bør det gis en ALTER TABLESPACE <tabellplassnavn> PREFETCHSIZE AUTOMATIC-setning for å oppdatere optimalisatorinformasjonen (med mindre det allerede er gitt en ALTER TABLESPACE-setning som oppdaterer optimalisatorinformasjonen).
Hvis en tabellplass blir omdirigert eller gjenopprettet for å bruke et annet antall containere, kan du oppdatere optimalisatorinformasjonen ved hjelp av en ALTER TABLESPACE <tabellplassnavn> PREFETCHSIZE AUTOMATIC-setning. Hvis det finnes flere stripesett i en tabellplass, brukes det maksimale antall containere i stripesettene til å beregnet størrelsen på forhåndshenting. Hvis den beregnede størrelsen på forhåndshenting overskrider maksimumsstørrelsen (32 767 sider), brukes det største antall containere som er mindre enn maksimumsstørrelsen, som størrelse på forhåndshenting.
I et DB2 UDB Enterprise Server Edition-miljø er det slik at hvis en tabellplass bruker en AUTOMATISK størrelse på forhåndshenting, kan denne størrelsen være forskjellig på forskjellige databasepartisjoner. Denne situasjonen kan oppstå fordi forskjellige databasepartisjoner kan ha et ulikt antall containere som brukes til beregning av størrelsen på forhåndshenting. Når optimalisatoren skal generere en tilgangsplan for spørringer, bruker den størrelsen på forhåndshenting fra den første partisjonen i en databasepartisjonsgruppe.
[ Øverst på siden |Forrige side | Neste side | Innhold ]