Delen via

Geoptimaliseerde vergrendeling

  • Artikel

van toepassing op:Azure SQL DatabaseSQL-database in Microsoft Fabric

In dit artikel worden geoptimaliseerde vergrendelingen geïntroduceerd, een functionaliteit van de database-engine die een verbeterd mechanisme voor transactievergrendeling biedt om het geheugengebruik van vergrendelingen te verminderen en het blokkeren bij gelijktijdige transacties te beperken.

Wat is geoptimaliseerde vergrendeling?

Geoptimaliseerde vergrendeling helpt om het geheugen van de vergrendeling te verminderen, omdat er zeer weinig vergrendelingen worden bewaard, zelfs voor grote transacties. Bovendien voorkomt geoptimaliseerde vergrendeling ook escalaties van vergrendelingen. Hierdoor is er meer gelijktijdige toegang tot de tabel mogelijk.

Geoptimaliseerde vergrendeling bestaat uit twee primaire onderdelen: transactie-id (TID)-vergrendeling en slot na kwalificatie (LAQ).

  • Een transactie-id (TID) is een unieke id van een transactie. Elke rij wordt gelabeld met de laatste TID die deze heeft gewijzigd. In plaats van mogelijk veel sleutel- of rij-id-vergrendelingen wordt één vergrendeling op de TID gebruikt. Zie Transaction ID (TID)-vergrendelingvoor meer informatie.
  • Vergrendelen na kwalificatie (LAQ) is een optimalisatie die querypredicaten evalueert met behulp van de meest recente vastgelegde versie van de rij zonder een vergrendeling te verkrijgen, waardoor gelijktijdigheid wordt verbeterd. Voor meer informatie, zie Lock after qualification (LAQ).

Bijvoorbeeld:

  • Zonder geoptimaliseerde vergrendeling is het bijwerken van 1000 rijen in een tabel mogelijk 1000 exclusieve rijvergrendelingen (X) vereist tot het einde van de transactie.
  • Met geoptimaliseerde vergrendeling kan het bijwerken van 1000 rijen in een tabel 1000 X rijvergrendelingen vereisen, maar elke vergrendeling wordt vrijgegeven zodra elke rij wordt bijgewerkt en slechts één TID-vergrendeling wordt bewaard tot het einde van de transactie. Omdat vergrendelingen snel worden vrijgegeven, wordt het geheugengebruik beperkt en escalatie van vergrendelingen veel minder waarschijnlijk is, waardoor de gelijktijdigheid van werkbelastingen wordt verbeterd.

Notitie

Het inschakelen van geoptimaliseerde vergrendeling vermindert of elimineert rij- en paginavergrendelingen die zijn verkregen door de DML-instructies (Data Modification Language), zoals INSERT, UPDATE, DELETE, MERGE. Dit heeft geen invloed op andere soorten database- en objectvergrendelingen, zoals schemavergrendelingen.

Beschikbaarheid

Geoptimaliseerde vergrendeling is alleen beschikbaar in Azure SQL Database en SQL-database in Microsoft Fabric, in alle servicelagen en rekengrootten.

Geoptimaliseerde vergrendeling is momenteel niet beschikbaar in Azure SQL Managed Instance of in SQL Server.

Is geoptimaliseerde vergrendeling ingeschakeld?

Geoptimaliseerde vergrendeling is ingeschakeld per gebruikersdatabase. Maak verbinding met uw database en gebruik vervolgens de volgende query om te controleren of geoptimaliseerde vergrendeling is ingeschakeld:

SELECT IsOptimizedLockingOn = DATABASEPROPERTYEX(DB_NAME(), 'IsOptimizedLockingOn');
Resultaat Beschrijving
0 Geoptimaliseerde vergrendeling is uitgeschakeld.
1 Geoptimaliseerde vergrendeling is ingeschakeld.
NULL Geoptimaliseerde vergrendeling is niet beschikbaar.

Geoptimaliseerde vergrendeling bouwt voort op andere databasefuncties:

Zowel ADR als RCSI zijn standaard ingeschakeld in Azure SQL Database. Als u wilt controleren of deze opties zijn ingeschakeld voor uw huidige database, maakt u verbinding met de database en voert u de volgende T-SQL-query uit:

SELECT name,
       is_read_committed_snapshot_on,
       is_accelerated_database_recovery_on
