Az Azure SQL Database teljesítményének monitorozása és kezelése több-bérlős SaaS-alkalmazásban

A következőre vonatkozik: Azure SQL Database

Ebben az oktatóanyagban az SaaS-alkalmazásokban használt főbb teljesítménykezelési forgatókönyveket vizsgáljuk meg. Az SQL Database és a rugalmas készletek beépített monitorozási és riasztási funkciói egy terhelésgenerátor használatával szimulálják az összes bérlői adatbázis tevékenységeit.

A Wingtip Tickets SaaS-adatbázis bérlőnkénti alkalmazás egy bérlős adatmodellt használ, amelyben minden helyszín (bérlő) saját adatbázissal rendelkezik. Sok más SaaS-alkalmazáshoz hasonlóan a bérlői számítási feladatok várt mintája kiszámíthatatlan és szórványos. Ez a gyakorlatban azt jelenti, hogy a jegyeladásokra bármikor sor kerülhet. Ennek a tipikus adatbázis-használati mintának a kihasználása érdekében a bérlői adatbázisok rugalmas készletekbe vannak üzembe helyezve. A rugalmas készletek optimalizálják a megoldások költségeit azáltal, hogy számos adatbázis között osztják meg az erőforrásokat. Ennél a típusú mintánál fontos az adatbázis és a készleterőforrások felhasználásának figyelése annak biztosítása érdekében, hogy a terhelések egyenletesen oszoljanak meg a készletek közt. Emellett azt is biztosítani kell, hogy az egyes adatbázisok elengedő mennyiségű erőforrással rendelkezzenek, és hogy a készletek ne érjék el a maximális eDTU-korlátot. Ez az oktatóanyag különböző módszereket ismertet az adatbázisok és készletek figyelésére és kezelésére, valamint a számítási feladatok változásaira adott korrekciós műveletek elvégzésére.

Ezen oktatóanyag segítségével megtanulhatja a következőket:

  • A bérlői adatbázisok használatának szimulálása egy adott terhelésgenerátor futtatásával
  • A bérlői adatbázisok megnövekedett terhelésre adott válaszának megfigyelése
  • A rugalmas készlet vertikális felskálázása az adatbázis megnövekedett terhelésére adott válaszul
  • Egy második rugalmas készlet kiépítése az adatbázis-tevékenységek terhelésének kiegyenlítésére

Az oktatóanyag teljesítéséhez a következő előfeltételeknek kell teljesülnie:

Az SaaS teljesítménykezelési mintáinak bemutatása

Az adatbázisteljesítmény-kezelés a teljesítményadatok fordításából és elemzéséből, majd az adatokra való reagálásból áll. Ez tulajdonképpen a paraméterek módosítását jelenti, miáltal az alkalmazás válaszideje elfogadható szinten marad. Ha több bérlőt üzemeltet, a rugalmas készletek költséghatékony módon biztosítják és kezelhetik az erőforrásokat egy kiszámíthatatlan számítási feladatokkal rendelkező adatbáziscsoport számára. Bizonyos számításifeladat-mintáknál már akár két S3-adatbázist is előnyös lehet készletben kezelni.

application diagram

A készleteket és a készletekben lévő adatbázisokat figyelni kell annak biztosítása érdekében, hogy elfogadható teljesítménytartományokon belül maradjanak. A készlet konfigurációjának finomhangolása az összes adatbázis összesített számítási feladatainak igényeinek megfelelően, biztosítva, hogy a készlet eDTU-jai megfeleljenek a teljes számítási feladatnak. Állítsa be az adatbázisonkénti minimális és maximális eDTU-értékeket az alkalmazás specifikus igényei szerint.

