Låser oppstår på IBM DB2 -serveren hver gang du utfører en spørring , sette inn, oppdatere eller slette . Tabeller har en " LOCKSIZE " parameter som kan påvirke låsing. Tabellen innstillingen av " LOCKSIZE NOEN " lar DB2 å velge størrelsen på låsen , vanligvis anskaffe side låser. SQL-spørringen uttalelser kan påvirke låsing ved å sette en " isolert nivå " i begynnelsen av transaksjonen . Selv når det gir en bestemt lås, kan DB2 fremme eller eskalere låsen , og derfor må du forstå hvordan DB2 håndterer låsing når du skriver databaseapplikasjoner. Programmerere kan sette låsen nivå for å forbedre ytelsen database med " LOCK TABLE "-kommandoen , men. Instruksjoner
en

Lås hele tabellen i delt modus eller eksklusiv modus . Execute " LOCK TABLE MyTable i eksklusive MODE" (bytt ut " MyTable " med navnet på DB2-tabell ) for å holde låsen på hele tabellen før transaksjonen er fullført. Denne modusen hindrer andre brukere fra å få tilgang bordet før du åpne låsen.
2

Execute " LOCK TABLE MyTable i aksjekursene MODE" for å tillate kun lesetilgang til bordet i løpet av transaksjonen . Denne modusen holder dataene konsistente samtidig gir brukerne kunne se den . Den " LOCK TABLE " kommandoen kan forbedre ytelsen og forhindre " vranglås " ved å lage en lås på hele tabellen i stedet for flere individuelle rad låser.
3

åpne låsen ved hjelp av " RELEASE ( COMMIT ) "eller" RELEASE ( deallocate ) " --- dine to alternativer når du utfører den " lOCK TABLE "statement som statisk SQL. " RELEASE ( COMMIT ) " vil åpne låsen etter henrettelsen av en" COMMIT "statement. " RELEASE ( deallocate )" vil åpne låsen når programmet avsluttes.
4

Slipp låsen når du utfører " LOCK TABLE " statement som dynamisk SQL med " RELEASE ( COMMIT )" . Hvis du bruker caching, holder DB2 forberedt uttalelser i minnet etter en " COMMIT " , og derfor må du deallocate låsen eller utføre en " COMMIT " etter de preparerte uttalelser er ikke lenger i minnet for å frigjøre låsen