FROM sys.databases
WHERE name = DB_NAME();

Overzicht van vergrendeling

Dit is een kort overzicht van het gedrag wanneer geoptimaliseerde vergrendeling niet is ingeschakeld. Raadpleeg de handleiding Transactievergrendeling en rijversiebeheer voor meer informatie.

In de database-engine is vergrendelen een mechanisme dat voorkomt dat meerdere transacties dezelfde gegevens tegelijkertijd bijwerken om de ACID- eigenschappen van transacties te garanderen.

Wanneer een transactie gegevens moet wijzigen, wordt een vergrendeling voor de gegevens aangevraagd. De vergrendeling wordt verleend als er geen andere conflicterende vergrendelingen op de gegevens worden vastgehouden, en de transactie kan doorgaan met de wijziging. Als een andere conflicterende vergrendeling op de gegevens wordt bewaard, moet de transactie wachten totdat de vergrendeling is vrijgegeven voordat deze kan worden voortgezet.

Wanneer meerdere transacties gelijktijdig toegang proberen te krijgen tot dezelfde gegevens, moet de database-engine mogelijk complexe conflicten met gelijktijdige lees- en schrijfbewerkingen oplossen. Vergrendelen is een van de mechanismen waarmee de engine de semantiek voor de isolatieniveaus van een ANSI SQL-transactie kan bieden . Hoewel het vergrendelen van databases essentieel is, kunnen minder gelijktijdigheid, impasses, complexiteit en vergrendelingsoverhead van invloed zijn op de prestaties en schaalbaarheid.

Vergrendeling van transactie-id (TID)

Wanneer isolatieniveaus op basis van rijversiebeheer worden gebruikt of wanneer ADR is ingeschakeld, bevat elke rij in de database intern een transactie-ID (TID). Deze TID blijft behouden op schijf. Elke transactie die een rij wijzigt, voorziet die rij van zijn TID-stempel.

Met TID-vergrendeling wordt, in plaats van een vergrendeling op de sleutel van de rij te nemen, een vergrendeling genomen op de TID van de rij. De wijzigingstransactie heeft een X-vergrendeling op zijn TID. Andere transacties verkrijgen een S-vergrendeling op de TID om te wachten totdat de eerste transactie voltooid is. Met TID-vergrendeling worden pagina- en rijvergrendelingen nog steeds gebruikt voor wijzigingen, maar elke pagina- en rijvergrendeling wordt vrijgegeven zodra elke rij wordt gewijzigd. De enige vergrendeling tot het einde van de transactie is de enkele X vergrendeling op de TID-resource, waarbij meerdere pagina- en rijvergrendelingen (sleutelvergrendelingen) worden vervangen.

Bekijk het volgende voorbeeld met vergrendelingen voor de huidige sessie terwijl een schrijftransactie actief is:

/* Is optimized locking is enabled? */
SELECT IsOptimizedLockingOn = DATABASEPROPERTYEX(DB_NAME(), 'IsOptimizedLockingOn');

CREATE TABLE t0
(
a int PRIMARY KEY,
b int NULL
);

INSERT INTO t0 VALUES (1,10),(2,20),(3,30);
GO

BEGIN TRANSACTION;

UPDATE t0
SET b = b + 10;

SELECT *
FROM sys.dm_tran_locks
WHERE request_session_id = @@SPID
      AND
      resource_type IN ('PAGE','RID','KEY','XACT');

COMMIT TRANSACTION;
GO

DROP TABLE IF EXISTS t0;

Als geoptimaliseerde vergrendeling is ingeschakeld, bevat de aanvraag slechts één X vergrendeling op de resource XACT (transactie).

Schermopname van de resultatenset van een query op sys.dm_tran_locks voor één sessie toont slechts één vergrendeling wanneer geoptimaliseerde vergrendeling is ingeschakeld.

Als geoptimaliseerde vergrendeling niet is ingeschakeld, bevat dezelfde aanvraag vier vergrendelingen: één IX (exclusieve intentievergrendeling) op de pagina met de rijen en drie X sleutelvergrendelingen op elke rij:

Schermopname van de resultatenset van een query op sys.dm_tran_locks voor één sessie toont drie vergrendelingen wanneer geoptimaliseerde vergrendeling niet is ingeschakeld.

