Prepared SQL vs Stored Procedure
Hali
most nyeltem be egy axapta adatbázis admisztrációs feladatot. Eddig még nem volt tapasztalatom Axapta adatbázissal, és lenne egy kérdésem:
Előírás az Axapta fejlesztéshez, hogy kizárólag Prepared SQL kérésekkel bombázzák az adatbázist, vagy lehetne használni SP-t is?
MCDEBIL
Válaszok
Megvan a válasz:
Lehet használni tárolt eljárásokat, sőt ajánlott. Egyes vélemények szerint az adatelérési műveletek áthelyezése az SQL szerverre 1000 szeresére is növelik a teljesítményt. Ha ez a tetemes teljesítménynövekedés így hihetetlen lenne valaki számára gondoljunk arra, hogy a töredéke is jelentős telejesítménynövekedésnek számít.
A teljesítménynövekedés számomra, mint adatázis adminisztrátor, biztosnak látszik amennyiben az SQL szerverre hárítjuk át a teljes adatelérési és adatmanipulációs feladatokat. A Microsoft ajánlások az adatbázis alapú alkalmazások fejlesztésére is ezt támasztják alá.
Másik nagy teljesítményt csökkentő tényező, amit tapasztaltam, az a kurzor használat X++-ból. A kommunikáció a kurzor léptetésnél nagyságrendekkel több időt igényel, mint maga az adatművelet. A felhasználók közben meg a homokórát bámulják. Ez is elkerülhető az adatelérési feladatok SQL szerveren történő végrehajtásával.
A legszebb amit tapasztaltam az a tranzakció kezelése a fejlesztők által. Minden eljárás, funkció ha kell ha nem ttsbegin-nel kezdődik, és a ttscommit csak a végén zárja le a tranzakciót. Ez nagy mértékben növeli a blokkolások miatti teljesítmény csökkenést. Jellemző példa: egy Batch feladat az általam üzemeltetett rendszeren két és fél órás futásideje alatt fokozatosan megállította a felhasználói munkavégzést. Az egy nagy tranzakció megszüntetése és a szükséges műveletknél alkalmazott tranzakció használat a feladat futásidejét tíz percre csökkentette és a felhasználók blokkolása eltűnt.
Összefoglalva: csókoltatom az axapta fejlesztőket, és kérem tanuljanak egy kis adatbáziskezelést is.
- Ahoi,
Ugyan nem vagyok adatbázis szakértő, max fejlesztője az Axaptanak, de azt hozzátenném ehhez, hogy noha teljes mértékben igazad van, jelentősen leegyszerűsíted a kérdést.
Ez a megállapítás jellemzően olyan riportok, lekérdezések esetén álja meg a helyét, ahol olyan táblát kell query-be fogni az Axapta egy riportjához (joinal vagy anélkül, while selectben, vagy select firstfastban, index-el lehetőleg) amelyeket futási időben az alkalmazás más részei update-re megnyitnak. Pl. InventSum tábla lehet ilyen, de pl. a LedgerTrans táblát csak "írják" a felhasználók, update nem lehet rá egy standard alkalmazásban.
Egy biztos, AX kicsit pazarló és hanyag módon kezeli az adatbázis kapcsolatot emiatt nem lehet oly hatékony (itt én is csókoltatom a tervező mérnököket), mintha belül az adatbázisban végeznénk el, azaz az alkalmazás logika az adatbázisban lenne. De mivel az alapelv az, hogy külön van az alkalmazás és az adatbázis, így ezzel együtt kell élni.
Az indexek használata jelentősen javít az adateléréseken, riportokra lehet külön naponta másolt adatbázist használni (mini BW szerű), valamint a fejlesztőnek felelőssége a lehetőségekhez mérten optimális kódot írnia. Ez lehet sajna időnként gyenge pont, tekintettel arra, hogy a szintaktikát könnyű elsajátítani X++ban, de a működésének megismeréséhez egy év ajánlott.
Tapasztalatom szerint egy évente 50-60 ezer számlát kiállító alkalmazás (számlánként 5-10 sor átlag) számla könyvelési sebessége kb 5-10 másodperc (gombnyomástól a nyomtató felzümmögéséig) erősen átalakított könyveléssel (bővített funkciónalitás). Ez szerintem elfogadható. Egy Tescoban persze ez azért rossz szintidőnek minősülne.
Üdv,
Bandi
Az összes válasz
Hát nem nagy a tolongás!
Öröm debuggolni egy olyan alkalmazás adatbázis műveleteit ahol az inputbuffer a következőket nyomja FETC API_CURSOR00000000... közben meg sírnak a felhasználók, hogy lefagyott az alkalmazás. A fejlesztők meg azt hajtogatják, hogy ez csak így oldható meg.
Megvan a válasz:
Lehet használni tárolt eljárásokat, sőt ajánlott. Egyes vélemények szerint az adatelérési műveletek áthelyezése az SQL szerverre 1000 szeresére is növelik a teljesítményt. Ha ez a tetemes teljesítménynövekedés így hihetetlen lenne valaki számára gondoljunk arra, hogy a töredéke is jelentős telejesítménynövekedésnek számít.
A teljesítménynövekedés számomra, mint adatázis adminisztrátor, biztosnak látszik amennyiben az SQL szerverre hárítjuk át a teljes adatelérési és adatmanipulációs feladatokat. A Microsoft ajánlások az adatbázis alapú alkalmazások fejlesztésére is ezt támasztják alá.
Másik nagy teljesítményt csökkentő tényező, amit tapasztaltam, az a kurzor használat X++-ból. A kommunikáció a kurzor léptetésnél nagyságrendekkel több időt igényel, mint maga az adatművelet. A felhasználók közben meg a homokórát bámulják. Ez is elkerülhető az adatelérési feladatok SQL szerveren történő végrehajtásával.
A legszebb amit tapasztaltam az a tranzakció kezelése a fejlesztők által. Minden eljárás, funkció ha kell ha nem ttsbegin-nel kezdődik, és a ttscommit csak a végén zárja le a tranzakciót. Ez nagy mértékben növeli a blokkolások miatti teljesítmény csökkenést. Jellemző példa: egy Batch feladat az általam üzemeltetett rendszeren két és fél órás futásideje alatt fokozatosan megállította a felhasználói munkavégzést. Az egy nagy tranzakció megszüntetése és a szükséges műveletknél alkalmazott tranzakció használat a feladat futásidejét tíz percre csökkentette és a felhasználók blokkolása eltűnt.
Összefoglalva: csókoltatom az axapta fejlesztőket, és kérem tanuljanak egy kis adatbáziskezelést is.
- Ahoi,
Ugyan nem vagyok adatbázis szakértő, max fejlesztője az Axaptanak, de azt hozzátenném ehhez, hogy noha teljes mértékben igazad van, jelentősen leegyszerűsíted a kérdést.
Ez a megállapítás jellemzően olyan riportok, lekérdezések esetén álja meg a helyét, ahol olyan táblát kell query-be fogni az Axapta egy riportjához (joinal vagy anélkül, while selectben, vagy select firstfastban, index-el lehetőleg) amelyeket futási időben az alkalmazás más részei update-re megnyitnak. Pl. InventSum tábla lehet ilyen, de pl. a LedgerTrans táblát csak "írják" a felhasználók, update nem lehet rá egy standard alkalmazásban.
Egy biztos, AX kicsit pazarló és hanyag módon kezeli az adatbázis kapcsolatot emiatt nem lehet oly hatékony (itt én is csókoltatom a tervező mérnököket), mintha belül az adatbázisban végeznénk el, azaz az alkalmazás logika az adatbázisban lenne. De mivel az alapelv az, hogy külön van az alkalmazás és az adatbázis, így ezzel együtt kell élni.
Az indexek használata jelentősen javít az adateléréseken, riportokra lehet külön naponta másolt adatbázist használni (mini BW szerű), valamint a fejlesztőnek felelőssége a lehetőségekhez mérten optimális kódot írnia. Ez lehet sajna időnként gyenge pont, tekintettel arra, hogy a szintaktikát könnyű elsajátítani X++ban, de a működésének megismeréséhez egy év ajánlott.
Tapasztalatom szerint egy évente 50-60 ezer számlát kiállító alkalmazás (számlánként 5-10 sor átlag) számla könyvelési sebessége kb 5-10 másodperc (gombnyomástól a nyomtató felzümmögéséig) erősen átalakított könyveléssel (bővített funkciónalitás). Ez szerintem elfogadható. Egy Tescoban persze ez azért rossz szintidőnek minősülne.
Üdv,
Bandi Hali,
végre valami mozgás. Amit írsz az világos és érthető. (Nem úgy mint az, hogy a Microsoft miért nem javít a helyzeten.) Azt tudom, hogy a jelenlegi helyzetben nem lehet minden adatműveletet átírni, de az ésszerű költségeken belül érdemes foglalkozni vele.
Az viszont nagyon érdekelne, hogy a server side cursor használatának csökkentésére tudsz-e (tud-e valaki) valamit javasolni.
Az már biztos, hogy a nyakamba sózott rendszer lassúsága a fejlesztők szégyene. Még tiszta X++ kódban is lehetne jóval jobb válaszidőkkel futtatni a funkciókat. Sajnos gyatra fejlesztő csapatot fogtam ki. Pl.: felesleges és túl nagy tranzakciók használata, az Oracle rule base adatbázisokon jól működő, de SQL szerveren inkább hátrányos explicit index hint használata, stb. Nálunk sajnos a válaszidőket nem másodpercben, hanem percben mérik, már amikor nincs olyan mértékű blokkolás, hogy öt percen belül már csak a blokkoló processz tud dolgozni, a többi 30 felhasználó meg dühöng, míg ki nem lövöm a blokkoló processzt. (ez persze nem egy finom megoldás)
Nekem nem igazán a néhány rekordot módosító- beszúró funkciókkal van a gondom, hanem a több száz rekord egyenkénti kezelésével járó futásidőkkel. Néhány napja tesztelünk egy batch job-ot, ami jelenleg több mint másfél órát fut, és egy mezőt módosít (kiválaszt egy értéket az előre meghatározott 5 lehetségesből egy meghatározott feltéterendszer szerint) egy táblán kiválasztott rekorokon.
Ez tipikusan egy tárolt eljárás feladataként nagyon jól megoldható, az érték kiválasztásához egy függvényt használva.
A teszt során a tárolt eljárás 6 és fél perc alatt végzett, míg az eredeti X++ eljárás 1 óra 8 percet futott. Ez alapján most a problémásabb funkciókat kezdtük átnézni, hogy átíthatók vagy sem tárolt eljárássá.
Többet most nem írok, mert az már regény lenne. Ha találok valami okosságot azt majd megírom később.
MCDEBIL
- Nu, a kedvencem, az én kissszzz dráhhgahhszzágomtól
Lassúllás
Szóval és tetvel, mielőtt elkezdenénk komolyan barkácsolni pár dolgot érdemes a lassulásnál kizárni, ellenőrizni, elemezni, végig szenvedni:
1. hálózat és annak szűk keresztmetszetei, javasolt trace-t indítani a háló különbözően távoli pontjairól az AOS felé, és nézni a válaszidőket. Mindezt egy kis batch file írásával oldjuk meg, átirányítva az output-ot egy log file-ba, ha van rá hálózati célmegoldás, természetesen akkor azzal ami ekvivalens
A logokat elemezve (macerás meló...) ezt ki lehet így zárni. Ez is sok mindentől függ, pl. Budapest dárga szépséges belvárosában 2 háztömbnyi távolságon 120 milisecundumtól 500-ig mértünk legutóbb... no comment délelőtt 10-14 óra között, nem ÁFA vagy SZJA bevallási időszakban, Karácsony, húsvét szintén kizárva ez alól.
A hálóban célszerű dedikálni az alkalmazás és a kliensek közötti axapta kommunikációnak 60 K-t userenként... 40 elég szokott lenni, vagy 50 konkurens user / 1 Mbit. Terminál szerveres elérés esetén a terminál és az alkalmazás közé kell rakni vastag kábelt
2. kapcsolat az alkalmazás AOS szervere és az SQL szerver között. Gigabites kapcsolat ajánlott az álmoskönyv szerint. Továbbá az alkalmazást és az adatbázist két külön vason kell futtatni. SQL mondjuk 5-ös RAID kegyetlen gyors vinyókkal, 8 giga RAM-ot kényelmesen elfogyasztgat. Reporting szerver általában e mellé még elfér ugyan azon a vason.
3. szerverek felépítése. AOS-nél veszett gyors feltöltési sebességű hálókártya kell a kliens gépek (terminál szerver) és ő közé. Az alap architektúra miatt ez a gyenge pont, mivel a kliens kis adat-utasítás csomagokkal bombázza az AOS-t, aki utána elcseveg az adatbázissal, és vissza küldi a megoldást. AOS kötelező architektúrális elem! mivel cache-el adatokat, így rettentő látványosan javítja az elérést.
4. SQL trace-t kapcsolni befelé mind a klienseken, mind az AOS-en és várni... figyelni... ezt az Axaptan belül kell beállítani, sztem 100 milisec fölötti futású SQL válaszidőkre, és ezt átirányítani file-ba. Utána elemezni (ez kicsivel jobb mint a trace file log elemzés) Ez a log megmutatja, hogy milyen Táblára milyen query select vagy egyéb borzalom milyen idő alatt futott és mi volt a forráskód utasítás verme ekkor. Utána, ezeken a táblákon végig ballagni az Axapta AOT-ben, és indexet gyártani. Ezt üzemidőn kívül ajánlott. A táblák indexeinek használata mellett a forráskódot is át kell nézni, beállítva az indexeket. A standard AX pazarló, így célszerű megmondani az indexet neki, amire melót kell végeznie táblán. Ez a trace még jobban le fogja lassítani (látványosan!) a rendszert mint eddig, de ez sajnos szükséges áldozat a megoldás oltárán!
5. Ne fusson az SQL szerveren semmilyen más hálózati funkció!!! file gyakori irás olvasás nem az SQL által pl egy win 2003 szervert heves file katalógus újraindexelésre készteti, amitől a vas maga nagyon jól ki lesz használva (proci idő, memória, lapozás, lapolás, vinyó írás olvasás) csak az SQL szerver maga nem fog tudni erőforráshoz jutni de istenien átmozgatja a BUS-t, DMA-t és tsa-t az alaplapon
Ha ezekkel megvagyunk (kb 2 hét egy ilyen végig zongorázása) akkor még jöhetnek egyéb apróságok, pl Adatbázis beállítások optimalizálása. Erről egy blogon van mese, használ Google, stb... nálamnál okosabb emberek megmondták ennél jobban a tutit szigorúan az adatbázis szemszögéből Axapta esetére vonatkozóan.
Mind ezek után jöhet az szerintem, hogy átpakolni az adatbázisba bizonyos funkciókat, riportokat stb... amiknél az általad említett szignifikáns időbeli különbség mutatkozik, de ez SZVSZ legyen az utolsó megoldás, ha már minden kötél szakad és ezt is kegyetlenül részletesen ledokumentálva a jövő nemzedékének! tudom-tudom, ezt mindenki rühhelli, de lássuk be egy ismeretlen rendszerben csúnya kellemetlenség lehet, ha nem látja az ember fia az ilyet, mer mér nézze meg az adatbázist, ha a standard AX úgyis csak tárolásra használja, és fejleszt valamit, költözteti, upgrade-eli az alkalmazást, másolja a környezetet stb...
U.i. ha az általad említett apró funkció mondjuk 3-as Axaptaban az InventSum nevű táblára vonatkozik update-nél, akkor SQL-ben a táblán állítsd át a lok-olást rekord szintűre a tábla szintűről 4-esben ez már nem hiba, a 3-asnak ez volt a halála
Ennyi, Bandi Köszi a segítséget.
1. Majd ráveszem a network adminokat a mérésre.
2. Itt nincs gond. A 6 citrix a 8 AOS és a DB szerver egy helyen van és bika hálózaton. A DB szerver is elég erős: 4 dual core proci, 36 GB ram (32 az SQL szerveré), dedikált storage. 64 bites W2K3 + 64 bites SQL 2005 standard
3. Ez is rendben van.
4. Ezt hol lehet elérni? Axapta admin nincs a cégnél, én meg csak egy mezei DBA vagyok.
5. Kizárólag az adatbázis fut a dedikált SQL szerveren. Tehát ez is jó.
A neten én is összekeresgéltem az adatbázis beállításokat, a Microsoft ellenőrizte a beállítási tervet és ez most elvileg optimális.
A táblán hol lehet beállítani lockolási szintet? Az SQL-ben én csak az indexen tudom kikapcsolni a page level lockolást.
Azért nem minden esetben csapunk bele a tárolt eljárások használatába. Ma egy eljárás kapcsán elbeszélgettem az egyik francia fejlesztővel:
A fejlesztő úgy küldte át, hogy "Na erre varjál gombot a nagy SQL tudásoddal!"
Az eljárás (a piros már az én megjegyzésem):
Code Snippetstatic InventTrans findRecIdTransId(recId recId,InventTransId inventTransId, boolean _forUpdate = false)
{
InventTrans inventTrans;if (recId)
{
inventTrans.selectForUpdate(_forUpdate);select firstonly inventTrans
index hint RecId // Index scan-t generál, ha included columnak beteszem az inventTransId oszlopot index seek a végeredmény és fele futásidő, még index hint nélkül is 6 millió rekordon!!!!!!Az SQL Server ugyan azt a lekérdezési tervet produkálja index hint nélkül is.
where inventTrans.recId== recId &&
inventTrans.inventTransId == inventTransId;
}return inventTrans;
}
Az Axapta hibája meg az, hogy itt egyetlen rekord kiválasztására több mint négy körutazásra kerül sor az adatbázis kiszolgáló és az AOS között. Míg ha ODBC-n keresztül szednénk le ezt a rekordot az egy lépésben történne. (AX 3, tehát ha jól tudom az ADO-t nem tudja használni)
A legnagyobb hiba, hogy eszetlenül van indexelve az adatbázis amit most inkább nem részleteznék.
A missing index jelentés egy hét után már több mind 200 hiányzó vagy hibás indexet reklamál.
A másik az előzőleg bemutatott explicit index hintek használata. Ezzel már a világból is ki tudnak kergetni. ez nagyon jó egy rule base ORACLE adatbázihoz, de az SQL Query Optimizer azért nagyon jól meg tudná állapítani, melyik index a legjobb a futtatáshoz. De mereven ragaszkodnak hozzá a fejlesztők. (Mind az öt országban, mert ezt az Axaptát minden telephelyen lokálisan fejlesztik és minimális kordinációval implementálják, ami megint csak oka lehet a blokkolási és deadlock problémáimnak.)
Ráadásul ez az index hasznlat megakadályoz engem is, hogy kövessem a változásokat az adatbázisban, és időnként optimizáljam az indexeket. (És egyéb index karbantartási feladatok sem igazán segítenek így a teljesítmény optimális szinten tartásában.)
MCDEBIL (szintén Bandi)- Hááát, egy darabig vakartam a fejem a dolgon amit állítasz, lehet igazad van, nem tudom őszintén szólva. Kezdek elbizonytaladni...
Ami biztos:
SQL trace az AOS config-ot indítsd el és a Settings-be menj be. Ott menj a Database fülre, és a log file-nak jelölj ki egy állományt lehetőleg ugyan azon a gépen, ahol az SQL van, ha nem akkor az AOS által elérhető publikus meghajtón. Utána a Tracing fülön kapcsold be a Trace All SQL statements into file, majd a milisec-nél add meg a 100-at, mondjuk.
Őszintén szólva még nézd meg az Axapta útmutatót illetve F1-el a mezőket a Database fülön. Itt nézz még körül, lehet találsz valami hasznosat.
Az AOS cluster-ezés miatt el vagyok bizonytalanodva, ekkora rendszerrel még nem volt dolgom megvallom a frankót, lehet ott még vannak további lehetőségek is.
Javaslom, hogy próbáljatok keríteni egy AX partnert, vagy ha van sajátotok belföldön vagy külföldön, akkor azokat elkezdeni piszkálni ezzel a kérdéssel. Sokkalta messzebbre mutat ez a kérdés egy DB admin-nél. Szerintem te megtettél mindent, amit lehetett. Innentől szerintem egy átfogó rendszer és alkalmazás átvilágítás kellene, hogy mi is van bent a dobozban, és mit is csinál pontosan és hogyan csinálja...
Amit a fejlesztő küldött neked az egy standard kereső metódus AX-ből, teljesen normális megjelenésű, a kérdés az, hogy ebben az esetben az InventTrans tábla van e recId-re indexelve? több mint valószínű, hogy igen. nem tudom, hogy az Axaptaból szoktál e adatbázis szinkronizálni? Lehet egy próbát megérne, egy teljes alkalmazás compile és egy adatbázis szinkronizálás. Ez jót szokott tenni a "lelki békéjének". Az Axapta szinkronizálás el fog dobni mindent az SQL ből, ami nincs a saját adatbázis leírójában letárolva, erre figyelj (trigger, index, stb...) és ezzel adatot is veszíthet az adatbázis, pl olyan mező egy táblán, ami van az adattáblán, de nincs az alkalmazásban. Multi-site esetében ez érzékeny terület lehet.
Viszont, el kell, hogy szomorítsalak, hogy ez a csúcs amit X++-ból kód szinten ki lehet hozni közvetlenül (közvetve direkt sql utasítással a te megoldásodat is be lehet rakni Axapta forráskódba)... az indexhint részt mondjuk lehet kétségek közé állítani, én speciel lusta vagyok és index-et direktben adok meg, vagy nem adok semmit, vagy csak néhány mezőt keresek a táblából nem az egészet. Jelen esetben az InventTrans tábla összes mezőjét felrántja a query és berakja egy memória területre, amit címszerint átad a hívónak. Itt is lehet hatékonyabbá tenni. Másrészt még az is kérdéses, hogy hogyan hívogatják ezt a metódust? select forupdate-re vagy sem, az alap az, hogy nem, de ha másként hívják de mégsem lesz update, csak elrontották a kódot, akkor lesz egy lock a táblán ha jól emlékszem... ami lassíthat
Tábla lock beállítás... mea culpa, de ezt nem találom sem SQL2000 sem SQL 2005-ben... valamit keverek a fejemben, egy biztos a 3as Axaptaban az Adminisztráció-Beállítás-Rendszerben a Készlet - rendszer több tranzakcióhoz menüpont. Itt lehet állítani, hogy az Axapta az InventSum táblán engedje a párhuzamos frissítést, de ezt őszintén szólva még sosem próbáltam de láttam már olyat ahol működött így a rendszer. A 4esben táblánként állítható ez a beállítás az Axaptaban belülről a tábla tulajdonságok között a Concurrency pontnál álltható, hogy optimista legyen-e vagy sem... de őszintén szólva innentől megáll a tudományom a kérdésben, ez már hard-core fejlesztői kérdés.
Blokkolás és deadlock, hát ezek meg már a rendszer egészének működését firtatják... és őszintén szólva a legkeményebb dió egy rendszer működésében.
Kifogytam az ötletekből, anélkül, hogy látnám magam előtt az alkalmazást és tudnám, hogy mire használják és lenne 2-3 hetem elegerészni a dolgon egy fejlesztővel együtt, nehezen tudok okosabbat, vagy pontosabbat mondani.
Bandi Gyanítom, hogy itt a fejlesztő nem nézett utána, hogy milyen indexek állnak rendelkezésre az adott táblához, és beírta azt ami ha jól sejtem minden táblához automatikusan létrejön. Vagy egyszerűen csak lemásolt egy metódust és csak azt írta át benne amit feltétlen muszáj volt ahhoz, hogy működjön.
Ez egyébként egy standard metódus ezen a táblán.
Teszteltem a következő jobbal:
static void Job1(Args _args)
{
InventTrans inventTrans;
RecId recId = 5637503069;
InventTransId inventTransId = '10045571';
int ticksBegin;
int ticksEnd;
;
ticksBegin = WinAPI::getTickCount();
inventTrans = InventTrans::findRecIdTransId(recId, inventTransId, false);
ticksEnd = WinAPI::getTickCount();
info(strfmt("%1 - %2 = %3", ticksEnd, ticksBegin, ticksEnd - ticksBegin));
}A táblában amin teszteltem 57961 rekord volt.
Az eredmény 31 tick az eredeti index hinttel és 16 ha kikommentezem az index hintet a findRecIdTransId metódusban.
Ezen a táblán van egy TransIdIdx nevű index ami a következő mezőket tartalmazza: InventtransId, inventDimId, RecId. Ez egyébként a tábla clustered és primary indexe is.
Ha ezt adom meg index hintben, akkor szintén 16 tick lesz az eredmény. Tehát az optimizer nagy valószínűséggel ezt találná meg, ha nem tanácsolnának neki explicite mást.
Üdv
Péter
- Hát urak, ez utóbbi teljesen korrekt válasz, több konkrétummal mint én
Szerintem a topic elején lévő kérdésre kibontakozó válaszok hadából egy biztos, ha egy ilyen kérdés lassulással együtt merül fel, akkor előbb-utóbb mindenképpen le kell menni a funkciók szintjéről a kód szintjére és át kell nézni a kritikus pontokat. Ezeket egy SQL trace beállításával lehet felderíteni szerintem, és azok meg fogják mutatni, hogy az alkalmazás melyik pontján vannak, lehetnek ilyen, vagy ehhez hasonló nem optimális kódrészek.
Jut is eszembe, a teljesítmény teszt c. funkciót nem tudnák használni ebben az esetben szerintetek?
Bandi
