Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Az automatikus indextömörítés segít csökkenteni a tárterület, a lemez I/O- és processzorhasználatát, a memóriát, és javíthatja a számítási feladatok teljesítményét anélkül, hogy időt és energiát fektetnének az indexkarbantartási feladatokba. Az index tömörítése folyamatosan és alacsony terhelés mellett történik az adatbázis adatainak változásakor.
Megjegyzés:
Az automatikus indextömörítés jelenleg előzetes verzióban érhető el az Azure SQL Database-ben, az Azure SQL Managed Instance az Always-up-to-date update policy-val, és a Fabric SQL-adatbázisban.
A gyakori kérdésekre adott válaszokért tekintse meg a gyakori kérdéseket (GYIK).
Engedélyezés és letiltás
Az automatikus indextömörülés alapértelmezés szerint le van tiltva. Az adott adatbázishoz bekapcsolhatja vagy kikapcsolhatja a beállítást az alábbi Transact-SQL utasítások futtatásával.
Automatikus indextömörítés engedélyezése
ALTER DATABASE [database-name-placeholder] SET AUTOMATIC_INDEX_COMPACTION = ON;Az index automatikus tömörítésének letiltása:
ALTER DATABASE [database-name-placeholder] SET AUTOMATIC_INDEX_COMPACTION = OFF;
Annak megtekintéséhez, hogy az index automatikus tömörítése engedélyezve van-e, használja a sys.databases katalógusnézetet. Ha például látni szeretné, hogy mely adatbázisokban engedélyezett az automatikus indextömörítő funkció, futtassa a következő lekérdezést:
SELECT database_id,
name,
is_automatic_index_compaction_on
FROM sys.databases;
A DATABASEPROPERTYEX függvénnyel is ellenőrizheti a tulajdonságot IsAutomaticIndexCompactionOn .
Előnyök és szempontok
Az automatikus indextömörítés a következő előnyöket nyújtja:
- Nem kell beállítania és karbantartania az index karbantartási folyamatokat.
- Az indexkarbantartási feladatok révén elkerüli a magas erőforrás-felhasználást.
- Csökkenti a térnövekedést, amely az adatbázis adatainak módosításakor fordulhat elő.
- Javítja a lekérdezési teljesítményt.
- A kompakt indexet olvasó lekérdezések kevesebb oldalt olvasnak, ezért kevesebb lemez I/O-t, CPU-t és memóriát igényelnek.
- A kompakt indexek nagyobb valószínűséggel lesznek kiválasztva a lekérdezésterv javítása érdekében.
Fontos
Az automatikus tömörítés csak a nemrég módosított oldalakon működik. Ennek eredményeképpen a tömörítés többlettere minimális az index újraépítéséhez vagy az index átszervezéséhez képest, amely minden oldalt feldolgoz.
Bár a tömörítési folyamat terhelése minimális, nem nulla. Ha engedélyezi az automatikus indextömörödést, fontolja meg a következő szempontokat:
- Ha a tömörítési folyamat sok sort mozgat, növekedést tapasztalhat a naplóírási I/O mennyiségében és a napló biztonsági mentéseinek méretében.
- A tömörítés során a processzorhasználat kismértékben növekedhet, az alacsony egyjegyű százaléktartományon belül. Ez a növekedés nem gyakori.
- Az indexek átrendezéséhez hasonlóan a tömörítési folyamat rövid távú kizárólagos (
X) oldalzárolásokat szerez be a sorok egyik oldalról a másikra való áthelyezéséhez.- Az egyidejűség hatása minimális. Ha egy lap zárolása nem szerezhető be azonnal, a rendszer kihagyja a lapot, hogy elkerülje a többi lekérdezés és folyamat blokkolását.
- A lekérdezések esetenként rövid távú (ezredmásodperc) blokkolást tapasztalhatnak. Ez a blokkolás akkor következik be, ha egy lekérdezés megpróbál oldal- vagy sorzárolást nyerni, miután a tömörítési folyamat már végrehajtott egy kizárólagos, rövid távú zárolást az oldalon, és ez nem gyakori eset.
- Az egyidejűség hatása minimális. Ha egy lap zárolása nem szerezhető be azonnal, a rendszer kihagyja a lapot, hogy elkerülje a többi lekérdezés és folyamat blokkolását.
Hogyan működik?
Az automatikus indextömörítés a háttérben futó állandó verziótár (PVS) tisztítófolyamat része. Ez a folyamat rendszeresen eltávolítja az elavult sorverziókat az adatlapokon. Ha engedélyezi az automatikus indextömörödést az adatbázishoz, a PVS-tisztító az indexeket is tömöríti.
Mivel a tisztító a beszúrt, frissített vagy törölt sorokat tartalmazó lapokat látogatja meg, ellenőrzi, hogy az aktuális lap szabad hellyel rendelkezik-e, kivéve a kitöltési tényezővel fenntartott szabad területet. Ha igen, a tisztító a következő oldalról az aktuális oldalra helyezi át a sorokat, amíg elférnek a szabad területben. Ez a folyamat ezután előrehalad, és kis számú egymást követő oldalpár esetében ismétlődik a megtisztított oldal után.
Ha egy oldal üressé válik a sorok áthelyezése után, a rendszer felszabadítja azt. Ennek eredményeképpen csökken az adatbázisban használt lapok teljes száma, nő a lapsűrűség , és csökken a tárterület, a lemez I/O- és processzorhasználata, valamint a pufferkészlet memóriája.
Az alábbi ábra egy index adatlapjainak fogalmi nézetét mutatja be a tömörítés előtt és után.
A tömörítési folyamat a háttérben folytatódik az adatok módosításakor, és az elavult sorverziók törlődnek.
A tömörítési folyamat kihagyhat néhány oldalt az egyidejű tevékenység miatt, például:
- Aktív tranzakció egy oldalon.
- Folyamatban lévő index összeállítása vagy átrendezése.
- Folyamatban lévő zsugorítási művelet.
- Nagy PVS-méret vagy nagyszámú megszakított tranzakció a PVS-ből való törléshez.
- A PVS-tisztítás elsőbbséget jelent az automatikus tömörítéssel szemben. A tömörítés fel van függesztve, ha a PVS mérete 150 GB vagy nagyobb, vagy ha a megszakított tranzakciók száma 1000 vagy nagyobb.
Kevésbé gyakori okok miatt, amelyek miatt a tömörítési folyamat kihagyhatja a lapokat, olvassa el a tömörítési statisztikák figyelésére szolgáló kiterjesztett esemény használatával című témakört.
Ha a rendszer kihagy egy lapot, akkor a PVS-tisztító a következő feldolgozáskor számít tömörítésnek.
Az automatikus indextömörítés nem érhető el a rendszertáblákhoz és a rendszertáblákon kívüli rendszeradatbázisokhoz msdb. A letiltott lapzárolással rendelkező indexek nem jogosultak az automatikus tömörítésre.
Az adatoldalakról további információt a Lap és a terjedelem architektúra útmutatójában talál.
További információ az indexekről: Index architektúra és tervezési útmutató.
Összehasonlítás az index újraszervezésével és az index újraépítésével
Vegye figyelembe az alábbi különbségeket a hagyományos indexkarbantartási műveletek (index átrendezése, index újraépítése) és az automatikus indextömörítés között:
| Megfontolások | Ajánlások |
|---|---|
| A tömörítés folyamatosan és minimális terhelés mellett történik, amíg az adatbázisban lévő adatok módosulnak. | Nem kell beállítania, monitoroznia és karbantartania az indexkarbantartási feladatokat, hogy kihasználhassa a feladatok által nyújtott előnyöket. |
| Ellentétben az index újraszervezésével és az összes oldalt feldolgozó újraépítéssel, a tömörítési folyamat csak az automatikus indextömörítés engedélyezése után módosított lapokat veszi figyelembe. | Ha egy index oldalsűrűsége már alacsony, érdemes lehet egy egyszeri indexátszervezést vagy index-újraépítést futtatni annak növeléséhez. Ez az egyszeri művelet egy extra optimalizálás, amely azonnal növeli az oldalsűrűséget. Ettől a ponttól kezdve az automatikus tömörítés felhasználói művelet nélkül tömöríti az indexeket. |
| Minden index-újraépítési művelethez jelentős szabad terület szükséges az adatfájlokban, ami általában megegyezik az újjáépített index vagy partíció méretével. | Nem kell szabad területet lefoglalnia az adatfájlokban az automatikus indextömörítéshez vagy az indexek átrendezéséhez. |
| Az index újraépítése vagy az indexek átrendezése ellentétben a tömörítéssel nem csökkenti az index töredezettségét. | A tömörítés utáni nagyobb oldalsűrűség fontosabb, mint az index töredezettsége. A legtöbb számítási feladat esetében a magasabb indextöredezettség nem befolyásolja a lekérdezés teljesítményét vagy az erőforrás-felhasználást. |
| Ha egy index kitöltési tényezője kisebb, mint 100 százalék, de az oldalon lévő adatok mennyisége meghaladja a kitöltési tényezőt, akkor sem az index tömörítése, sem az átrendezés nem távolítja el a sorokat az oldaltól. Az indexek újraépítése új lapokat hoz létre, és a kitöltési tényezőnek megfelelően tölti ki őket. | A legtöbb számítási feladat esetében a nagyobb lapsűrűséget részesíti előnyben. Azok a számítási feladatok, amelyeknél alacsonyabb kitöltési tényező szükséges az oldaleloszlások csökkentéséhez, kihasználhatják az indexek időnkénti újraépítését. Az újraépítés alacsonyabb lapsűrűségű oldalakat hoz létre, amelyek megegyeznek a kitöltési tényezővel. |
| Az index újraépítésével ellentétben a tömörítés nem frissíti az index statisztikáit. | Ha az automatikus statisztikai frissítés nem elegendő a számítási feladathoz, és az index újraépítésére támaszkodik a statisztikák frissítéséhez, fontolja meg az automatikus tömörítést egy statisztikai frissítési feladattal kombinálva. |
Az indexek átrendezéséről és újraépítéséről további információt az indexkarbantartás optimalizálása a lekérdezési teljesítmény javítása és az erőforrás-felhasználás csökkentése érdekében című témakörben talál.
Oldalsűrűség és indextöredezettség
Az oldalsűrűség és az indextöredezettség az a két metrika, amely tükrözi az index által használt helyet, és hatással lehet a lekérdezési teljesítményre. A sys.dm_db_index_physical_stats dinamikus felügyeleti függvény (DMF) ezeket a metrikákat az avg_page_space_used_in_percent és az avg_fragmentation_in_percent oszlopokban jelenti, illetve.
A tömörítés növeli az oldalak sűrűségét azáltal, hogy több sort tárol ugyanazon az oldalon, ami javítja a teljesítményt és csökkenti az erőforrás-felhasználást.
Megfigyelheti, hogy az index töredezettsége magasabb, ha engedélyezi az automatikus indextömörítést. Ha ez a feltétel jelentkezik, fontolja meg a következőt:
| Megfontolások | Ajánlások |
|---|---|
| Egyes írásigényes számítási feladatokban a lapok nem sokkal a tömörítés után újra megoszlanak. Az oldalfelosztások növelik az index töredezettségét. | Ha a számítási feladatok teljesítményét ez befolyásolja, használjon egy egyszeri index-újraépítést egy kis mértékben csökkentett kitöltési tényezővel az oldaleloszlások csökkentéséhez a tömörítés után. Állítsa be például a kitöltési tényezőt a 70–95 százalékos tartományban. Ne csökkentse azonban feleslegesen a kitöltési tényezőt, vagy ne állítsa túl alacsonyra. A legtöbb számítási feladat optimális teljesítményt és erőforrás-kihasználtságot ér el az alapértelmezett 100%-os kitöltési tényezővel. |
| Ha a tömörítés során üres lapot helyez el, az bizonyos mértékig hézagot okozhat az oldalszámozási sorozatban. A mértéken belüli rések növelik az index töredezettségét, ami csökkentheti az előre olvasható I/O méretét. | A nagyobb töredezettség teljesítményhatása még az előre olvasható számítási feladatok esetében is minimálisra csökken, mivel a lekérdezések kevesebb oldalt olvasnak a tömörítés után. |
Jótanács
A legtöbb számítási feladat esetében a nagyobb oldalsűrűség előnyei meghaladják a nagyobb indextöredezettség teljesítményre gyakorolt hatását.
Automatikus indextömörülés monitorozása
Az automatikus indextömörítés hatékonyságának megtekintéséhez figyelheti a főbb indexmetrikákat, például a lapok számát, az átlagos oldalsűrűséget és az indexek időbeli töredezettségét. További információt a Kulcsindex-metrikák meghatározása című példában talál.
Az indexek egyes partícióinak összesített tömörítési statisztikáit a sys.dm_db_index_operational_stats dinamikus felügyeleti függvény használatával figyelheti. Ezek a statisztikák tartalmazzák a befejezett és kihagyott tömörítési kísérleteket, az áthelyezett sorokat és a felszabadított oldalakat. További információt az egyes indexpartíciós példák tömörítési statisztikáinak megtekintése című témakörben talál.
A részletes tömörítési statisztikákat kiterjesztett események használatával is monitorozhatja. További információ: A tömörítési statisztikák statisztikáinak monitorozására szolgáló kiterjesztett esemény használata példa.
Korlátozások
Az automatikus index tömörítési folyamat csak a B-fa index levélszintjének lapjait veszi figyelembe, amelyek egy IN_ROW_DATA foglalási egységben találhatók. Ide tartoznak a következő oldalak:
- Klaszterezett indexek és korlátozások.
- Nem klaszteres indexek és korlátozások.
- B-fa indexek a belső táblákon, amelyek speciális indextípusokat tárolnak, például XML, teljes szöveges, térbeli és oszlopcentrikus belső sorkészleteket.
Az alábbi oldalak nem jogosultak az automatikus indextömörülésre:
- Halomtáblák lapjai.
- Lapok a
ROW_OVERFLOW_DATAvagyLOB_DATAfoglalási egységekben. - Az oszlopalapú indexek tömörített sorcsoportjaiban lévő lapok.
- A memóriaoptimalizált táblázatok lapjai.
Gyakran ismételt kérdések (FAQ)
Ez a szakasz az automatikus indextömörüléssel kapcsolatos gyakori kérdésekre ad választ.
Szükség van újraindításra vagy kizárólagos adatbázis-hozzáférésre az automatikus tömörítés engedélyezéséhez vagy letiltásához?
Nem. A tömörítés a parancs végrehajtása ALTER DATABASE ... SET AUTOMATIC_INDEX_COMPACTION = ... után percek alatt elindul vagy leáll.
Hogyan változtatja meg a lekérdezés teljesítményét?
A lekérdezések általában gyorsabban futnak, és kevesebb lemez I/O-t, memóriát és processzort használnak. Ez a javulás leginkább azokban a számítási feladatokban észlelhető, amelyek jelentős írási tevékenységet végeznek, ami egyébként indexblobot okozna.
Hogyan változtatja meg a tárterület használatát?
A tömörítés csökkenti az adatfájlokban használt terület növekedését. Az adatbázis zsugorításával ellentétben azonban nem csökkenti az adatfájlok lefoglalt méretét.
Van többletterhelés?
A legtöbb számítási feladat esetében a többletterhelés nem észlelhető. Az írásigényes számítási feladatok esetében a tranzakciónapló I/O-jának növekedése és a tranzakciónapló biztonsági mentéseinek mérete is növekedhet.
Okozhat blokkolást?
Az automatikus tömörítés miatti blokkolás nem valószínű. Ha bármilyen blokkolás történik, az rövid távú és átmeneti (ezredmásodperc).
Ha egy lekérdezés le van tiltva, ellenőrizze a fő blokkoló parancsát a sys.dm_exec_requests. Az automatikus tömörítés blokkolhatja a lekérdezéseket, ha a parancs VERSION_CLEANER_MAIN vagy VERSION_CLEANER_WORKER.
Betartja a kitöltési tényező paramétereit?
Az automatikus tömörítés nem használja a kitöltési tényező által fenntartott szabad oldalterületet. Ha azonban az előző DML-utasítások már használják ezt a fenntartott helyet, akkor a tömörítés nem szabadít fel.
Működik, ha egy index sor- vagy oldaltömörítést használ?
Igen. Az automatikus tömörítés eltávolítja az üres területet az index lapjairól. Nem számít, hogy a lapok adatai tömörítve vannak-e vagy sem.
Miben különbözik a szellemek megtisztításától?
A ghost cleanup eltávolítja a helyreállíthatóan törölt sorokat a lapokról, így üres hely marad a lapon. Az automatikus tömörítés kevesebb oldalon lévő adatok összevonásával eltávolítja a lapok üres területét.
Mi történik, ha index-újraépítést vagy indexátszervezést futtatok, miközben engedélyezve van az automatikus tömörítés?
Az automatikus tömörítés kihagyja az újraépített vagy újraszervezett indexeket, beleértve a szüneteltetett újrapróbálkozott indexműveletek közepén lévő indexeket is.
Megakadályozhatja-e az automatikus tömörítés egy szerver nélküli adatbázis automatikus szüneteltetését?
Nem. Azok az indexek, amelyek az adatbázis szünete esetén automatikus tömörítésre jogosultak maradnak, az adatbázis folytatása után tömörítik. Az automatikus indextömörítés nem folytatja a szünetelt szerver nélküli adatbázist. További információkért lásd: Automatikus szüneteltetés és automatikus folytatás.
Examples
A következő T-SQL példákat futtassa a felhasználói adatbázisban, és ne az master adatbázisban.
Kulcsindex-metrikák meghatározása
Az alábbi lekérdezés visszaadja az index levélszintjének lapszámát, az oldalak átlagos sűrűségét és a töredezettség mértékét az page_count, avg_page_space_used_in_percent és avg_fragmentation_in_percent oszlopokban, automatikus tömörítésre jogosult indexek esetében. A lekérdezés egy összegsort is visszaad, amely összesítve tartalmazza ezeket a metrikákat az adatbázis összes indexéhez.
SELECT COALESCE (OBJECT_SCHEMA_NAME(ips.object_id), '<Total>') AS schema_name,
COALESCE (OBJECT_NAME(ips.object_id), '<Total>') AS object_name,
COALESCE (i.name, '<Total>') AS index_name,
COALESCE (i.type_desc, '<Total>') AS index_type,
COALESCE (ips.partition_number, NULL) AS partition_number,
AVG(ips.avg_page_space_used_in_percent) AS avg_page_space_used_in_percent,
AVG(ips.avg_fragmentation_in_percent) AS avg_fragmentation_in_percent,
SUM(ips.record_count) AS record_count,
SUM(ips.page_count) AS page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), DEFAULT, DEFAULT, DEFAULT, 'SAMPLED') AS ips
INNER JOIN sys.indexes AS i
ON ips.object_id = i.object_id
AND ips.index_id = i.index_id
WHERE i.type_desc IN ('CLUSTERED', 'NONCLUSTERED', 'XML', 'SPATIAL')
AND ips.index_level = 0
AND ips.page_count > 0
AND ips.alloc_unit_type_desc = 'IN_ROW_DATA'
GROUP BY ROLLUP(ips.object_id, i.name, i.type_desc, ips.partition_number)
HAVING ips.object_id IS NULL
AND ips.object_id IS NULL
AND i.name IS NULL
AND i.type_desc IS NULL
AND ips.partition_number IS NULL
OR ips.object_id IS NOT NULL
AND ips.object_id IS NOT NULL
AND i.name IS NOT NULL
AND i.type_desc IS NOT NULL
AND ips.partition_number IS NOT NULL
ORDER BY IIF (ips.object_id IS NULL, 0, 1), page_count DESC;
A lekérdezés hozzávetőleges eredményeket ad vissza a lapok egy részhalmazának mintavételezésével. Váltson a SAMPLEDDETAILED pontosabb eredmények eléréséhez. A nagy adatbázisok használata DETAILED hosszabb időt vehet igénybe, mert az adatbázis összes jogosult indexét teljes mértékben beolvasjuk. További információkért tekintse meg sys.dm_db_index_physical_stats.
Az egyes indexpartíciók tömörítési statisztikáinak megtekintése
Az aktuális adatbázisban lévő indexek egyes partícióira vonatkozó automatikus tömörítési statisztikákat az alábbi lekérdezéssel tekintheti meg:
SELECT OBJECT_SCHEMA_NAME(ios.object_id) AS schema_name,
OBJECT_NAME(ios.object_id) AS object_name,
i.name AS index_name,
i.type_desc AS index_type,
ios.partition_number AS partition_number,
ios.compaction_attempt_count,
ios.compaction_complete_count,
ios.compaction_skip_count,
ios.compaction_ineligible_count,
ios.compaction_failure_count,
ios.compaction_row_move_count,
ios.compaction_page_deallocation_count
FROM sys.dm_db_index_operational_stats(DB_ID(), DEFAULT, DEFAULT, DEFAULT) AS ios
INNER JOIN sys.indexes AS i
ON ios.object_id = i.object_id
AND ios.index_id = i.index_id
WHERE i.type_desc IN ('CLUSTERED', 'NONCLUSTERED', 'XML', 'SPATIAL')
AND OBJECT_SCHEMA_NAME(ios.object_id) <> 'sys';
További információ: sys.dm_db_index_operational_stats.
A tömörítési statisztikák figyelése kiterjesztett esemény használatával
A auto_index_compaction_stats kiterjesztett esemény használatával monitorozhat egy adatbázis tömörítési statisztikáit. Az esemény 10 percenként aktiválódik. Olyan adatokat tartalmaz, mint az index tömörítéséhez a lapok között áthelyezett sorok száma, a felszabadított lapok száma, valamint a különböző okokból kihagyott tömörítési kísérletek száma. Az egyes események által jelentett statisztikák kumulatívak az adatbázismotor indítása óta.
Az alábbi T-SQL-példa létrehoz és elindít egy esemény munkamenetet, amely összegyűjti az auto_index_compaction_stats eseményadatokat egy ring_buffer-célban . A lekérdezés összehasonlítja az aktuális és az előző eseményt, hogy minden 10 perces időszakra visszaadja a tömörítési statisztikákat. Mivel a lekérdezésnek legalább két eseményre van szüksége egy időintervallum statisztikáinak kiszámításához, előfordulhat, hogy legfeljebb 20 percig nem ad vissza adatokat az esemény munkamenetének kezdete után.
/*
Create and start an event session collecting the auto_index_compaction_stats event
into a ring_buffer target
*/
IF NOT EXISTS (SELECT 1
FROM sys.dm_xe_database_sessions
WHERE name = N'automatic_index_compaction')
BEGIN
CREATE EVENT SESSION automatic_index_compaction ON DATABASE
ADD EVENT sqlserver.auto_index_compaction_stats
ADD TARGET package0.ring_buffer (SET MAX_MEMORY = 1024);
ALTER EVENT SESSION automatic_index_compaction ON DATABASE STATE = START;
END
/* Get event data from the ring_buffer target */
DECLARE @EventData AS XML = (SELECT CAST (xst.target_data AS XML) AS TargetData
FROM sys.dm_xe_database_session_targets AS xst
INNER JOIN sys.dm_xe_database_sessions AS xs
ON xst.event_session_address = xs.address
WHERE xs.name = N'automatic_index_compaction');
/* Return statistics for each 10-minute interval */
WITH compaction_stats_event AS (
SELECT d.value('@timestamp', 'datetimeoffset') AS timestamp,
d.value('(data[@name = "database_id"]/value/text())[1]', 'smallint') AS database_id,
d.value('(data[@name = "compact_attempts"]/value/text())[1]', 'bigint') AS compact_attempts,
d.value('(data[@name = "compact_completed"]/value/text())[1]', 'bigint') AS compact_completed,
d.value('(data[@name = "pages_deallocated_compaction"]/value/text())[1]', 'bigint') AS pages_deallocated_compaction,
d.value('(data[@name = "rows_moved"]/value/text())[1]', 'bigint') AS rows_moved
FROM @EventData.nodes('/RingBufferTarget/event') AS e(d)
WHERE e.d.value('@name', 'sysname') = 'auto_index_compaction_stats'
),
timestamp_map AS (
SELECT database_id,
timestamp,
LAG(timestamp) OVER (PARTITION BY database_id ORDER BY timestamp) AS previous_timestamp
FROM compaction_stats_event
)
SELECT c.timestamp,
c.database_id,
c.compact_attempts - p.compact_attempts AS compact_attempts,
c.compact_completed - p.compact_completed AS compact_completed,
c.pages_deallocated_compaction - p.pages_deallocated_compaction AS pages_deallocated_compaction,
c.rows_moved - p.rows_moved AS rows_moved
FROM compaction_stats_event AS c
INNER JOIN timestamp_map AS tm
ON c.timestamp = tm.timestamp
AND c.database_id = tm.database_id
INNER JOIN compaction_stats_event AS p
ON tm.previous_timestamp = p.timestamp
AND tm.database_id = p.database_id
ORDER BY timestamp DESC;
Az előző lekérdezést úgy módosíthatja, hogy más eseménymezőket is tartalmazzon, és további statisztikákat adjon vissza, például a különböző okokból kihagyott tömörítési kísérletek számát. Az alábbi lekérdezés segítségével megtekintheti az esemény összes mezőjét auto_index_compaction_stats és leírását.
SELECT name,
type_name,
description
FROM sys.dm_xe_object_columns
WHERE object_name = N'auto_index_compaction_stats'
AND column_type = N'data';
Visszajelzés küldése
Microsoft szívesen meghallgatja az automatikus indextömörödéssel kapcsolatos visszajelzését. Küldjön visszajelzést a termékről, ha új ötletet tesz közzé az SQL visszajelzési fórumában. Más közösségtagok is felveszthetik és véleményezhetik ötleteit és javaslatait. A közösségi szavazatok és megjegyzések segítenek Microsoft termékfejlesztések megtervezésében és rangsorolásában.