De sys.dm_tran_locks dynamische beheerweergave (DMV) is handig bij het onderzoeken of oplossen van vergrendelingsproblemen, zoals het observeren van geoptimaliseerde vergrendeling in actie.

Vergrendeling na kwalificatie (LAQ)

Voortbouwend op de TID-infrastructuur verandert geoptimaliseerde vergrendeling hoe DML-instructies zoals INSERT, UPDATEen DELETE vergrendelingen verkrijgen.

Zonder geoptimaliseerde vergrendeling worden querypredicaten rij voor rij in een scan gecontroleerd door eerst een update (U) rijvergrendeling te nemen. Als aan het predicaat is voldaan, wordt een exclusieve rijvergrendeling (X) verkregen voordat de rij wordt bijgewerkt en vastgehouden tot het einde van de transactie.

Met geoptimaliseerde vergrendeling en wanneer het READ COMMITTED RCSI (Snapshot Isolation Level) is ingeschakeld, kunnen predicaten optimistisch worden gecontroleerd op de nieuwste vastgelegde versie van de rij zonder vergrendelingen te nemen. Als het predicaat niet voldoet, wordt de query verplaatst naar de volgende rij in de scan. Als aan het predicaat wordt voldaan, wordt er een X-rijvergrendeling genomen om de rij te actualiseren.

Met andere woorden, de vergrendeling wordt genomen na kwalificatie voor wijziging van de rij. De X rijvergrendeling wordt vrijgegeven zodra de rijupdate is voltooid, vóór het einde van de transactie.

Aangezien predicaatevaluatie wordt uitgevoerd zonder dat er vergrendelingen worden verkregen, blokkeren query's die tegelijkertijd verschillende rijen wijzigen elkaar niet.

Bijvoorbeeld:

CREATE TABLE t1
(
a int NOT NULL,
b int NULL
);

INSERT INTO t1
VALUES (1,10),(2,20),(3,30);
GO
Sessie 1 sessie 2
BEGIN TRANSACTION;
UPDATE t1
SET b = b + 10
WHERE a = 1;
BEGIN TRANSACTION;
UPDATE t1
SET b = b + 10
WHERE a = 2;
COMMIT TRANSACTION;
COMMIT TRANSACTION;

Zonder geoptimaliseerde vergrendeling wordt sessie 2 geblokkeerd omdat sessie 1 een U-vergrendeling op de rij houdt die sessie 2 moet bijwerken. Met geoptimaliseerde vergrendeling wordt sessie 2 echter niet geblokkeerd omdat U vergrendelingen niet worden gebruikt en omdat in de meest recente vastgelegde versie van rij 1 kolom a gelijk is aan 1, wat niet voldoet aan het predicaat van sessie 2.

LAQ wordt optimistisch uitgevoerd op basis van de veronderstelling dat een rij niet wordt gewijzigd na het controleren van het predicaat. Als aan het predicaat wordt voldaan en de rij niet is gewijzigd nadat het predicaat is gecontroleerd, wordt deze gewijzigd door de huidige transactie.

Omdat er geen U-sloten worden toegepast, kan een concurrente transactie de rij wijzigen nadat het predicaat is geëvalueerd. Als er een actieve transactie is met een X TID-vergrendeling op de rij, wacht de database-engine totdat deze is voltooid. Als de rij is gewijzigd nadat het predicaat eerder is geëvalueerd, evalueert de database-engine het predicaat opnieuw (herkwalificatie) voordat de rij wordt gewijzigd. Als er nog steeds aan de voorwaarde is voldaan, wordt de rij gewijzigd.

Herkwalificatie van predicaat wordt ondersteund door een subset van de operators van de query-engine. Als het nodig is om het predicaat opnieuw te evalueren, maar het queryplan een operator gebruikt die geen ondersteuning biedt voor predicaatherkwalificatie, beëindigt de database-engine intern de verwerking van de instructie en start deze opnieuw zonder LAQ. Wanneer een dergelijke abort optreedt, wordt de lock_after_qual_stmt_abort uitgebreide gebeurtenis geactiveerd.

Sommige instructies, bijvoorbeeld UPDATE instructies met variabele toewijzing en instructies met de component OUTPUT, kunnen niet worden afgebroken en opnieuw worden gestart zonder de semantiek te wijzigen. Voor dergelijke uitspraken wordt LAQ niet gebruikt.