Teljesítménykezelési stratégiák

  • A teljesítmény manuális figyelésének elkerülése érdekében a leghatékonyabb olyan riasztásokat beállítani, amelyek akkor aktiválnak, ha az adatbázisok vagy készletek eltávolodnak a normál tartományoktól.
  • A készlet összesített számítási méretének rövid távú ingadozásaira reagálva a készlet eDTU-szintje fel- vagy leskálázható. Ha az ingadozás rendszeres vagy kiszámítható, akkor a készlet beállítható úgy, hogy a skálázás automatikusan ütemezve legyen. Beállítható például a vertikális leskálázás, amikor előre láthatóan kevés lesz a számítási feladat, például éjjelente vagy a hétvégi napokon.
  • A hosszabb távú ingadozásokra vagy az adatbázisok számának változására válaszul az egyes adatbázisok áthelyezhetők másik készletekbe.
  • Az egyes adatbázisok terhelésének rövid távú növekedésére való reagáláshoz az egyes adatbázisok kivehetők a készletből, és egyedi számítási méretet rendelhetnek hozzá. A terhelés csökkenésével az adatbázis visszahelyezhető a készletbe. Ha ez előre ismert, az adatbázisok előre áthelyezhetők, hogy az adatbázis mindig rendelkezzen a szükséges erőforrásokkal, és hogy elkerülje a készlet többi adatbázisára gyakorolt hatást. Ha ez a szükséglet előre kiszámítható, például ha egy helyszín nagy mennyiségű növekedésre számít a jegyeladásokban egy népszerű esemény miatt, akkor ez a kezelési viselkedés integrálható az alkalmazásba.

Az Azure Portal a legtöbb erőforráshoz beépített figyelési és riasztási lehetőségeket biztosít. A monitorozás és a riasztás adatbázisokban és készletekben érhető el. Ez a beépített monitorozás és riasztás erőforrás-specifikus, ezért kis számú erőforráshoz kényelmesen használható, de sok erőforrás használatakor nem túl kényelmes.

Nagy mennyiségű forgatókönyv esetén, ahol sok erőforrással dolgozik, az Azure Monitor-naplók használhatók. Ez egy külön Azure-szolgáltatás, amely a Log Analytics-munkaterületen összegyűjtött, kibocsátott naplókon keresztül biztosít elemzéseket. Az Azure Monitor-naplók telemetriát gyűjthetnek számos szolgáltatásból, és a riasztások lekérdezésére és beállítására használhatók.

A Wingtip Tickets SaaS-adatbázis bérlőnkénti alkalmazásszkriptjeinek lekérése

A Wingtip Tickets SaaS Több-bérlős adatbázis szkriptjei és az alkalmazás forráskódja a WingtipTicketsSaaS-DbPerTenant GitHub adattárban érhető el. Tekintse meg a Wingtip Tickets SaaS-szkriptek letöltésének és letiltásának feloldásához szükséges általános útmutatót .

További bérlők kiépítése

Noha a készletek használata már két S3-adatbázis esetén is költséghatékony lehet, minél több adatbázis található egy készletben, a költséghatékonyság mértéke annál jobban nő. Annak érdekében, hogy a teljesítményfigyelés és -kezelés nagy léptékben való használatát kellőképpen szemléltetni lehessen, jelen oktatóanyaghoz legalább 20 üzembe helyezett adatbázis szükséges.

Ha egy korábbi oktatóanyagban már kiépített egy bérlőköteget, ugorjon az összes bérlői adatbázis használat szimulálása szakaszára.

  1. A PowerShell ISE-ben nyissa meg a ...\Learning Modules\Performance Monitoring and Management\Demo-PerformanceMonitoringAndManagement.ps1 fájlt. Tartsa ezt a szkriptet nyitva, mivel az oktatóanyag során több különböző forgatókönyvet is futtatnia kell majd.
  2. Válassza a $DemoScenario = 1, Bérlők kötegelt kiépítése lehetőséget.
  3. A szkriptek futtatásához nyomja le az F5 billentyűt.

A szkript kevesebb mint öt perc alatt 17 bérlőt helyez üzembe.

A New-TenantBatch szkript egy beágyazott vagy csatolt Resource Manager-sablonkészletethasznál, amely bérlők kötegét hoz létre, amely alapértelmezés szerint a katalóguskiszolgálón lévő adatbázist másolja át az új bérlői adatbázisok létrehozásához, majd regisztrálja őket a katalógusban, és végül inicializálja őket a bérlő nevével és helyszíntípusával. Ez összhangban van azzal, ahogyan az alkalmazás kiépít egy új bérlőt. A basetenantdb módosításai az azt követően kiépített új bérlőkre lesznek alkalmazva. A sémakezelési oktatóanyagból megtudhatja, hogyan módosíthatja a meglévő bérlői adatbázisokat (beleértve a basetenantdb-adatbázist is).

Az összes bérlői adatbázis használatának szimulálása

