>>-UPDATE QP_SYSTEM USING--------------------------------------->
>--+-DEFAULT------------------------------+--------------------><
'-CREATE_RESULT_TABLE_ALIASES--+-'Y'-+-'
'-'N'-'
A rendszer figyelmeztető üzenetet küld, ha a következő feladatok valamelyikének végrehajtása a Query Patroller Center vagy a Query Patroller parancssor segítségével történik:
A figyelmeztető üzenet a következő:
DQP1024W A lekérdezési osztály létrehozása, módosítása, illetve eltávolítása nem
történik meg, amíg újra nem indítja a Query Patroller kiszolgálót.
Ehhez hasonlóan a 8.2-es verziójú DB2 Query Patroller(TM) útmutató: Telepítés, adminisztráció és használat kiadványban szerepel, hogy a Query Patroller kiszolgálót lekérdezési osztályok létrehozását, módosítását, illetve eltávolítását követően újra kell indítani a változások életbe léptetéséhez.
Az útmutatóban szereplő üzenet és az utasítás nem pontos. A korábban felsorolt, lekérdezési osztállyal kapcsolatos három feladat végrehajtása azonnal megtörténik, hacsak nincsenek várakoztatott vagy futó lekérdezések. Ha a rendszerben vannak várakoztatott vagy futó lekérdezések, köztük újonnan elküldött lekérdezések, a lekérdezési osztály módosításai akkor lépnek életbe, ha a várakoztatott vagy futó lekérdezések futása befejeződött. Ha nem kívánja megvárni a várakoztatott és futó lekérdezések futásának befejezését, újra kell indítania a Query Patroller kiszolgálót.
A Canceled (Törölve) és a Done (Kész) lekérdezési állapot jelentése a következők szerint módosult:
A Query Patroller historikus adat generátor programját futtatva a magyarázó táblák még nem léteznek, a generátor program létrehozza azokat. Azonban igencsak javasolt, hogy még a historikus adat generátor futtatása előtt hozza létre a magyarázó táblákat. A magyarázó táblák létrehozásakor ügyeljen arra, hogy ugyanazon a partíción jöjjenek létre. Ha a magyarázó táblák aktív módon, ugyanazon a partíción jönnek létre, az növeli az Explain szolgáltatás teljesítményét. Ez a javítás növeli a historikus adat generátor teljesítményét.
Ha Query Activity over Time (Historical Analysis) jelentés Explain Run oszlopa Ran unsuccessfully állapotot jelez egy lekérdezés esetében, akkor nem sikerült előállítani az adott lekérdezésre vonatkozó adatokat. Emiatt a lekérdezés nem jelenik meg egyetlen Historical Analysis jelentésben vagy grafikonon sem. A 8-as verzió dokumentációjában foglaltak szerint, ha meg kívánja ismerni a lekérdezés sikertelenségének okát, átnézheti a qpuser.log fájlt.
A qpuser.log fájl vizsgálata mellett a qpdiag.log fájlt is meg kell tekinteni.
Ha a historikus adat generátort rendellenesen állítja le, a program következő indításakor hibaüzenetet fog kapni. Az abnormális lezárás a következőket foglalja magába:
Ha a historikus adat generátor rendellenesen áll le, annak újraindítása előtt ki kell adnia a következő parancsot:
qp -d adatbázis generate historical_data stop
ahol adatbázis az az adatbázis, amelyre a parancsot futtatja.
Némely lekérdezésosztály művelethez már nem szükséges a Query Patroller leállítása és újraindítása.
A következő táblában az aktív lekérdezés olyan lekérdezés, amely állapota Running (futó) vagy Queued (várakozó).
A beágyazott lekérdezések nem várakoztathatók. Egy beágyazott lekérdezés ehelyett azonnal lefut, ha átlépi azt a küszöböt, amely után normális esetben várakozási sorba kerülne.
Az előző dokumentációval ellentétben, a következő utasításokat tartalmazó lekérdezések várakoztathatók:
Ha a Terminal Services Client ügyfelet 640x480 képpontos felbontásban használja olyan távoli munkaasztalhoz való csatlakozásra, amelyen fut a Query Patroller központ, a Submission Preferences (Küldési beállítások) ablak üresen fog megjelenni. Ahhoz, hogy ez az ablak megfelelően jelenjen meg, a 640x480 képpontnál nagyobb felbontást kell használnia.
A 8.2-es verziótól kezdve a DB2 Universal Database (UDB) a felhasználói csoportokat az operációs rendszeri csoportokon túl támogatja. Ezért egy kis módosulás van a Submitter Profile to Use (Használni kívánt küldési profil) legördülő listában a Query Submission Preferences (Lekérdezések küldési beállítási) ablakban, a Query Patroller központban.
Ha be van jelentkezve, de nincs sem DBADM jogosultsága, sem Edit joga a Query Patroller felhasználói adminisztrációjához, akkor csak magának vehet fel vagy frissíthet küldési beállítást. Ebben az esetben a Submitter Profile to Use (Használandó küldőprofil) legördülő lista a felhasználó DB2 UDB csoportjainak meglévő küldési profiljait tartalmazza, az operációs rendszeri csoportjai helyett.
Ha be van jelentkezve, és rendelkezik DBADM vagy Edit jogosultsággal a Query Patroller felhasználói adminisztrációjához, akkor más felhasználóknak is felvehet vagy frissíthet küldési beállításokat. Ebben az esetben a Submitter Profile to Use legördülő lista minden létező csoport küldési profiljait tartalmazza.
Ha a Query Patroller központban ütemezésekkel dolgozik, a Schedule (Ütemezés) ablakban fájlba mentheti az ütemezéseket, hogy később importálhassa azokat. Ha olyan ütemezéssel rendelkezik, melynek mentését 6-os vagy korábbi FixPak javítócsomaggal hajtotta végre, azt nem importálhatja 8.2-es vagy újabb verzióval. Ez a korlátozás a DB2 UDB 8.2-es verziójában bevezetett változtatás miatt van, amely a JDK szintek közti sorosítást érinti.
A RUN IN BACKGROUND QUERY parancs futtatásához az szükséges, hogy a lekérdezést eredetileg elküldő személy legyen a küldő.
A Query Patroller 8.1-es verzió 5-ös javítócsomagtól kezdve a Query Patroller nem hoz létre eredménytáblákat abban a sémában, amely megfelel a lekérdezés küldőjének hitelesítési azonosítójának. Ehelyett a Query Patroller az eredménytáblákat egy közös DB2QPRT sémaban hozza Létre. Ahhoz, hogy az eredménytáblákra a küldő sémájával lehessen hivatkozni, a Query Patroller 8.2-es verziójában bevezettek egy beállítást, mely automatikusan létrehoz egy fedőnevet minden egyes új eredménytáblához, amelyet a Query Patroller készít. Az eredménytábla a DB2QPRT sémában jön létre, a fedőnév pedig egy olyan sémában készül, amely megfelel a küldő hitelesítési azonosítójának.
Ezen beállítási ki- vagy bekapcsolásához adja ki az UPDATE QP_SYSTEM parancsot a CREATE_RESULT_TABLE_ALIASES beállítással:
A CREATE_RESULT_TABLE_ALIASES beállítással létrehozott fedőnevek automatikusan eldobásra kerülnek az eredménytábla eldobásakor. Van azonban két olyan eset, amikor az eredménytábla eldobásakor nem következik be a hozzátartozó fedőnév automatikus eldobása.
Azon fedőnevek eltávolítását, amelyekhez nem tartozik eredménytábla, egy új paranccsal lehet végrehajtani: REMOVE RESULT_TABLE_ALIASES. Ez a parancs automatikusan végrehajtódik, amikor eredménytáblák törlésre kerülnek a Query Patroller ütemezett eredménytábla-eltávolító folyamata során. A REMOVE RESULT_TABLE_ALIASES parancs az alábbi lekérdezéssel szerzi meg a törlendő fedőnevek listáját:
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)
DBADM jogosultsággal kell rendelkeznie.
Ez a parancs töröl minden olyan fedőnevet, amely még azután is él, hogy a hozzátartozó eredménytábla már el lett dobva. A fedőneveket eredetileg a Query Patroller hozta létre az eredménytáblákhoz.
A Query Patroller elhatárolt tárolt eljárás eljárásokat használ, melyek bejegyzéseket naplózhatnak a qpdiag.log fájlba. Ebből kifolyólag az elhatárolt felhasználó azonosítójának írási hozzáféréssel kell rendelkeznie a qpdiag.log fájlhoz és annak elérési útvonalához.
[ Oldal eleje |Előző oldal | Következő oldal | Tartalom ]