In het volgende voorbeeld wordt het predicaat opnieuw geëvalueerd omdat een andere transactie de rij heeft gewijzigd:

CREATE TABLE t3
(
a int NOT NULL,
b int NULL
);

INSERT INTO t3 VALUES (1,10),(2,20),(3,30);
GO
sessie 1 Sessie 2
BEGIN TRANSACTION;
UPDATE t3
SET b = b + 10
WHERE a = 1;
BEGIN TRANSACTION;
UPDATE t3
SET b = b + 10
WHERE a = 1;
COMMIT TRANSACTION;
COMMIT TRANSACTION;

LAQ-heuristiek

Zoals beschreven in Lock na kwalificatie (LAQ), kunnen sommige verklaringen intern opnieuw worden opgestart en verwerkt zonder LAQ. Als dit vaak gebeurt, kan de overhead van herhaalde verwerking aanzienlijk worden. Om deze overhead tot een minimum te houden, gebruikt geoptimaliseerde vergrendeling een heuristiekmechanisme om herhaalde verwerking bij te houden. Met dit mechanisme wordt LAQ voor de database uitgeschakeld als de overhead een drempelwaarde overschrijdt.

Voor het heuristische mechanisme wordt het werk dat door een opdracht wordt uitgevoerd gemeten op basis van het aantal verwerkte pagina's (logische leesbewerkingen). Als de database-engine een rij wijzigt die is gewijzigd door een andere transactie nadat de verwerking van de instructie is gestart, wordt het werk dat door de instructie wordt uitgevoerd, behandeld als mogelijk verspild omdat de instructie mogelijk wordt afgebroken en opnieuw wordt gestart. Het systeem houdt het totale potentieel verspilde werk bij en het totale werk dat door alle instructies in de database wordt uitgevoerd.

LAQ is uitgeschakeld voor de database als het percentage van het potentieel verspilde werk een drempelwaarde overschrijdt. LAQ is ook uitgeschakeld als het aantal opnieuw gestarte opdrachten een drempel overschrijdt.

Als het verspilde werk en het aantal opnieuw gestarte instructies onder de respectieve drempelwaarden vallen, wordt LAQ opnieuw ingeschakeld voor de database.

Wijzigingen in querygedrag met geoptimaliseerde vergrendeling en RCSI

Gelijktijdige werkbelastingen onder vastgelegde isolatie van momentopnamen (RCSI) die afhankelijk zijn van een strikte uitvoeringsvolgorde van transacties, kunnen verschillen ondervinden in het querygedrag wanneer geoptimaliseerde vergrendeling is ingeschakeld.

Bekijk het volgende voorbeeld waarbij transactie T2 de tabel bijwerkt t4 op basis van kolom b die is bijgewerkt tijdens transactie T1.

CREATE TABLE t4
(
a int NOT NULL,
b int NULL
);

INSERT INTO t4
VALUES (1,1);
GO
sessie 1 sessie 2
BEGIN TRANSACTION T1;
UPDATE t4
SET b = 2
WHERE a = 1;
BEGIN TRANSACTION T2;
UPDATE t4
SET b = 3
WHERE b = 2;
COMMIT TRANSACTION;
COMMIT TRANSACTION;

Laten we het resultaat van het vorige scenario evalueren met en zonder de vergrendeling na kwalificatie (LAQ).

Zonder LAQ

Zonder LAQ wordt de UPDATE-verklaring in transactie T2 geblokkeerd, wachtend tot transactie T1 is voltooid. Zodra T1 is voltooid, werkt T2 de rij-instellingenkolom bij van b naar 3 omdat aan het predicaat van T2 wordt voldaan.

Nadat beide transacties zijn doorgevoerd, bevat de tabel t4 de volgende rijen:

 a | b
 1 | 3

met LAQ

Met LAQ gebruikt transactie T2 de meest recente vastgelegde versie van de rij, waarbij kolom b gelijk is aan 1 om het predicaat (b = 2) te evalueren. De rij komt niet in aanmerking; daarom wordt het overgeslagen en de opdracht wordt voltooid zonder dat deze is geblokkeerd door transactie T1. In dit voorbeeld verwijdert LAQ blokkeringen, maar leidt dit tot verschillende resultaten.

Nadat beide transacties zijn doorgevoerd, bevat de tabel t4 de volgende rijen:

 a | b
 1 | 2