Elérhető a Demo-PerformanceMonitoringAndManagement.ps1 szkript, amely az összes bérlői adatbázison futó számítási feladatot szimulálja. A terhelés az elérhető terhelési forgatókönyvek egyikével jön létre:

Bemutató Forgatókönyv
2 Normál intenzitású terhelés létrehozása (körülbelül 40 DTU)
3 Terhelés létrehozása adatbázisonkénti hosszabb és gyakoribb adatlöketekkel
4 Nagyobb DTU-kipukkadású terhelés generálása adatbázisonként (körülbelül 80 DTU)
5 Normál terhelés és nagy terhelés generálása egyetlen bérlőn (körülbelül 95 DTU)
6 Kiegyensúlyozatlan terhelés létrehozása több készlet számára

A terhelésgenerátor egy szintetikus CPU-terhelést alkalmaz az összes bérlői adatbázison. A generátor minden bérlői adatbázis számára elindít egy feladatot, amely időközönként meghív egy, a terhelést létrehozó tárolt eljárást. A terhelések szintje (eDTU-ban mérve), időtartama és időköze minden adatbázis esetén más és más, ezzel szimulálva a kiszámíthatatlan bérlői aktivitást.

  1. A PowerShell ISE-ben nyissa meg a ...\Learning Modules\Performance Monitoring and Management\Demo-PerformanceMonitoringAndManagement.ps1 fájlt. Tartsa ezt a szkriptet nyitva, mivel az oktatóanyag során több különböző forgatókönyvet is futtatnia kell majd.
  2. Állítsa be a $DemoScenario = 2 értéket, normál intenzitású terhelést generál.
  3. Nyomja le az F5 billentyűt, hogy az összes bérlői adatbázist érje terhelés.

A Wingtip Tickets SaaS-adatbázis bérlőnként egy SaaS-alkalmazás, és az SaaS-alkalmazások valós terhelése általában szórványos és kiszámíthatatlan. Ennek szimulálására a terhelésgenerátor az összes bérlő között elosztott, véletlenszerű terhelést hoz létre. A terhelési minta megjelenéséhez több percre van szükség, ezért futtassa a terhelésgenerátort 3-5 percig, mielőtt megpróbálna figyelni a terhelést a következő szakaszokban.

Fontos

A terhelésgenerátor feladatok sorozataként fut a helyi PowerShell-munkamenetben. Hagyja nyitva a Demo-PerformanceMonitoringAndManagement.ps1 lapot! Ha bezárja a lapot vagy felfüggeszti a gép működését, a terhelésgenerátor leáll. A terhelésgenerátor feladat-invokálási állapotban marad, ahol terhelést generál a generátor elindítása után kiépített új bérlőkre. A Ctrl-C billentyűkombinációval állítsa le az új feladatok meghívását, és lépjen ki a szkriptből. A terhelésgenerátor továbbra is fut, de csak a meglévő bérlőkön.

Erőforrás-használat monitorozása az Azure Portalon

Az alkalmazott terhelésből származó erőforrás-használat figyeléséhez nyissa meg a portált a bérlői adatbázisokat tartalmazó készletben:

  1. Nyissa meg az Azure Portalt, és keresse meg a bérlők1-dpt-USER<> kiszolgálóját.
  2. Görgessen lefelé, keresse meg a rugalmas készleteket, és kattintson a Pool1 készletre. Ez a készlet tartalmazza az összes eddig létrehozott bérlői adatbázist.

Figyelje meg a rugalmas készlet monitorozási és rugalmasadatbázis-monitorozási diagramjait.

A készlet erőforrás-kihasználtsága a készlet összes adatbázisának összesített adatbázis-kihasználtsága. Az adatbázisdiagram az öt legforróbb adatbázist jeleníti meg:

database chart

Mivel a készletben az első ötnél több adatbázis található, a készlet kihasználtsága olyan tevékenységeket jelenít meg, amelyek nem jelennek meg az első öt adatbázisdiagramon. További részletekért kattintson az Adatbázis-erőforrás kihasználtsága elemre:

database resource utilization

Teljesítményriasztások beállítása a készletben

