Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Огромное кол-во чтений  [new]
Doctormom
Member

Откуда:
Сообщений: 48
Добрый день всем!

Помогите понять такую в чтениях:

есть таблица
CREATE TABLE [Calculation].[List](
	[PeriodID] [int] NOT NULL,
	[HouseID] [int] NOT NULL,
	[FlatID] [int] NOT NULL,
	[AccountID] [int] NOT NULL,
	[SubListID] [int] NOT NULL,
	[DateBegin] [date] NOT NULL,
	[DateEnd] [date] NULL,
	[TarifValue] [numeric](10, 2) NULL,
	[VolumeValue] [numeric](20, 5) NULL,
	[NormaValue] [numeric](10, 5) NULL,
	[Result]  AS (CONVERT([numeric](20,2),coalesce([VolumeValue],(0))*[TarifValue])) PERSISTED,
 CONSTRAINT [PK_List_11] PRIMARY KEY CLUSTERED 
(
	[PeriodID] ASC,
	[HouseID] ASC,
	[FlatID] ASC,
	[AccountID] ASC,
	[SubListID] ASC,
	[DateBegin] ASC
)


В нее происходит вставка порядка 90 000 строк. Больше в ней ничего нет. Только эти 90 000 строк.

Во такой select выполняет чтения : "Число просмотров 1, логических чтений 877"
declare @Account Account.List

	insert into @Account
Select ID from Adress.Account

select *
	from Calculation.List CL
	inner join @Account A ON A.AccountID = CL.AccountID



Но если сделать delete : "Число просмотров 1, логических чтений 506644"
declare @Account Account.List

	insert into @Account
Select ID from Adress.Account

delete CL
	from Calculation.List CL
	inner join @Account A ON A.AccountID = CL.AccountID


Microsoft SQL Server 2012 - 11.0.5058.0 (X64)
May 14 2014 18:34:29
Copyright (c) Microsoft Corporation
Express Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)

Почему такая огромная разница ?? и что с этим можно сделать ?
13 авг 15, 18:14    [18014706]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
Konst_One
Member

Откуда:
Сообщений: 11540
delete CL
	from Calculation.List CL
	inner join @Account A ON A.AccountID = CL.AccountID


а если так:
delete * 
from Calculation.List
WHERE
    EXISTS (SELECT * FROM @Account A WHERE A.AccountID = Calculation.List.AccountID)
13 авг 15, 18:18    [18014720]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 37069
Ответ как всегда в планах выполнения.
13 авг 15, 18:22    [18014742]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
Doctormom
Member

Откуда:
Сообщений: 48
Konst_One,

Абсолютно одинаково. Ничего не поменялось.
13 авг 15, 18:28    [18014769]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
Doctormom
Member

Откуда:
Сообщений: 48
Гавриленко Сергей Алексеевич,

Планы в приложении.

К сообщению приложен файл (Select.sqlplan - 35Kb) cкачать
13 авг 15, 18:31    [18014778]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
Doctormom
Member

Откуда:
Сообщений: 48
Гавриленко Сергей Алексеевич,

план на DELETE

К сообщению приложен файл (Delete.sqlplan - 26Kb) cкачать
13 авг 15, 18:31    [18014780]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
AlanDenton
Member [скрыт]

Откуда:
Сообщений: 1004
1. OPTION(RECOMPILE)
2. покрывающий индекс на таблицу

мозг уже не варит, но 1-2 должно помочь...
13 авг 15, 18:34    [18014793]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
Doctormom
Member

Откуда:
Сообщений: 48
1. OPTION (RECOMPILE) не помогает. :(
2. Не подскажите какой индекс вы имеете ввиду ?
13 авг 15, 19:48    [18015090]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Пркрывающий индекс на delete?
13 авг 15, 22:31    [18015540]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
Doctormom
Member

Откуда:
Сообщений: 48
Никто не сможет помочь ? хотя бы направить где почитать почему так происходит...
14 авг 15, 00:00    [18015772]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Doctormom,

Добрый день. Сейчас опубликую ответ. Долго писал =) Картинки, все такое =)
14 авг 15, 00:02    [18015778]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
Doctormom
Member