Belangrijk

Zelfs als LAQ niet in gebruik is, mogen toepassingen niet aannemen dat de database-engine een strikte volgorde van rijen garandeert zonder vergrendelingshints te gebruiken wanneer isolatieniveaus gebaseerd op rijversies worden gebruikt. Onze algemene aanbeveling voor klanten die gelijktijdige workloads uitvoeren onder RCSI die afhankelijk zijn van een strikte uitvoeringsvolgorde van transacties (zoals in het vorige voorbeeld) is om strengere isolatieniveaus te gebruiken, zoals REPEATABLE READ en SERIALIZABLE.

Diagnostische toevoegingen voor geoptimaliseerde vergrendeling

De volgende verbeteringen helpen u bij het bewaken en oplossen van problemen met blokkeren en impasses wanneer geoptimaliseerde vergrendeling is ingeschakeld:

  • Wachttypen voor geoptimaliseerde vergrendeling
    • XACT wachttypen voor de S vergrendeling op de TID en resourcebeschrijvingen in sys.dm_os_wait_stats (Transact-SQL):
      • LCK_M_S_XACT_READ: treedt op wanneer een taak wacht op een gedeelde vergrendeling op een XACTwait_resource type, met een intentie om te lezen.
      • LCK_M_S_XACT_MODIFY: treedt op wanneer een taak wacht op een gedeelde vergrendeling op een XACTwait_resource type, met een intentie om te wijzigen.
      • LCK_M_S_XACT: treedt op wanneer een taak wacht op een gedeelde vergrendeling op een XACTwait_resource type, waarbij de intentie niet kan worden afgeleid. Dit scenario is niet gebruikelijk.
  • Middelenzichtbaarheid vergrendelen
  • Zichtbaarheid van wachtende resources
  • Impassegrafiek
    • Onder elke resource in het impasserapport <resource-list>rapporteert elk <xactlock> element de onderliggende resources en specifieke informatie voor vergrendelingen van elk lid van een impasse. Zie Geoptimaliseerde vergrendelingen en impassesvoor meer informatie en een voorbeeld.
  • Uitgebreide gebeurtenissen
    • De lock_after_qual_stmt_abort gebeurtenis wordt geactiveerd wanneer een instructie intern wordt afgebroken en opnieuw wordt gestart vanwege een conflict met een andere transactie. Zie Lock na kwalificatie (LAQ)voor meer informatie.

Aanbevolen procedures met geoptimaliseerde vergrendeling

Isolatie van vastgelegde momentopnamen inschakelen (RCSI)

Als u de voordelen van geoptimaliseerde vergrendeling wilt maximaliseren, wordt u aangeraden in te schakelen voor het lezen van vastgelegde momentopname-isolatie (RCSI) in de database en READ COMMITTED isolatie te gebruiken als het standaardisolatieniveau. Als dit nog niet is ingeschakeld, schakelt u RCSI in door verbinding te maken met de master-database en de volgende instructie uit te voeren:

ALTER DATABASE [your-database-name] SET READ_COMMITTED_SNAPSHOT ON;

In Azure SQL Database is RCSI standaard ingeschakeld en is READ COMMITTED het standaardisolatieniveau. Wanneer RCSI is ingeschakeld en het READ COMMITTED-isolatieniveau wordt gebruikt, lezen lezers een versie van de rij uit de momentopname aan het begin van de instructie. Met LAQ kwalificeren schrijvers rijen per predicaat op basis van de meest recente vastgelegde versie van de rij en zonder U vergrendelingen te verkrijgen. Met LAQ wacht een query alleen als de rij in aanmerking komt en er een actieve schrijftransactie voor die rij is. Kwalificeren op basis van de meest recente vastgelegde versie en het vergrendelen van alleen de gekwalificeerde rijen vermindert de blokkering en verhoogt de gelijktijdigheid.

Naast verminderde blokkering wordt het vereiste vergrendelingsgeheugen verminderd. Dit komt doordat lezers geen vergrendelingen nemen en schrijvers slechts korte duurvergrendelingen nemen, in plaats van vergrendelingen die tot het einde van de transactie worden bewaard. Wanneer u strengere isolatieniveaus zoals REPEATABLE READ of SERIALIZABLEgebruikt, bevat de database-engine rij- en paginavergrendelingen tot het einde van de transactie, zelfs als geoptimaliseerde vergrendeling is ingeschakeld, voor zowel lezers als schrijvers, wat resulteert in een toegenomen blokkering en vergrendeling van het geheugengebruik.