Állítson be egy riasztást a készleten, amely a 75%-os kihasználtságot aktiválja >az alábbiak szerint:

  1. Nyissa meg a Pool1-et (a tenants1-dpt-user>< kiszolgálón) az Azure Portalon.

  2. Kattintson a Riasztási szabályok elemre, majd a + Riasztás hozzáadása gombra:

    add alert

  3. Adjon meg egy nevet, például: Magas DTU.

  4. Állítsa be a következő értékeket:

    • Metrika = eDTU százalékos értéke
    • Feltétel = nagyobb, mint
    • Küszöbérték = 75
    • Period = Az elmúlt 30 percben
  5. Adjon hozzá egy e-mail-címet a További rendszergazdai e-mail(ek) mezőbe, és kattintson az OK gombra.

    set alert

Foglalt készlet vertikális felskálázása

Ha egy készlet összesített terhelési szintje addig növekszik, hogy teljesen lefoglalja a készletet és 100%-os eDTU-használatot ér el, az hatással van az adatbázisok egyéni teljesítményére, és lelassíthatja a lekérdezések válaszidejét a készletben található összes adatbázisban.

Rövid távon fontolja meg a készlet skálázását további erőforrások biztosításához, vagy az adatbázisok készletből való eltávolításához (más készletekbe vagy a készletből egy különálló szolgáltatási szintre való áthelyezéshez).

Hosszabb távon érdemes lehet optimalizálni a lekérdezéseket vagy az indexhasználatot az adatbázis teljesítményének javítása érdekében. Az alkalmazás teljesítményingadozásokra való érzékenységétől függően az ajánlott eljárás a készlet vertikális felskálázása még a 100%-os eDTU-használat elérése előtt. Használjon olyan riasztást, amely előre figyelmezteti Önt.

Foglalt készletet a generátor által létrehozott terhelés növelésével szimulálhat. Az adatbázisok gyakrabban és hosszabb ideig törnek ki, és növelik a készlet összesített terhelését anélkül, hogy módosítanák az egyes adatbázisok követelményeit. A készlet vertikális felskálázása könnyedén elvégezhető a portálon vagy a PowerShellben. A gyakorlat során a Portalt használjuk.

  1. Állítsa be a $DemoScenario = 3, Terhelés létrehozása adatbázisonkénti hosszabb és gyakoribb adatlöketekkel értéket, hogy megnövelje a készlet összesített terhelési intenzitását az egyes adatbázisok csúcsterhelési követelményeinek megváltoztatása nélkül.

  2. Nyomja le az F5 billentyűt, hogy az összes bérlői adatbázist érje terhelés.

  3. Nyissa meg a Pool1-et az Azure Portalon.

Figyelje meg a készlet eDTU-jának megnövekedett használatát a felső diagramon. Néhány percig tart, amíg az új magasabb terhelés beindul, de gyorsan látnia kell, hogy a készlet eléri a maximális kihasználtságot, és mivel a terhelés az új mintába kerül, gyorsan túlterheli a készletet.

  1. A készlet vertikális felskálázásához kattintson a Készlet1 lap tetején található Készlet konfigurálása elemre.
  2. Állítsa a készlet eDTU-beállítását 100-ra. A készlet eDTU-értékének módosítása nem módosítja az adatbázisonkénti beállításokat (ami továbbra is adatbázisonként legfeljebb 50 eDTU). Az adatbázisonkénti beállítások a Készlet konfigurálása lap jobb oldalán láthatók.
  3. Kattintson a Mentés gombra a készlet méretezésére vonatkozó kérés elküldéséhez.

A figyelési diagramok megtekintéséhez térjen vissza a Pool1>áttekintéséhez. Figyelje meg, hogy a készletnek több erőforrást kell-e biztosítani (bár kevés adatbázissal és véletlenszerű terheléssel nem mindig könnyű meggyőzően látni, amíg egy ideig nem fut). A diagramok megtekintése közben vegye figyelembe, hogy a felső diagramon látható 100% most 100 eDTU-t jelent, míg az alsó diagramon látható 100% továbbra is 50 eDTU-t, mivel az adatbázisonkénti maximum változatlanul 50 eDTU.

Az adatbázisok a folyamat során végig online állapotban maradnak, és teljes mértékben rendelkezésre állnak. Abban a pillanatban, hogy minden adatbázis készen áll a készlet új eDTU-értékével való engedélyezésre, minden aktív kapcsolat megszakad. Az alkalmazás kódját mindig úgy kell megírni, hogy újrapróbálja a megszakított kapcsolatokat, így újra csatlakozni fog az adatbázishoz a felskálázott készletben.

Terheléselosztás készletek között