Откуда:
Сообщений: 48
SomewhereSomehow,

Жду с нетерпением. Заранее огромное спасибо.
14 авг 15, 00:12    [18015798]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Спасибо за интересный и хорошо оформленный вопрос!

Если вы указали в вопросе все так, как есть на самом деле, то репро ниже, скорее всего, воспроизводит ситуацию. Буду говорить про него, т.к. на нем есть возможность показать, что и как.

Вкратце «здесь все – и DML, и его теория, и баг сиквела».

Проблема

Репро ( SQL Server 2012)
+
set nocount off;
use opt; -- Any DB
go
-- 1. Prepare Data
if object_id ('dbo.List') is not null drop table dbo.[List];
go
CREATE TABLE dbo.[List](
	[PeriodID] [int] NOT NULL,
	[HouseID] [int] NOT NULL,
	[FlatID] [int] NOT NULL,
	[AccountID] [int] NOT NULL,
	[SubListID] [int] NOT NULL,
	[DateBegin] [date] NOT NULL,
	[DateEnd] [date] NULL,
	[TarifValue] [numeric](10, 2) NULL,
	[VolumeValue] [numeric](20, 5) NULL,
	[NormaValue] [numeric](10, 5) NULL,
	[Result]  AS (CONVERT([numeric](20,2),coalesce([VolumeValue],(0))*[TarifValue])) PERSISTED,
	CONSTRAINT [PK_List_11] PRIMARY KEY CLUSTERED 
	(
		[PeriodID] ASC,
		[HouseID] ASC,
		[FlatID] ASC,
		[AccountID] ASC,
		[SubListID] ASC,
		[DateBegin] ASC
	)
)
go
with cte as (
	select top(83328) rn = row_number() over(order by(select null)) from dbo.t1 cross join t2
)
insert dbo.[List]([PeriodID],[HouseID],[FlatID],[AccountID],[SubListID],[DateBegin],[DateEnd])
select rn, rn, rn, rn, rn, dateadd(mi, rn, '19000101'), null from cte
go
dbcc freeproccache; -- Warning Free Plan Cache!!!
go

-- 2. Repro
declare @Account table(AccountID int primary key);
with cte as (
	select top(83328) rn = row_number() over(order by(select null)) from dbo.t1 cross join t2
)
insert @Account(AccountID)
select top(2688) rn from cte;

set statistics io, xml on;
-- Select
select
	*
from 
	dbo.List CL
	inner join @Account A ON A.AccountID = CL.AccountID
;


-- Delete
delete CL
	from dbo.List CL
	inner join @Account A ON A.AccountID = CL.AccountID
;

set statistics io, xml off;

Результаты по статистике IO:

Картинка с другого сайта.

В случае удаления примерно в 20(!) раз больше чтений.

Объяснение

Давайте сделаем такой же запрос в 2014. Я, конечно, не могу на 100% утверждать, что в 2012 происходит то же самое, но почти уверен, просто выбрал 2014 т.к. там есть средства наглядной демонстрации – что происходит.

Репро (SQL Server 2014) – скрипт тот же – результат, чуть-чуть другой, но порядок сохраняется (есть еще вывод Workfile – но никакого spill туда не происходит, не обращаем внимания на него):

Картинка с другого сайта.

Планы запросов:

Картинка с другого сайта.

Вполне совпадают с тем, что обозначены в теме.

