Дано:
1C77 Комплексная нетиповая, SQL 2008 R2, база 60 Гб.
Развернул копию базы на другом сервере - открыл обе базы, при попытке открыть документ, справочник, отчет или журнал в копии начинаются висюки. Выражаются в следующем: копия (база в которой собственно и открывается объект) подвисает намертво на период от нескольких секунд до нескольких минут, компьютер частично не дееспособен - то есть, другая база не отвечает на нажатия кнопок мыши и сочетания клавиш, хотя не висит, то есть переключиться в нее я могу, но что-то сделать в ней ничего не получается (ни документ открыть, ни журнал и пункты меню не реагируют на нажатия кнопок мыши), при этом я не могу открыть эксплорер ни через "пуск" (меню пуска открывается, но при нажатии кнопкой мыши на программу, которую я хочу запустить компьютер никак не реагирует), ни через вин-е. Причем количество пунктов меню (Файл, Операция, Справочники, Документы и т.д.) отличается от обычного, то есть например может не быть пункта "Сервис", "Правка" или любого другого.

Замечу, что база и в рабочем (не висящем) режиме не отличается шустростью, но мертвые висюки бывает по нескольку раз в день.
При работе в тестовой базе подвисает каждое второе-третье новое окно.

Вопрос.
Кто сталкивался с подобными висюками и как то решил проблему?

rigus,
1 - демоническое решение :)
2 - 10 рейд с батарейкой - пойдет или как (в рейдах не силен)?
3 - Бесспорно, решение правильное, но одному богу только известно, что именно используется из сущестувующего зоопарка, хотя на это решение я сам уже давно пристально смотрю.
4 - Не раньше чем через год :)

Критик,
1 - спасибо, уже озадачил админов.
2 - точно, совсем забыл.
3 - а разве sql сам не обновляет статистику?

Zerro,
Xeon(TM) 3.2 GHz; память: 3 ГБ; диск 10 Raid - сервер на котором лежит md (на нем лежат все мд-шники)
Xeon R E5504 2 GHz; память: 8 ГБ; диск 10 Raid - сервер, на котором лежит тестовая база
Xeon R E5620 2.4 GHz; память: 12 ГБ; диск 10 Raid - сервер, на котором лежит рабочая база

А что интересует по сети?

rigus,

Результат третьего запроса (топ 10):

Тестовая база

LAZYWRITER_SLEEP 1856646 1575338688 206965340 68559
REQUEST_FOR_DEADLOCK_SEARCH 159555 797770361 5031 797770361
XE_TIMER_EVENT 26594 797761718 30004 797759994
SQLTRACE_BUFFER_FLUSH 199404 797612362 4031 0
LOGMGR_QUEUE 465277 795678904 43215914 2046
FT_IFTS_SCHEDULER_IDLE_WAIT 13187 791163155 60030 49
CHECKPOINT_QUEUE 666034 773634462 177759958 374153
XE_DISPATCHER_WAIT 10 430891696 392341733 0
SLEEP_TASK 5150129 404620971 1108 68610
BROKER_TO_FLUSH 389164 398883332 1930 1240

Рабочая база:

LAZYWRITER_SLEEP 19578053 5410117160 86399138 284166
LOGMGR_QUEUE 1195508 2706547953 82285194 69761
XE_TIMER_EVENT 90219 2706516052 30605 2706513818
SQLTRACE_BUFFER_FLUSH 676500 2706316217 5787 51752
REQUEST_FOR_DEADLOCK_SEARCH 541241 2706074628 5666 2706074628
CHECKPOINT_QUEUE 989786 2705713857 54975294 15441
XE_DISPATCHER_WAIT 122 2689323718 86821833 0
FT_IFTS_SCHEDULER_IDLE_WAIT 44736 2684155574 61718 15560
SLEEP_TASK 12074155 1353877929 4146 153632
BROKER_TO_FLUSH 1320350 1353081210 3345 93324


Первые два не выполняются, возможно из-за того что база в режиме совместимости 80.

Сообщение 208, уровень 16, состояние 1, строка 1
Недопустимое имя объекта "sysaltfiles".
хотя в тексте запроса "sysaltfiles" выделено зелененьким

