Резко упала производительность сервера - Компьютерный форум OSzone.net

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)

- Программирование и базы данных (http://forum.oszone.net/forumdisplay.php?f=21)

- - Резко упала производительность сервера (http://forum.oszone.net/showthread.php?t=142110)

Резко упала производительность сервера

ХП обрабатыват таблицу около 500 т. записей - все летало достаточно прилично
НИЧЕГО не менял ни в коде ни в настройках сервера

Вдруг скорость обработки упала в разы, если не в 10-ки раз.
С чего это и как вернуть?

Код:

select @@version

Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (Intel X86)   Mar 29 2009 10:27:29   Copyright (c) 1988-2008 Microsoft Corporation  Enterprise Evaluation Edition on Windows NT 6.0 <X86> (Build 6000: )

Код:

exec sp_configure

name        minimum        maximum        config_value        run_value

allow updates        0        1        0        0

backup compression default        0        1        0        0

clr enabled        0        1        1        1

cross db ownership chaining        0        1        0        0

default language        0        9999        21        21

filestream access level        0        2        0        0

max text repl size (B)        -1        2147483647        65536        65536

nested triggers        0        1        1        1

remote access        0        1        1        1

remote admin connections        0        1        0        0

remote login timeout (s)        0        2147483647        20        20

remote proc trans        0        1        0        0

remote query timeout (s)        0        2147483647        600        600

server trigger recursion        0        1        1        1

show advanced options        0        1        0        0

user options        0        32767        0        0

в начале ХП рабочие таблицы чистятся DELETE-ом вставляются новые данные.
Таблиц две
Превая

Код:

 CREATE TABLE [dbo].[t_InStudy](

        [D] [datetime] NOT NULL,

        [H] [decimal](10, 6) NOT NULL,

        [L] [decimal](10, 6) NOT NULL,

PRIMARY KEY CLUSTERED 

( [D] ASC )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

) ON [PRIMARY]

Вторая

Код:

CREATE TABLE [dbo].[t_CommonStudy](

        [T0] [datetime] NOT NULL,

        [P1] [decimal](10, 5) NULL,

        [PMax] [decimal](10, 5) NULL,

        [TMax] [datetime] NULL,

        [PMin] [decimal](10, 5) NULL,

        [TMin] [datetime] NULL,

PRIMARY KEY CLUSTERED 

( [T0] ASC )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

) ON [PRIMARY]

Затем делается

Код:

        Delete from t_CommonStudy

        Insert Into t_CommonStudy (T0) Select D from t_InStudy

Т.е. индексы свежие

Запрос фактически один

Код:

 UPDATE t_CommonStudy  Set  

PMax = (Select MAX(H) From t_InStudy where T0 > D And T0 <= D + Cast( 'янв  1 1900 12:30AM' as datetime ) ), 

PMin = (Select MIN(L) From t_InStudy where T0 > D And T0 <= D + Cast( 'янв  1 1900 12:30AM' as datetime ) )

Where P1 is NULL

т.е. ищем макс и минимум в пердыдущем периоде от T0 (текущего значения) до T0 минус 'янв 1 1900 12:30AM' для каждой записи.

работало как пулемет - все считалось за несколько минут
теперь второй день тормозит по страшному.
Код тот же, набор данных тот же, структура данных тажа.

Настройка лога

Код:

Нач. размер 1078

Авторасширение 10%, рост ограничен до 2097152МБ

Был размер 1,05 ГБ (1 130 299 392 байт)

Сделал Бекап - стало

Код:

Размер БД стал 875 МБ

Размер ЛОГа стал 51 МБ

Скорость НЕ ВОЗРОСЛА

ПОМОГИТЕ ПОЖАЛУЙСТА!!!

Цитата:

Цитата namenike

работало как пулемет - все считалось за несколько минут
теперь второй день тормозит по страшному.
Код тот же, набор данных тот же, структура данных тажа. »

Если сервер не перегружали, то блокировки (deadlock) посмотрите.

сервер перезагружался в силу того, что машина перезагружаласть

на машине только один пользователь - это ноут
одновременно задачи не запускал - думаю, что Деедлок здесь ни причем - ему просто неоткуда взяться.

Во время выполнения ХП апдейт внутри него так блокирует таблицу, что из
Манаджмент Студио запрос к этой таблице (экспеерментировал) висит намертво и ничего не выдает.

Объем Лог файла во время выполнения ХП скачет в пределах от 7 до 500 МБ несколько раз меняя свое значение

При создании таблиц вы используете первичные кластерные ключи.
Надеюсь, вы это делаете осознано и понимаете что вставка любого значения "между", будет сопровождаться физическим упорядочиванием таблицы по первичному кластерному ключу.
А это при 500 тыс записях немножко долго.

тормоза НЕ на вставке, на на апдейте