Сделаем немного другой запрос. Который бы находил строки в кластерном индексе таблицы List по кластерному индексу.
+
set nocount off;
use opt; -- Any DB
go
-- 1. Prepare Data
if object_id ('dbo.List') is not null drop table dbo.[List];
go
CREATE TABLE dbo.[List](
	[PeriodID] [int] NOT NULL,
	[HouseID] [int] NOT NULL,
	[FlatID] [int] NOT NULL,
	[AccountID] [int] NOT NULL,
	[SubListID] [int] NOT NULL,
	[DateBegin] [date] NOT NULL,
	[DateEnd] [date] NULL,
	[TarifValue] [numeric](10, 2) NULL,
	[VolumeValue] [numeric](20, 5) NULL,
	[NormaValue] [numeric](10, 5) NULL,
	[Result]  AS (CONVERT([numeric](20,2),coalesce([VolumeValue],(0))*[TarifValue])) PERSISTED,
	CONSTRAINT [PK_List_11] PRIMARY KEY CLUSTERED 
	(
		[PeriodID] ASC,
		[HouseID] ASC,
		[FlatID] ASC,
		[AccountID] ASC,
		[SubListID] ASC,
		[DateBegin] ASC
	)
)
go
with cte as (
	select top(83328) rn = row_number() over(order by(select null)) from dbo.t1 cross join t2
)
insert dbo.[List]([PeriodID],[HouseID],[FlatID],[AccountID],[SubListID],[DateBegin],[DateEnd])
select rn, rn, rn, rn, rn, dateadd(mi, rn, '19000101'), null from cte
go
dbcc freeproccache; -- Warning Free Plan Cache!!!
go

if object_id('tempdb..#read_cursor') is not null drop table #read_cursor;
CREATE TABLE #read_cursor(
	[PeriodID] [int] NOT NULL,
	[HouseID] [int] NOT NULL,
	[FlatID] [int] NOT NULL,
	[AccountID] [int] NOT NULL,
	[SubListID] [int] NOT NULL,
	[DateBegin] [date] NOT NULL,
	CONSTRAINT [PK_List_11] PRIMARY KEY CLUSTERED 
	(
		[PeriodID] ASC,
		[HouseID] ASC,
		[FlatID] ASC,
		[AccountID] ASC,
		[SubListID] ASC,
		[DateBegin] ASC
	)
);
go
declare @Account table(AccountID int primary key);
with cte as (
	select top(83328) rn = row_number() over(order by(select null)) from dbo.t1 cross join t2
)
insert @Account(AccountID)
select top(2688) rn from cte;

-- Read cursor
insert #read_cursor
select
	cl.[PeriodID],
	cl.[HouseID],
	cl.[FlatID],
	cl.[AccountID],
	cl.[SubListID],
	cl.[DateBegin]
from 
	dbo.List CL
	inner join @Account A ON A.AccountID = CL.AccountID
;

-- Write cursor
set statistics io, xml on;
select *
	from dbo.List CL
	inner join #read_cursor rc ON
		cl.[PeriodID] = rc.[PeriodID] and
		cl.[HouseID] = rc.[HouseID] and
		cl.[FlatID] = rc.[FlatID] and
		cl.[AccountID] =rc.[AccountID] and
		cl.[SubListID] = rc.[SubListID] and
		cl.[DateBegin] = rc.[DateBegin]
option(loop join)
;
set statistics io, xml off;

Посмотрим статистику последнего запроса:

Картинка с другого сайта.

Запомним порядок этой цифры.

Что важно – я указал хинт option(loop join), и без хинта у меня на машине выбирает Loop Join, но я хочу подчеркнуть – что нам важно посмотреть – сколько чтений будет из таблицы при лукапе в кластерный индекс. Это число 8241.

Обновления

Вернемся к первоначальному запросу и его плану. Это запрос DML, запрос DML состоит из двух частей:

1. Read cursor – начитывает данные для обновления
2. Write cursor – производит обновления

На данном плане их можно разделить так:

Картинка с другого сайта.

После того, как данные прочитаны, соединены и получено подмножество для обновления (read cursor) – нужно найти и удалить строки в кластерном индексе (write cursor).

Это тот самый лукап в 8241 чтение, который мы наблюдали в предыдущем пункте. С этим – ничего не поделаешь, т.е. грубо говоря, серверу нужно найти ту конкретную строку в кластерном индексе, которую, надо удалить.

Для подтверждения лукапа можно сделать запрос на удаление таким:
-- Delete
delete CL
output deleted.*
from dbo.List CL
inner join @Account A ON A.AccountID = CL.AccountID
;


