mssql 2000 - blokowania tabeli podczas transakcji

[Adam]

Witam

Mam problem w aplikacji, która podczas wstawiania wielu wierszy do
tabeli blokuje dostęp do niej dla innych transakcji. Skrypt create dla
tej tabeli:

CREATE TABLE [dbo].[Tabelka](
[id] [int] IDENTITY(1,1) NOT NULL,
[idTypu] [int] NOT NULL,
....
[idTabelkiNadrzednej] [int] NULL,
CONSTRAINT [PK_Tabelka] PRIMARY KEY CLUSTERED
(
[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY
= OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO
SET ANSI_PADDING OFF
GO
ALTER TABLE [dbo].[Tabelka] WITH CHECK ADD FOREIGN KEY
([idTabelkiNadrzednej])
REFERENCES [dbo].[Tabelka] ([id])

Podczas transakcji gdy wstawiam wiersze do tej tabeli, jest ona
zablokowana do czasu zakończenia obecnej transakcji. Gdy wykonuję
zapytanie: select count(*) from tabelka, zapytanie wisi, aż zakończy
się transakcja wstawiająca wiersze. Mam ustawiony poziom izolacji
READ_COMMITED, więc zapytanie powinno zwrócić ilość wierszy bez tych
wstawianych w obecnie trwającej transakcji bez oczekiwania na jej
zakończenie. Gdy sprawdzam jakie są locki założone na tabeli to widzę,
że są to głównie PAG i KEY, więc na podstawie dokumentacji domniemam,
że jest to związane z przebudowywaniem się indeksu tabeli podczas
wstawiania wierszy do tabeli. Jest klucz główny:
CONSTRAINT [PK_Tabelka] PRIMARY KEY CLUSTERED
(
[id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY
= OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

podejrzewam, że atrybuty ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON
powodują te blokady. Czy mogę zmienić te atrybuty w prosty sposób na
OFF? Niestety od tej kolumny [id] zależy wiele innych tabel - dużo
kluczy obcych - i nie mogę po prostu zrobić drop i add. Czy zmiana
tych atrybutów będzie miała jakieś poważne konsekwencje? To co chcę
osiągnąć, to żeby READ_COMMITED się zachowywało jako READ_COMMITED a
nie SERIALIZABLE.

Pozdrawiam

[Maciej Pilichowski]

On Tue, 15 Dec 2009 08:21:20 -0800 (PST), Adam
<adam.m...@gmail.com> wrote:

>Mam problem w aplikacji, która podczas wstawiania wielu wierszy do
>tabeli blokuje dostęp do niej dla innych transakcji.

Nie wiem, czy Cie dobrze naprowadze, bo z 2K mialem stycznosc dawno
temu, ale to moze byc efekt tego, ze od pewnego poziomu przy
wstawianiu rekordow serwer uznaje, ze lepiej bedzie odciac innych od
tabeli, wykonac zmiany i przywrocic dostep. Liczba rekordow jest
parametryzowana.

> Niestety od tej kolumny [id] zależy wiele innych tabel - dużo
>kluczy obcych - i nie mogę po prostu zrobić drop i add.

Przede wszystkim zwroc uwage, ze masz index typu clustered.
Dopisywanie duzych liczby rekordow jest _kosztowne_. Moze rozwiazaniem
byloby odpuszczenie tego indeksu, wrzucenie rekordow, dodanie go z
powrotem. Nie naruszy to integralnosci danych, a moze bedzie szybsze.

milego dnia, hej

[gregorius]

Adam pisze:
[...]

> Podczas transakcji gdy wstawiam wiersze do tej tabeli, jest ona

> zablokowana do czasu zako�czenia obecnej transakcji. Gdy wykonuj�
> zapytanie: select count(*) from tabelka, zapytanie wisi, a� zako�czy
> si� transakcja wstawiaj�ca wiersze. Mam ustawiony poziom izolacji
> READ_COMMITED, wi�c zapytanie powinno zwr�ci� ilo�� wierszy bez tych
> wstawianych w obecnie trwaj�cej transakcji bez oczekiwania na jej
> zako�czenie. Gdy sprawdzam jakie s� locki za�o�one na tabeli to widz�,
> �e s� to g��wnie PAG i KEY, wi�c na podstawie dokumentacji domniemam,
> �e jest to zwi�zane z przebudowywaniem si� indeksu tabeli podczas
> wstawiania wierszy do tabeli. Jest klucz g��wny:

> CONSTRAINT [PK_Tabelka] PRIMARY KEY CLUSTERED
> (
> [id] ASC
> )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY
> = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
> ) ON [PRIMARY]
>

> podejrzewam, �e atrybuty ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON
> powoduj� te blokady. Czy mog� zmieni� te atrybuty w prosty spos�b na
> OFF? Niestety od tej kolumny [id] zale�y wiele innych tabel - du�o
> kluczy obcych - i nie mogďż˝ po prostu zrobiďż˝ drop i add. Czy zmiana
> tych atrybut�w b�dzie mia�a jakie� powa�ne konsekwencje? To co chc�
> osi�gn��, to �eby READ_COMMITED si� zachowywa�o jako READ_COMMITED a
> nie SERIALIZABLE.

Poziom READ COMMITED w�a�nie tak dzia�a. W 2005 wprowadzono READ
SNAPSHOT (czego zapewne oczekujesz), ale w 2000 go nie ma - wi�c albo
czekasz na zako�czenie transakcji, albo musisz skorzysta� z poziomu READ
UNCOMMITED.

Pozdrawiam

--
gregorius
Odpowiadaj�c usu� spamerom_nie. z adresu.