Zerro,
Замеры где в 1с? Мол не выполняется ли там что? Делали - ничего в 1с не выполняется, просто тупое ожидание чего то. Предполагал что висят только формы у которых модуль вынесен во внешний файл - не угадал - висят все формы. В настройках стоит обновление 60 сек.
В sql в профайлере смотрел - очень много выполнений "sp_cursorfetch" - и количество выполнений и время цп - количество выполнений всегда много, время цп много только когда висит база - но это я замерял без тестовой базы, то есть рабочую базу мерял. Что именно выполняется по этой команде я до конца так и не понял.
Есть другие тяжелые запросы (опять речь про рабочую базу), но там по крайней мере понятно что происходит
- выгрузка цен торговым агентам (на самом деле надо переписывать на прямой запрос к SQL - выгрузка сделана тупой выборкой, а 1с-овый запрос падает на 500 000 ценах) - висюки начинаются только, если количество запросов к базе данных (согласно монитору SQL) превышает 6000-7000 - это одновременная выгрузка по 5-7 агентам - ситуация крайне редкая;
- установка цен на номенклатуру (происходит блокировка спарвочника цен - там порядка 11 000 000 записей) - после перевода на новый сервер жалоб нет, хотя я думаю пользователи просто привыкли к тормозам в базе и уже не обращают внимания, если база висит в пределах минуты;
- проведение выписок и расходных накладных (тут понятно что блокировка идет на таблицу с документами (_1sjourn 3 500 000 записей и _1SCRDOC 13 500 000 записей) - тут возникают именно блокировки, хотя возможно есть и тормоза;
- автоматическая загрузка заявок (запись и проведение) и расходных накладных (только запись) от торговых агентов - тут тормоза возникают по следующей причине - на серваке висит несколько клиентских 1с, которые периодически опрашивают файлообменники и пишут в 1с заявки и расходные - так вот косяк возникает в том случае, когда два или более клиента одновременно пытаются загрузить документы, то есть один начала грузить заявку, тут же второй пытается записать другую заявку - таблица занята, он ждет - как только таблица освобождается он пытается записать туда свою заявку, но косяк в том, что первый клиент сразу после загрузки заявки пытается записать накладную, а если второй агент пишет заявку, то первый висит в ожидании - подобные ситуации не редкость, потому что клиентов подгружающих заявки аж 8 штук. Замечено, что когда имеет место быть такая ситуация загрузка процессора (по монитору SQL) 15-30 %, пользователи жалуются на висюки, а база висит очень сильно - приходится резать подвисшие сессии.

Ребят, спасбио за участие, но я завтра отвечу - сейчас убегаю.

Zerroну мы сервера мд (терминальный) и скуль прямым кабелем соединяли. гигабит чтоб был без хабов. Может хаб тормозит между ними. Какой стоит?
Такая же ситуация - гигабитка между серверами.

Господин ПЖ>3 - а разве sql сам не обновляет статистику?

смотря чего с опциями в нем
Где глянуть?

КритикЕще, база tempdb должна лежать на быстром дисковом массиве.
Часто оставляют на системном диске, что фатально отражается на производительности.
На обоих серверах tempdb лежит на диске D.

rigusпервые два запроса нужно запускать к базе master

SELECT db_name(fs.dbid),f.name, f.filename, fs.NumberReads, fs. NumberWrites, fs. BytesRead/1024/1024 as [MB прочитано], fs.BytesWritten/1024/1024 as [MB записано], fs.IoStallMS/1000 as [сумм.ожидание в сек],fs.IoStallReadMS/1000 as [ожидание чтения в сек],fs.IoStallWriteMS/1000 as [ожидание записи в сек]
FROM ::fn_virtualfilestats(DEFAULT, DEFAULT ) fs
join sysaltfiles f on f.dbid= fs.dbid and f.fileid=fs.fileid order by ioStallWriteMs DESC

рабочий сервер

base Base_Data D:\SQL_Data\SQL_2008_1\base.MDF 1480523 356618 685771 3636 171567 27411 144156
tempdb tempdev D:\SQL_Data\SQL_2008_1\tempdb.mdf 1457356 10896343 81612 675843 20563 2741 17821
tempdb templog D:\SQL_Data\SQL_2008_1\templog.ldf 101 1319847 1 58151 1924 0 1924
base Base_Log D:\SQL_Data\SQL_2008_1\base_1.LDF 72 389461 2 1741 200 0 200

тестовый сервер

base_dev Base_Data D:\SQL\MSSQL10.DEV\MSSQL\DATA\base_dev.MDF 4515229 1242181 98699 101089 261330 144466 116864
base_dev Base_Log D:\SQL\MSSQL10.DEV\MSSQL\DATA\base_dev.LDF 3539 2287400 14 119246 42276 0 42276
tempdb tempdev D:\SQL\MSSQL10.DEV\MSSQL\DATA\tempdb.mdf 1410149 275653 25073 20904 37543 1240 36302
tempdb templog D:\SQL\MSSQL10.DEV\MSSQL\DATA\templog.ldf 189 9498 1 466 352 0 352

SELECT left(f.filename,1), sum(fs.NumberReads),sum( fs. NumberWrites),sum( fs. BytesRead/1024/1024) as [MB прочитано],sum( fs.BytesWritten/1024/1024) as [MB записано], sum(fs.IoStallMS/1000) as [сумм.ожидание в сек],sum(fs.IoStallReadMS/1000) as [ожидание чтения в сек],sum(fs.IoStallWriteMS/1000) as [ожидание записи в сек]
FROM ::fn_virtualfilestats(DEFAULT, DEFAULT ) fs
join sysaltfiles f on f.dbid= fs.dbid and f.fileid=fs.fileid
group by left(f.filename,1) order by [ожидание записи в сек] DESC

рабочий сервер

D 2939841 12962733 767465 739379 194258 30156 164101
C 1741 3847 95 16 15 13 0

тестовый сервер

D 5930271 3815734 123837 241707 341556 145718 195835

Вохможно изложение информации не самое удобное, но я не понял как таблицы вставлять с заголовками. Если подскажете как - выложу в более удобном варианте.

rigus1. SQLTRACE_BUFFER_FLUSH
Трассировку отключи
как то так
2. База в каком режме? Simple, Full? (Если Full, то иеет смыл выделить под логи отдельный raid массив (или если не делаются бекапы логов то перевести в simple))

1 - надо почитать сначала что эта трассировка делает.
2 - симпл

mangust_02,

У меня 77, а не 80.

Кстати, когда я работаю напрямую на тестовом сервере (в терминале) тормозов ни разу не было.

Zerro,
Сам периодически на нее думаю.
Но есть следующая ситуация - при попытке работать в таком режиме (две базы, несколько открытых форм) с другого компа, по параметрах идентичным моему компьютеру проблема налицо, при попытке получить проблему на нетбуке - проблема отсутствует - то есть открыты несколько баз (3-4 сеанса двух разных баз) с двух серверов (рабочий и тестовый), открыто несколько форм, формируются отчеты, открываются элементы справочников, документы - и в процессе всего этого действа тормозов нет.
Характеристики моего компьютера:
Intel® Core™ i3 CPU 540 @ 3.07GHz, 4 Ггб оперативно памяти.
Характеристики нетбука:
Atom n270, 2Ггб
Замер производился одновременно, были открыты обе базы на обоих компьютерах, одновременно нажимались кнопки, оба компьютера были подсоединены к одному свичу - в итоге на моем компьютере база висит, на нетбуке есть небольшие тормоза связаные с характеристиками.

Критик,
В этом ты прав, когда тестовый сервер был рабочим была просто вешалка для пользователей, база висела каждые 5 минут.

rigus,
buh buh D:\SQL_Data\SQL_2008_buh\buh.mdf 6768702 2599898 1149497 26066 2668973 1246390 1422582 0,547168389
tempdb tempdev D:\SQL_Data\SQL_2008_buh\tempdb.mdf 1330888 1640352 80416 101319 13134 8047 5086 0,003100554
buh buh_log D:\SQL_Data\SQL_2008_buh\buh_1.ldf 337 366296 3 9809 529 3 525 0,001433267
tempdb templog D:\SQL_Data\SQL_2008_buh\templog.ldf 99 121568 1 5353 100 0 100 0,000822585

Вот кстати данные с другого инстанса SQL (это тот же рабочий сервер, но на нем висят два инстанса), на другой рабочей базе (buh) опять ахренительный коэффициент записи/ожидания.
И в целом показатель тоже не ацти (0,3), может приоритет какой выставить?

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

Дело было не в бобине...
Решили мы проблему подвисания базы при открытии форм.
Проблема была вовсе не с сервером, хотя тут тоже не вес гладко - проблема связана с тем, что на клиентском компе 4 Гб оперативной памяти и стоит WIN XP.
Было два вариант решения - установить х64 винду или исправить что-то в ветке
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Windows
Что именно надо исправить не знаю, этим занимался одмин.