Заметьте output deleted.* и откуда он получается и берет столбцы:

Картинка с другого сайта.

Сканирование – 6 столбцов в Output, удаление – 11 в Output.


При этом, вне зависимости от того, запрашиваешь ли ты deleted строки или нет – кол-во чтений совпадает. Т.е. delete делает лукап в кластерный индекс.

Вывод

Что можно сделать для уменьшения чтений.

1. Узкий, уникальный, монотонно возрастающий, статичный кластерный индекс. В репро это не проявится, но на практике – очень даже. Чем быстрее лукап, тем лучше.

2. OPTION(RECOMPILE) уже советовали, вам не помогло. Почему вообще могло помочь? Потому, что сиквел имеет такую оптимизацию для DML запросов, как DML Request Sort. Он может ее использовать, когда строк для обновления достаточно много и есть выгода вставить оператор сортировки после получения строк из write cursor-а, чтобы превратить случайный доступ к ключам кластерного, в более-менее последовательный. Есть недокументированный TF 2332 , который форсирует эту оптимизацию, но я не советую его использовать в продакшене, как и любые недокументированные фишки. Вместо этого, если не помогло прослушивание числа строк в табличной переменной – попробуйте временную таблицу. Может быть, статистика на ней, поможет оптимизатору задействовать эту оптимизацию без указаний.

3. Посмотрите фрагментацию вашей таблицы aka кластерного индекса. Перестройте его, в удобное технологическое окно, если есть такая возможность. Конечно, при случайном доступе, кажется, что это не может играть роли, но на практике, сиквел склонен читать с диска блоками много больше чем страница. Даже если у вас нет чтений с диска – перестроение может уплотнить индекс и снизить число логических чтений.

4. Можете ничего не делать из первых трех пунктов, если вас эта ситуация реально не напрягает и удаление проходит приемлемо быстро. Хуже нет, когда пытаются оптимизировать ради оптимизации (исключая, конечно навыки, когда пишут с оглядкой на производительность – это нужно делать всегда, по возможности).

Баг

Итак, мы выяснили, откуда 8 тыс. чтений. Но их же в репро 16! Откуда?

Для этого нужен был 2014 сиквел. И его представление sys.dm_exec_query_profiles. Давайте откроем три окна в SSMS. И далее по шагам.

Шаг 1. Окно 1 – Сессия 1. Запускаем генерацию данных.
+
set nocount off;
use opt; -- Any DB
go
-- 1. Prepare Data
if object_id ('dbo.List') is not null drop table dbo.[List];
go
CREATE TABLE dbo.[List](
	[PeriodID] [int] NOT NULL,
	[HouseID] [int] NOT NULL,
	[FlatID] [int] NOT NULL,
	[AccountID] [int] NOT NULL,
	[SubListID] [int] NOT NULL,
	[DateBegin] [date] NOT NULL,
	[DateEnd] [date] NULL,
	[TarifValue] [numeric](10, 2) NULL,
	[VolumeValue] [numeric](20, 5) NULL,
	[NormaValue] [numeric](10, 5) NULL,
	[Result]  AS (CONVERT([numeric](20,2),coalesce([VolumeValue],(0))*[TarifValue])) PERSISTED,
	CONSTRAINT [PK_List_11] PRIMARY KEY CLUSTERED 
	(
		[PeriodID] ASC,
		[HouseID] ASC,
		[FlatID] ASC,
		[AccountID] ASC,
		[SubListID] ASC,
		[DateBegin] ASC
	)
)
go
with cte as (
	select top(83328) rn = row_number() over(order by(select null)) from dbo.t1 cross join t2
)
insert dbo.[List]([PeriodID],[HouseID],[FlatID],[AccountID],[SubListID],[DateBegin],[DateEnd])
select rn, rn, rn, rn, rn, dateadd(mi, rn, '19000101'), null from cte
go
dbcc freeproccache; -- Warning Free Plan Cache!!!
go

Шаг 2. Окно 2 – Сессия 2. Открываем транзакцию и обновляем одну строку – последнюю строку в таблице List. Держим транзакцию открытой.
+
begin tran
delete dbo.List where AccountID = 83320

