>>-UPDATE QP_SYSTEM USING--------------------------------------->
>--+-DEFAULT------------------------------+--------------------><
'-CREATE_RESULT_TABLE_ALIASES--+-'Y'-+-'
'-'N'-'
Det blir returnert en varselmelding når en av disse oppgavene blir utført via Query Patroller-senteret eller Query Patroller-kommandolinjen:
Dette er varselmeldingen:
DQP1024W Creation, change, or removal of a query class will not
take effect until the Query Patroller server is restarted.
I boken DB2 Query Patroller Guide: Installation, Administration, and Usage, Version 8.2, står det også at du må starte Query Patroller-tjeneren på nytt etter at du har opprettet, endret eller fjernet spørreklasser, for at endringene skal bli tatt i bruk.
Denne meldingen og forklaringen i boken er ikke helt korrekte lenger. De tre spørreklasseoppgavene ovenfor vil bli aktivert umiddelbart med mindre det er aktive spørringer eller spørringer i kø. Hvis det er aktive spørringer eller spørringer i kø, inkludert nylig sendte spørringer, blir spørreklasseendringene tatt i bruk når disse spørringene er utført. Hvis du ikke vil vente til alle aktive spørringer eller spørringer i kø er fullført, må du starte Query Patroller-tjeneren på nytt.
Betydningen for spørrestatusene Canceled og Done er oppdatert slik:
Når du kjører generatoren for historikkdata for Query Patroller og forklaringstabellene ikke allerede finnes, oppretter generatoren dem for deg. Du bør imidlertid opprette forklaringstabellene før du kjører generatoren for historikkdata. Når du oppretter forklaringstabellene, må du passe på at du oppretter dem på samme partisjon. Hvis du oppretter forklaringstabellene selv på samme partisjon, får du bedre ytelse i forklaringsfunksjonen. Denne forbedringen øker også ytelsen til generatoren for historikkdata.
Hvis kolonnen Explain kjørt i rapporten Spørringsaktivitet over tid (Historisk analyse) viser statusen Kjørt med feil for en spørring, er det ikke generert historiske data for den spørringen. Derfor vil ikke spørringen blir vist i noen rapporter eller diagrammer for historisk analyse. Som det er beskrevet i versjon 8, kan du se i filen qpuser.log for å finne ut hvorfor det oppstod feil med spørringen.
I tillegg til å se i filen qpuser.log kan du også se i filen qpdiag.log.
Hvis du kjører generatoren for historikkdata og avslutter den på en unormal måte, får du en feilmelding neste gang du forsøker å kjøre generatoren. Dette er eksempler på unormal avslutning:
Når generatoren for historikkdata avsluttes unormalt, må du gi følgende kommando før du forsøker å kjøre generatoren for historikkdata på nytt:
qp -d database generate historical_data stopder database angir databasen som kommandoen skal kjøres mot.
Enkelte spørreklasseoperasjoner krever ikke lenger at Query Patroller blir stoppet og startet på nytt for at de skal bli tatt i bruk.
I tabellen nedenfor er en aktiv spørring en spørring med statusen Kjører eller I kø.
Nestede spørringer kan ikke legges i kø. I stedet blir en nestet spørring kjørt umiddelbart hvis den overskrider terskelen som normalt ville ha ført til at den ble lagt i kø.
I motsetning til hva som har stått i tidligere dokumentasjon, kan spørringer med disse setningene legges i kø:
Når du bruker Terminal Services Client ved en oppløsning på 640x480 for tilkobling til en fjerntliggende bordmodellmaskin som kjører Query Patroller Center, er det mulig at vinduet Submission Preferences er tomt. For at vinduet Submission Preferences skal vises ordentlig, må du bruke en høyere oppløsning enn 640x480.
Fra og med versjon 8.2 støtter DB2 Universal Database (UDB) brukergrupper utover operativsystemets brukergrupper. Det er derfor en liten endring i valglisten Submitter Profile to Use i vinduet Query Submission Preferences i Query Patroller-senteret.
Hvis du er logget på, men ikke har DBADM-autorisasjon eller redigeringsrettighet for Query Patrollers brukeradministrasjon, kan du bare tilføye eller oppdatere en innsendingsinnstilling for deg selv. I dette tilfellet inneholder valglisten Submitter Profile to Use eksisterende innsenderprofiler i DB2 UDB-gruppene du tilhører, i stedet for bare operativsystemgruppene du tilhører.
Hvis du er logget på og har DBADM-autorisasjon eller redigeringsrettighet for Query Patrollers brukeradministrasjon, kan du tilføye eller oppdatere innsendingsinnstillinger for andre brukere. I dette tilfellet viser valglisten Submitter Profile to Use alle eksisterende gruppeinnsenderprofiler.
Når du arbeider med planer i Query Patroller-senteret, kan du bruke vinduet Schedule til å lagre planer i en fil og importere dem senere. Hvis du har en plan som du har lagret med opprettingspakke 6 eller tidligere, kan du ikke importere planen med versjon 8.2 eller senere. Denne begrensningen skuldes endringen i serieomkoding mellom JDK-nivåer innført med DB2 UDB versjon 8.2.
For å utføre kommandoen RUN IN BACKGROUND QUERY å du være den innsenderen som opprinnelig sendte inn spørringen.
I Query Patroller versjon 8.1 opprettingspakke 5 sluttet Query Patroller å opprette resultattabeller i skjemaet som samsvarte med autorisasjons-IDen til den som sendte spørringen. I stedet begynte Query Patroller å opprette resultattabeller i et felles DB2QPRT-skjema. For å gjøre det mulig å referere til resultattabeller med innsenderens skjema innfører Query Patroller versjon 8.2 et alternativ for automatisk opprettelse av kallenavn for hver nye resultattabell som Query Patroller oppretter. Resultattabellen opprettes i skjemaet DB2QPRT, og kallenavnet opprettes i et skjema som samsvarer med innsenderens autorisasjons-ID.
Du kan slå dette alternativet på eller av ved å kjøre kommandoen UPDATE QP_SYSTEM med alternativet CREATE_RESULT_TABLE_ALIASES:
Kallenavn som er opprettet med alternativet CREATE_RESULT_TABLE_ALIASES, blir automatisk slettet når en resultattabell slettes. Det er imidlertid to situasjoner der en resultattabell kan bli slettet uten at tilsvarende kallenavn slettes:
For å rydde opp i kallenavn som ikke har noen tilsvarende resultattabeller, er det opprettet en ny kommando, REMOVE RESULT_TABLE_ALIASES. Denne kommandoen utføres automatisk når resultattabeller slettes som en del av Query Patrollers planlagte prosess for sletting av resultattabeller. Kommandoen REMOVE RESULT_TABLE_ALIASES henter listen over kallenavn som skal slettes, ved hjelp av følgende spørring:
with a as (select tabschema, tabname from syscat.tables
where type = 'A' and tabname like 'QUERY%_RESULTS'),
t as (select tabname from syscat.tables
where type = 'T' and tabname like 'QUERY%_RESULTS')
select all tabschema, tabname from a
where not exists (select * from t where t.tabname=a.tabname)
Du må ha DBADM-autorisasjon.
Denne kommandoen fjerner alle kallenavn som finnes etter at deres tilsvarende resultattabeller er blitt slettet. Kallenavnene ble opprinnelig opprettet av Query Patroller for resultattabeller.
Query Patroller bruker noen beskyttede lagrede prosedyrer som kan føre inn loggposter i filen qpdiag.log. Derfor må den beskyttede bruker-IDen ha skrivetilgang til filen qpdiag.log og banen der filen qpdiag.log ligger.
[ Øverst på siden |Forrige side | Neste side | Innhold ]