A készlet felskálázása mellett másik lehetőségként létrehozhat egy második készletet és áthelyezhet abba adatbázisokat, hogy kiegyenlítse a két készlet terhelését. Ehhez az új készletet ugyanazon a kiszolgálón kell létrehozni, amelyen az első is megtalálható.

  1. Az Azure Portalon nyissa meg a tenants1-dpt-USER>< kiszolgálót.

  2. Kattintson az + Új készlet elemre, ha készletet szeretne létrehozni az aktuális kiszolgálón.

  3. A Rugalmas készlet sablonon:

    1. Állítsa be a nevet a Pool2 értékre.

    2. A tarifacsomagnál hagyja meg a Standard készlet beállítást.

    3. Kattintson a Készlet beállítása elemre.

    4. Állítsa az eDTU készletet 50 eDTU-ra.

    5. Kattintson az Adatbázisok hozzáadása gombra a készlet2-hez hozzáadható adatbázisok listájának megtekintéséhez a kiszolgálón.

    6. Jelölje ki a 10 adatbázist az új készletbe való áthelyezéshez, majd kattintson a Kijelölés gombra. Ha már futtatta a terhelésgenerátort, a szolgáltatás már tudja, hogy a teljesítményprofil az alapértelmezett 50 eDTU-méretnél nagyobb készletet igényel, és 100 eDTU-beállítással kezdődően javasolja.

      recommendation

    7. Ebben az oktatóanyagban hagyja meg az alapértelmezett értéket 50 eDTU értéken, majd kattintson ismét a Kijelölés gombra.

    8. Válassza az OK gombot az új készlet létrehozásához és a kijelölt adatbázisok áthelyezéséhez.

A készlet létrehozása és az adatbázisok áthelyezése néhány percet vesz igénybe. Az adatbázisok áthelyezésekor az utolsó pillanatig online állapotban maradnak, és teljes mértékben elérhetők maradnak, és ekkor minden nyitott kapcsolat bezárul. Ha van újrapróbálkozási logikája, az ügyfelek ezután csatlakoznak az új készlet adatbázisához.

Keresse meg a Pool2 (a bérlők1-dpt-user>< kiszolgálóján) elemet a készlet megnyitásához és a teljesítmény figyeléséhez. Ha nem látja, várja meg az új készlet üzembe helyezését.

Most már láthatja, hogy a Készlet1 erőforrás-kihasználtsága csökkent, és a Pool2 is hasonlóképpen van betöltve.

Önálló adatbázis teljesítményének kezelése

Ha egy készlet egyes adatbázisai tartósan magas terhelést tapasztalnak a készlet konfigurációjától függően, az általában a készlet erőforrásait uralja, és hatással van más adatbázisokra. Ha a tevékenység valószínűleg egy ideig folytatódik, az adatbázis ideiglenesen áthelyezhető a készletből. Ez lehetővé teszi, hogy az adatbázis rendelkezzen a szükséges extra erőforrásokkal, és elkülönítse azt a többi adatbázistól.