--rollback tran

Шаг 3. Окно 1 – Сессия 1. Включаем статистику сбора плана. Запускаем удаление. План выполнения блокируется на последней строке сканирования фазы Probe Hash Join-а. Т.е. к этому моменту – мы удалили из таблицы все строки, но заблокировались на последней строке сканирования таблицы List.
+
set statistics xml, io on;
declare @Account table(AccountID int primary key);
with cte as (
	select top(83328) rn = row_number() over(order by(select null)) from dbo.t1 cross join t2
)
insert @Account(AccountID)
select top(2688) rn from cte;

-- Delete
delete CL
	from dbo.List CL
	inner join @Account A ON A.AccountID = CL.AccountID
;
set statistics xml, io off;

Шаг 4. Окно 3 – Сессия 3. Запускаем диагностику.
+
select
	p.node_id,
	p.physical_operator_name,
	obj_name = object_name(p.object_id),
	idx_name = i.name,
	p.logical_read_count,
	p.*
from 
	sys.dm_exec_query_profiles p
	left join sys.indexes i on p.object_id = i.object_id and p.index_id = i.index_id

Результат:

Картинка с другого сайта.

Шаг 5. Окно 2 – Сессия 2. Откатываем транзакцию.

Шаг 6. Окно 1 – Сессия 1. Наблюдаем, что удаление завершилось.

Число чтений:
Картинка с другого сайта.

8064 + 8897 = 16961.

На 2 страницы разница. Я думаю, это служебные страницы, возможно, GAM, PFS и т.д.

Теперь, вычтем:

8897 – 8064 = 833.

Теперь, повторим наш предыдущий запрос на заполнение read cursor со сбором статистики.

+
set nocount off;
use opt; -- Any DB
go
-- 1. Prepare Data
if object_id ('dbo.List') is not null drop table dbo.[List];
go
CREATE TABLE dbo.[List](
	[PeriodID] [int] NOT NULL,
	[HouseID] [int] NOT NULL,
	[FlatID] [int] NOT NULL,
	[AccountID] [int] NOT NULL,
	[SubListID] [int] NOT NULL,
	[DateBegin] [date] NOT NULL,
	[DateEnd] [date] NULL,
	[TarifValue] [numeric](10, 2) NULL,
	[VolumeValue] [numeric](20, 5) NULL,
	[NormaValue] [numeric](10, 5) NULL,
	[Result]  AS (CONVERT([numeric](20,2),coalesce([VolumeValue],(0))*[TarifValue])) PERSISTED,
	CONSTRAINT [PK_List_11] PRIMARY KEY CLUSTERED 
	(
		[PeriodID] ASC,
		[HouseID] ASC,
		[FlatID] ASC,
		[AccountID] ASC,
		[SubListID] ASC,
		[DateBegin] ASC
	)
)
go
with cte as (
	select top(83328) rn = row_number() over(order by(select null)) from dbo.t1 cross join t2
)
insert dbo.[List]([PeriodID],[HouseID],[FlatID],[AccountID],[SubListID],[DateBegin],[DateEnd])
select rn, rn, rn, rn, rn, dateadd(mi, rn, '19000101'), null from cte
go
dbcc freeproccache; -- Warning Free Plan Cache!!!
go
set statistics io, xml on;
if object_id('tempdb..#read_cursor') is not null drop table #read_cursor;
CREATE TABLE #read_cursor(
	[PeriodID] [int] NOT NULL,
	[HouseID] [int] NOT NULL,
	[FlatID] [int] NOT NULL,
	[AccountID] [int] NOT NULL,
	[SubListID] [int] NOT NULL,
	[DateBegin] [date] NOT NULL,
	CONSTRAINT [PK_List_11] PRIMARY KEY CLUSTERED 
	(
		[PeriodID] ASC,
		[HouseID] ASC,
		[FlatID] ASC,
		[AccountID] ASC,
		[SubListID] ASC,
		[DateBegin] ASC
	)
);
go
declare @Account table(AccountID int primary key);
with cte as (
	select top(83328) rn = row_number() over(order by(select null)) from dbo.t1 cross join t2
)
insert @Account(AccountID)
select top(2688) rn from cte;