Vermijd vergrendelingshints

Hoewel tabel- en queryhints zoals UPDLOCK, READCOMMITTEDLOCK, XLOCK, HOLDLOCK, enzovoort worden gehonoreerd wanneer geoptimaliseerde vergrendeling is ingeschakeld, verminderen ze het voordeel van geoptimaliseerde vergrendeling. Vergrendelingshints dwingen de database-engine rij- of paginavergrendelingen te nemen en vast te houden tot het einde van de transactie, om de intentie van de vergrendelingshints te respecteren. Sommige toepassingen hebben logica waarbij vergrendelingshints nodig zijn, bijvoorbeeld wanneer u een rij leest met de UPDLOCK hint en deze later bijwerkt. We raden u aan alleen vergrendelingshints te gebruiken wanneer dat nodig is.

Met geoptimaliseerde vergrendeling zijn er geen beperkingen voor bestaande query's en query's hoeven niet opnieuw te worden geschreven. Query's die geen hints gebruiken, profiteren van geoptimaliseerde vergrendeling.

Een tabelhint voor één tabel in een query schakelt geoptimaliseerde vergrendeling voor andere tabellen in dezelfde query niet uit. Bovendien is geoptimaliseerde vergrendeling alleen van invloed op het vergrendelingsgedrag van tabellen die worden bijgewerkt door een DML-instructie, zoals INSERT, UPDATE, DELETEof MERGE. Bijvoorbeeld:

CREATE TABLE t5
(
a int NOT NULL,
b int NOT NULL
);

CREATE TABLE t6
(
a int NOT NULL,
b int NOT NULL
);
GO

INSERT INTO t5 VALUES (1,10),(2,20),(3,30);
INSERT INTO t6 VALUES (1,10),(2,20),(3,30);
GO

UPDATE t5 SET t5.b = t6.b
FROM t5
INNER JOIN t6 WITH (UPDLOCK)
ON t5.a = t6.a;

In het vorige queryvoorbeeld wordt alleen de tabel t6 beïnvloed door de vergrendelingshint, terwijl t5 nog steeds kan profiteren van geoptimaliseerde vergrendeling.

UPDATE t5
SET t5.b = t6.b
FROM t5 WITH (REPEATABLEREAD)
INNER JOIN t6
ON t5.a = t6.a;

In het vorige queryvoorbeeld gebruikt alleen de tabel t5 het REPEATABLE READ isolatieniveau en wachtvergrendelingen tot het einde van de transactie. Andere updates voor t5 kunnen nog steeds profiteren van geoptimaliseerde vergrendeling. Hetzelfde geldt voor de HOLDLOCK hint.

Veelgestelde vragen (FAQ)

Is geoptimaliseerde vergrendeling standaard ingeschakeld in zowel nieuwe als bestaande databases?

Ja in Azure SQL Database.

Hoe kan ik detecteren of geoptimaliseerde vergrendeling is ingeschakeld?

Zie Is geoptimaliseerde vergrendeling ingeschakeld?.

Wat gebeurt er wanneer versneld databaseherstel (ADR) niet is ingeschakeld voor mijn database?

Als ADR is uitgeschakeld, wordt geoptimaliseerde vergrendeling ook automatisch uitgeschakeld.

Wat moet ik doen als ik wil afdwingen dat query's worden geblokkeerd ondanks geoptimaliseerde vergrendeling?

Voor klanten die RCSI gebruiken, gebruik de query-hint READCOMMITTEDLOCK om blokkeren tussen twee query's af te dwingen wanneer geoptimaliseerde vergrendeling is ingeschakeld.

Wordt geoptimaliseerde vergrendeling gebruikt voor alleen-lezen secundaire replica's?

Nee, omdat DML-instructies niet kunnen worden uitgevoerd op alleen-lezen replica's en de bijbehorende rij- en paginavergrendelingen worden niet gebruikt.

Wordt geoptimaliseerde vergrendeling gebruikt bij het wijzigen van gegevens in tempdb en in tijdelijke tabellen?

Niet op dit moment.

Verwante inhoud