Ez a gyakorlat a Contoso Concert Hall magas terhelésének a hatását szimulálja, amikor megkezdődik a jegyek árusítása egy népszerű koncertre.

  1. A PowerShell ISE-ben nyissa meg a ...\Demo-PerformanceMonitoringAndManagement.ps1 szkriptet.

  2. Állítsa be a $DemoScenario = 5 értéket, hozzon létre egy normál terhelést és egy nagy terhelést egyetlen bérlőn (körülbelül 95 DTU).

  3. Állítsa be a $SingleTenantDatabaseName = contosoconcerthallértéket.

  4. Futtassa a szkriptet az F5 billentyűvel.

  5. Az Azure Portalon keresse meg a bérlők1-dpt-user<> kiszolgáló adatbázisainak listáját.

  6. Kattintson a contosoconcerthall adatbázisra.

  7. Kattintson arra a készletre, amelyben a Contosoconcerthall található. Keresse meg a készletet a Rugalmas készlet szakaszban.

  8. Vizsgálja meg a rugalmas készlet monitorozási diagramot, és keresse meg a készlet megnövekedett eDTU-használatát. Egy-két perc után jelentkezik a magas terhelés, aminek következtében a készlet eléri a 100%-os kihasználtságot.

  9. Vizsgálja meg a rugalmas adatbázis monitorozási kijelzőjét, amely az elmúlt órában a legforróbb adatbázisokat mutatja. A contosoconcerthall adatbázisnak hamarosan az öt legforróbb adatbázis egyikeként kell megjelennie.

  10. Kattintson a rugalmas adatbázis-monitorozásidiagramra , és megnyitja az Adatbázis-erőforrás-kihasználtság lapot, ahol bármelyik adatbázist figyelheti. Ez lehetővé teszi a contosoconcerthall-adatbázis megjelenítésének elkülönítését.

  11. Az adatbázisok listájában kattintson a contosoconcerthall elemre.

  12. Kattintson a Tarifacsomag (DTU-k méretezése) elemre a Teljesítmény konfigurálása lap megnyitásához, ahol beállíthatja az adatbázis önálló számítási méretét.

  13. Kattintson a Standard lapra a Standard csomag skálázási beállításainak megnyitásához.

  14. Húzza jobbra a DTU csúszkát a 100 DTU kiválasztásához. Vegye figyelembe, hogy ez megfelel az S3 szolgáltatáscélnak.

  15. Az Alkalmaz gombra kattintva áthelyezheti az adatbázist a készletből, és standard S3-adatbázissá teheti.

  16. A skálázás befejezése után figyelje meg a contosoconcerthall-adatbázisra és a Pool1-re gyakorolt hatást a rugalmas készletre és adatbázispanelekre.

Miután a contosoconcerthall-adatbázis nagy terhelése alábbhagyott, azonnal vissza kell adnia a készletbe a költségek csökkentése érdekében. Ha nem egyértelmű, hogy ez mikor történik, beállíthat egy riasztást az adatbázison, amely akkor aktiválódik, ha a DTU-használat az adatbázisonkénti maximális érték alá csökken a készleten. Egy adatbázis készletbe történő áthelyezésének menetét az 5. gyakorlat írja le.

Egyéb teljesítménykezelési minták

Előzetes skálázás A fenti gyakorlatban, ahol egy izolált adatbázis skálázását vizsgálta, tudta, hogy melyik adatbázist kell keresnie. Ha a Contoso Koncertterem vezetősége tájékoztatta volna a Wingtipst a közelgő jegyeladásról, akkor az adatbázist előre lehetett volna áthelyezni a medencéből. Máskülönben valószínűleg egy riasztást kellett volna beállítani a készleten vagy az adatbázison ahhoz, hogy észre lehessen venni, mi történik. Erről nem szeretne többet megtudni a készlet többi bérlőjétől, aki teljesítménycsökkenésre panaszkodik. Ha a bérlő meg tudja jósolni, hogy milyen hosszan lesz szüksége további erőforrásokra, beállítható egy Azure Automation-runbook, amely pontosan ütemezi az adatbázis kivételét, majd visszahelyezését a készletbe.

Bérlők általi önkiszolgáló skálázás Mivel a skálázási feladat könnyen meghívható a felügyeleti API-n keresztül, így a bérlői adatbázisok méretezésének lehetősége könnyen beépíthető a bérlőoldali alkalmazásba, és felkínálható az SaaS-szolgáltatás egy funkciójaként. Például a bérlők saját maguk adminisztrálhatják a vertikális fel- és leskálázást, ami előfordulhat, hogy közvetlen kapcsolatban áll a számlázásukkal.

Készlet vertikális fel- és leskálázása ütemezés szerint a használati mintáknak megfelelően

Ha az összesített bérlői használat kiszámítható mintákat követ, az Azure Automationnel ütemezni tudja a készletek vertikális fel- és leskálázását. Például egy készletet hétköznapokon este 6 után leskálázhat, reggel 6 előtt pedig felskálázhat, ha tudja, hogy a két időpont között csökken az erőforrásigény.

További lépések

Ezen oktatóanyag segítségével megtanulhatja a következőket:

  • A bérlői adatbázisok használatának szimulálása egy adott terhelésgenerátor futtatásával
  • A bérlői adatbázisok megnövekedett terhelésre adott válaszának megfigyelése
  • A rugalmas készlet vertikális felskálázása az adatbázis megnövekedett terhelésére adott válaszul
  • Egy második rugalmas készlet kiépítése az adatbázis-tevékenységek terhelésének kiegyenlítésére

Egyetlen bérlő visszaállítása – oktatóanyag

További erőforrások