-- Read cursor
insert #read_cursor
select
	cl.[PeriodID],
	cl.[HouseID],
	cl.[FlatID],
	cl.[AccountID],
	cl.[SubListID],
	cl.[DateBegin]
from 
	dbo.List CL
	inner join @Account A ON A.AccountID = CL.AccountID
;

set statistics io, xml off;

Картинка с другого сайта.

834 чтения.

833 и 834. Возможно, т.к. таблицы пересоздавались – где-то есть погрешность, возможно, где-то учитывались или нет служебные страницы.

Но что точно понятно это:
Сканирование List – занимает 833 (834) страниц.
Случайный поиск по List по кластерному индексу занимает 8064 (8241) страниц.

Статистика IO суммируется по таблице, но почему-то, если таблица участвует в плане два раза (один раз в read cursor, другой раз в write cursor), то статистика из write cursor повторно записывается при учете read cursor. В итоге получается:

833 + 8064 + 8064 + 2 = 16693

,вместо

833 + 8064 + 2 = 8899

На мой взгляд, это баг. Т.к. реально сервер не осуществляет случайный доступ к таблице в данном плане при формировании курсора чтения.

Попробую зафайлить это на коннект.
14 авг 15, 00:34    [18015854]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
aleks2
Guest
Я наших теорий люблю громадье!!!


--Но если сделать delete : "Число просмотров 1, логических чтений 506644"

--1) хрен знает, как у вас декларирован Account.List
--declare @Account Account.List
-- но надо делать так
declare @Account table(AccountID int primary key clustered); -- правильный индекс лишним не бывает.

insert into @Account
  Select ID from Adress.Account;

create index [IX_List_AccountID] on  [Calculation].[List]
(
	[AccountID] ASC,
);

delete CL
	from Calculation.List CL
	inner join @Account A ON A.AccountID = CL.AccountID
14 авг 15, 05:35    [18016024]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
Doctormom
Member

Откуда:
Сообщений: 48
SomewhereSomehow,

огромное спасибо за развернутый ответ! Буду изучать.
Но в Вашем примере на примере кол-во чтений отличается в 2 раза... Это было бы терпимо. Но у себя я вижу увеличение чтений на порядки :(

Могу ли я для Вас сформировать базу данных с реальными цифрами и запросами и отправить Вам на почту ? Может в таком варианте получится что то прояснить ?
14 авг 15, 13:24    [18017654]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
Doctormom
Member

Откуда:
Сообщений: 48
aleks2,

1. Тип создается таким образом:
CREATE TYPE [Account].[List] AS TABLE(
[AccountID] [int] NOT NULL,
PRIMARY KEY CLUSTERED
(
[AccountID] ASC
)WITH (IGNORE_DUP_KEY = OFF)
)

2. Ваш вариант с индексом не проясняет ситуацию про увеличение чтений данных при удалении на порядки.
14 авг 15, 13:28    [18017681]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Doctormom,

Но почему же в два раза? В два раза отличается отображение из-за, на мой взгляд, бага.
А если вы сравните
Картинка с другого сайта.
834 чтения для SELECT и 16992 для DELETE.
Т.е. отличия в 20 раз. Это на прядок, хотя, конечно, не в 500 раз как у вас.
Если вы можете прислать БД мне на почту, это конечно, будет гораздо удобнее, так что да, присылайте. Единственное, наверное, смогу ответить после выходных - т.к. буду занят.
14 авг 15, 14:27    [18018128]     Ответить | Цитировать Сообщить модератору
 Re: Огромное кол-во чтений  [new]
Doctormom
Member

Откуда:
Сообщений: 48
SomewhereSomehow,

Сегодня постараюсь подготовить ее и вышлю. Срочность не горит. После выходных вполне устроит.
14 авг 15, 14:41    [18018211]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить