- Remove From My Forums
-
Вопрос
-
Ситуация такая, утром операторы проводят и распечатывают документы. В это время через раз, день есть день нет, 1с у всех тормазит, т.е. не даёт создать новый документ, провести, снять проводку. После начала одной из этих операций 1с-ка задумывается и выдаёт ошибку sql server-a.
—————————
1С:Предприятие
—————————
При выполнении транзакции произошла ошибка!
SQL State: HYT00
Native: 0
Message: [Microsoft][ODBC SQL Server Driver]Время ожидания истеклоПовторить попытку выполнить транзакцию?
—————————
Да Нет
—————————
Днём один оператор распечатывает уже проведённые документы в течении примерно 15-20 минут. В это время 1с висит у всех 100%. Ничего кроме распечатывания документов в это время не делается.
Конфа:
Win2k3 sp1
Sql 2000
1c 7.7. Работает через сервер терминалов.
Пользователей около 40.
Кроме как 1с и немного файл шаринга на этом сервере ничего нет.Замерялась загрузка сервера с помощью оснастки Perfomance. Слабых мест железа не обнаружено.
Поменял в 1с параметры :
Период опроса изменений бд: 90
Время ожидания захвата таблицы: 180
Результат данных действий узнаю чуть позже, но мне кажется что ничего не изменится.Что это может быть? как убрать эти тормоза?
Ответы
-
Тут надо программистов напрягать, потому что запрос надо смотреть не в SQL, а в конфигурации 1С.
«В процессе выполнения самых простых действий 1С
блокирует множество записей в разных таблицах SQL. Это можно увидеть,
запустив на SQL сервере стандартную процедуру sp_lock.
Может быть, не слишком наглядно, но Вы можете увидеть какие номера
пользователей что заблокировали. Для того, чтобы определить, какие
пользователи соответствуют этим безликим номерам, запустите процедуру
sp_who. Некоторый дискомфорт вызывает то обстоятельство, что все
пользователи 1С работают из-под одного имени пользователя. И различать
в списке sp_who можно тольно по hostname — имени компьютера.
«А это обработки для 1С
Пробуйте это :
http://softsearch.ru/programs/117-215-blokirovki-1s-sql-download.shtml
Либо оригинал
http://1c.proclub.ru/modules/mydownloads/personal.php?cid=79&lid=4188
aka Pupus -(Porter)-
-
Помечено в качестве ответа
12 марта 2013 г. 13:46
-
Помечено в качестве ответа
Hi,
I am getting similar error «SqlState HYT00, Login timeout expired
A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct
and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.
TCP Provider: Error code 0x6F»
while trying to connect from Linux using «sqlcmd -S VM-5555 -U DWH_ETL»
whereas
I am able to connect the same server and instance from MS SQL management studio, I am also able to ping the server from backend.
Entries of .ini are
$cat
odbc.ini
[VM-5555]
Driver=/opt/microsoft/sqlncli/lib64/libsqlncli-11.0.so.1790.0
Server=tcp:VM-5555.xxx.nsroot.netMSSQL_DWH_SIT,1443
Database=DWH_Report_SIT
cat
odbcinst.ini
[SQL Server Native Client 11.0]
Description=Microsoft SQL Server ODBC Driver V1.0 for Linux
Driver=/opt/microsoft/sqlncli/lib64/libsqlncli-11.0.so.1790.0
Threading=1
UsageCount=1
I tried & \ before instance name.
I was also able to connect other server from Linux, but without using the instance name.
that time entry in .ini was similar
cat
odbc.ini_old
[VM-1272-6223]
Driver=/opt/microsoft/sqlncli/lib64/libsqlncli-11.0.so.1790.0
Server=tcp:vm-1222.xxx.nsroot.net
Database=DWH_Report_DEV
Can someone pls suggest what is wrong or how can I eliminate contributing factor.
thanks
08.05.07 — 18:52
Очень надеюсь на вашу помощь, хочу разобраться в следующей ситуации. Итак, имелось 1С 7.7 (25), ТиС, SQL Server 2000 — 8.00.679(SP2), практически год безупречной работы. Сегодня при попытке проведения счета-фактуры появилась ошмбка SQL State: HYT00 Native: 0 Message: [Microsoft][ODBC SQL Server Driver]Время ожидания истекло, попытка повторить транзакцию к успеху не привела. Соответственно на всех машинах в сети, то же самое. Работа остановилась. Перезапустил SQL сервер — то же самое, перезагрузил сервер — эффекта 0. Отключив сервер от сети, попробовал зайти с него в 1С и создать новую реализацию, при попытке записать — SQL State: HYT00 Native: 0 Message: [Microsoft][ODBC SQL Server Driver]Timeout expired. Почитал всякие посты на всевозможных форумах. Отключил named pipes, оставив только TCP/IP, попробовал зайти с рабочей станции — без named pipes соединяться с SQL почему-то отказался. Опять же отключив сервер от сети, зашел с него в 1С. Реализация не записывалась с указанной выше ошибкой. Минут 15 пробовал всевозможные варианты, затем в конфигураторе прописал в параметрах соединения с базой, вместо имени сервера sqlserver IP’шник — 127.0.0.1, запустил Profiler, открыл базу и попробовал записать реализацию. На этот раз ошибка не появилась, но судя по профайлеру он «думал» над каким-то select’ом из таблицы DH1611 (судя по 1Cv7.DDS — как раз документ реализация) добрых 5 минут, при этом это было достаточно заметно по активности винтов в RAID’е. После чего реализация все-таки записалась и все вернулось к нормальной работе. Вернул named pipes, сейчас все работает. Вопрос, который мне не дает покоя. ЧТО ЭТО БЫЛО? Почему до того как я прописал вместо имени sql сервера его 127.0.0.1 документ не записывался, совпадение? Может быть дадите какие-то рекомендации, в плане — как исключить в дальнейшем подобную ситуацию, порядок действий при ее возникновении, выяснение причины произошедшего? Стоит ли обновить SQL Server до SP3? Может быть проблема именно в этом? Возможно ли возникновение такой ситуации (может быть сейчас глупо прозвучит, но все же) из-за какой-то внутренней блокировки таблиц в SQL? Как вы понимаете после перезагрузки сервера отключенного от сети, пользователи не работали, никакие ресурсоемкие отчеты и т.п. не выполнялись … вообщем я не знаю на что и думать. Надеюсь на вашу помощь.
2 — 08.05.07 — 18:54
+0: http://www.mista.ru/kb/topic4990.htm — это читал. Если все дело, по вашему мнению, в версии SQL, то какой на данный момент последний SP к нему, и последняя версия драйверов ODBC?
3 — 08.05.07 — 19:16
ну в (2) не совсем то. что нужно. Почитай логи скуля, системы… просто так ничего не бывает.
4 — 08.05.07 — 19:33
(3) у меня была похожая проблема. База самописка, достаточно легкая — локально на моем компьютере при записи база висла и могла висеть несколько минут — потом ошибка, почти как в (0). Пробовал даже переставить sql и выгрузку/загрузку — не помогало. В результате я взял рабочий МД из каталога БД и у клиента новый архив базы. После восстановления из архива — все заработало. Что это было так и не понял. Уже прошло полгода — на рабочей таких багов не замечается.
P.S. В базе много прямых запросов.
Модератор
5 — 08.05.07 — 19:33
(0) Кто-то заблокировал проведение документов, и пошел обедать (например, в модуле проведения есть модальное окно). Даже если его нет, в движке 1С есть ошибка, когда окно «Недостаточно прав доступа» открывается именно внутри транзакции проведения.
Кто именно всех блокирует, можно посмотреть в Enterprise Manager.
Как вариант, можно всех выгнать и попросить заново войти
(я использую выгонялку Книга знаний: Альтернативное стартовое окно для 1С:Предприятие 7.7 ).
6 — 08.05.07 — 19:34
(5) а почему после перезагрузки сервера ошибка не пропала? Врядли в этом дело.
Модератор
7 — 08.05.07 — 19:42
(6) Даже не знаю как это могло получиться, ск. всего внутренняя ошибка MS-SQL.
Имеет смысл обновить движок, почистить папку временных файлов, сделать стоп-старт серверу, выгрузить-загрузить…
Также возможно имеет смысл поставить последний сервис-пак MS-SQL (там же наверняка исправляются всякие ошибки).
8 — 08.05.07 — 19:58
В логах «C:Program FilesMicrosoft SQL ServerMSSQLLOG» есть только упоминание о:
2007-05-08 17:27:42.65 spid8 The header for file ‘C:Program FilesMicrosoft SQL ServerMSSQLdatamsdblog.ldf’ is not a valid database file header. The PageAudit property is incorrect.
2007-05-08 17:27:42.65 spid8 Device activation error. The physical file name ‘C:Program FilesMicrosoft SQL ServerMSSQLdatamsdblog.ldf’ may be incorrect.
В Enterprise Manager’е она значится, как msdb (Suspect) … Может ли это иметь отношение к моей проблеме, что это за DB такая, и как ее вывести из состояния suspect?
9 — 08.05.07 — 20:00
а лог файл каких размеров?..
10 — 08.05.07 — 20:04
В смысле? errorlog от MSSQL или msdblog.ldf? Первый 3 килобайта, второй около двух метров. За что отвечает база msdb и насколько опасно то, что она находится в состоянии suspect?
Модератор
11 — 08.05.07 — 20:32
А база как называется в MS-SQL?
12 — 08.05.07 — 23:17
Вообщем начитался я тут всякого:
http://www.klerk.ru/soft/1c/?15077 — тут рассказывается про восстановление пользовательских баз данных, мне не помогло конечно, ибо msdb системная, но зато узнал что такое sp_attach_db и sp_attach_single_file_db. Думал воспользоваться вторым (аттач одного mdf’f) для восстановления msdb, не тут то было. Потом стал читать:
http://support.microsoft.com/kb/224071/ru — Перемещение баз данных SQL Server в новое местоположение с помощью операций Detach и Attach. Как раз про перемещение системных баз данных. В моем случае можно было (в теории) сделать detach msdb, а потом attach_single_file_db, но почему-то, несмотря на прописанные ключи -c -m -T3608, он на любых операциях аттача / детача с системными таблицами говорил:
Server: Msg 7940, Level 16, State 1, Line 1
System databases master, model, msdb, and tempdb cannot be detached.
Хотя по идее должен был разрешить.
В итоге взял два файла из дистрибутива MSSQL — x86DATAmsdblog.ldf и x86DATAmsdbdata.mdf и подсунул их SQL Server’у.
Может кто-нибудь прокомментирует, почему он не давал сделать detach. Я грешу на то, что msdb находилась в suspect’е, но ведь он ясно сказал что именно системные таблицы не могут быть отключены, почему-то он ключи проигнорировал, интересно почему? Сейчас вроде бы все работает, но что-то меня беспокоит … не чревата ли такая подмена msdb?
Модератор
13 — 09.05.07 — 02:41
(12) Детач не дает сделать для системных таблиц.
Но можно остановить сервер и подсовывать таблицы.
По идее не чревата, только вот почему оно вот так все накернилось?
Может, заряженная частица пролетела, и все испортила? 
14 — 09.05.07 — 03:09
>>Вернул named pipes
Чего не айпи?
>>Стоит ли обновить SQL Server до SP3?
Можно и до 4-го
15 — 09.05.07 — 03:29
в мире мелкософта есть много чудес
вот одно из них:
однажды после переезда MSSQL с 1-процессорного сервера на на 2х процевый
с некоторых(!!!) машин невозможно было запустить 1С…
не буду описывать пляски с бубном… но все решилось установкой нового, на тот момент, MDAC на «проблемные» машины.
зы. естественно ОС и SQL на другом сервере ставились с того же самого дистрибутива, с какого ставилось и на первый.
16 — 10.05.07 — 12:55
(13) Как раз в статье http://support.microsoft.com/kb/224071/ru описан способ с помощью которого можно сделать detach для системных таблиц (статья по ссылке как раз о перемещении системных таблиц в другое месторасположение), только вот у меня этот способ почему-то не сработал.
Ну вообщем ладно, главное что все работает. Спасибо всем принимавшим участие в обсуждении.
Conditer
17 — 30.07.07 — 12:21
Такая же ошибка у меня начала неожиданно возникать на некоторых машинах при попытке вообще войти в 1С. Причем на одной через день ошибка перестала появлятся сама. А еще через 2 месяца вдруг другие 2 машины уперлись — и ни в какую к SQL серверу не подключались. Как тут посоветовали, поставил в конфигураторе вместо имени сервера IP-адрес — всё заработало. Чудеса…
| full_lamer |
Отправлено: 21.05.2004, 10:08 |
||
|
Машинист паровоза Группа: Участник
|
Доброго времени суток!
У меня произошла ошибка с MS SQL Server 2000:
И еще вопрос как написать процедуру для выгрузки дампа транзакций MS SQL Server 2000? Если можно приведите пример… Спасибо! |
||
 |
|||
| olegenty |
Отправлено: 21.05.2004, 13:50 |
||
|
Ветеран Группа: Модератор
|
ты, как обычно, вопрос задаёшь, предоставляя мало данных…
1. Ты какимим компонентами доступа пользуешься? |
||
|
|||
| olegenty |
Отправлено: 21.05.2004, 13:56 |
||
|
Ветеран Группа: Модератор
|
И нафига тебе дамп транзакций, что ты с ним делать будешь??? Есть там запросик, поищу щас… |
||
|
|||
| full_lamer |
Отправлено: 21.05.2004, 16:25 |
||
|
Машинист паровоза Группа: Участник
|
Это не есть мой прога, я еще не такой умный… Это 1С… так ругается, и для нее нужен выгруз дампа… А то каждый раз когда я меняю ее конфигурацию она мне говорит, что дамп транзакций мол нужно выгрузить… Поентому я не могу дать больше информации…. |
||
|
|||
| olegenty |
Отправлено: 22.05.2004, 08:46 |
||
|
Ветеран Группа: Модератор
|
Соответственно и смотри настройки 1С, кроме того, раз это говорит 1C, то и дамп, как я понимаю, выгружать надо средством 1С, специально для этого предназначенным. Потому что вряд ли 1С способна отследить твою выборку из лога транзакций. Ну, разве что посредством алертов, но это можно посмотреть у удостовериться, что оно не так. |
||
|
Добрый день. Ни с того, ни с сего стала выходить сегодня вот такая ошибка: «SQL State: HYT00 Native: 0 Message: [Microsoft][ODBC SQL Server Driver]Время ожидания истекло». Вчера её не было. На форумах нашёл много информации про данную ошибку, но случаи не подходят. Стоит windows server 2003, 1С 7.70.027, SQL 2000. Вот мои симптомы: Ошибка появляется только при проведении документа «Реализация товаров». Справочники записываются нормально, другие документы проводятся нормально. Даже проведенные документы «Реализация товаров» проводятся повторно нормально, а вот непроведённые провести не удаётся. Ошибке предшествует код «Операция.Записать;» Провожу документ из терминала, т.е. ошибка в сети исключена, как у многих с аналогичной ошибкой. Что это может быть?
запусти профайлер, и посмотри, что делает сервер…
а вообще, конец месяца, и т.е. пересчет итогов штатной хранимкой идет с начала месяца — тормоза нарастают.
+ Обмен не может пройти. Я уже просил всех перезайти в 1С. Ошибка осталась. К своему стыду не знаю, что это такое. Перепроводит документ за секунду, а проводит и 15 стандартных секунд не хватает?
при _пере_проведении сначала идет ClearRecalcDocAct, потом WriteDocAct, а пр ипроведении непроведенного — только WriteDocAct
Странно всё решилось. Хотел уже и службу SQL перезагрузить. В последний момент увеличил время ожидания и время захвата в 2 раза и документы стали проводится, причём первый раз долго, а потом стали быстро, как и должны. Вернул время назад — работает. Обмен прошёл. Сетевые пользователи тоже стали работать нормально. Что это было? О_О
вообщето SQL необходимо админить , регламентные задачи и все такое , как и скульную базу
забавный дятел по первой ссылке…
бывает ;)) главное обще понимание, что SQL это не тайота — сел и поехал (с) …
Смотри чего навоял, а скорей всего не навоял. Все дело в том, что при определенном объеме информации SQL БД начинает паршиво работать с запросами от самой 1С … Бывает прямые запросы спасут отца демократии
Это на время, пока число пользователей в БД не начнет опять повышаться. Или не начнут запускать какой либо МЕГО отчет на прямых запросах. Не забывай, что мего отчеты выполняются уже на самом SQL и тут ресурсов SQL 2000 физически может не хватить, если такой отчет начнут запускать 10 и более пользователей
смотря как писать… впрочем, сам вот кувыркаюсь — под конец месяца штатная запись/проведение документа начинает зверски тормозить…
у кого-то из пользователей слишком тормозной компьютер, вот он и блокирует при проведении таблицу. У нас так в свое время 5 лет назад было. В EA это хорошо было видно
может просто кто-то что-то большое и долгое проводил? типа восстановления ГП, ну или формирование книги покупок какое-нибудь.
формирование книги не блокирует журнал. а штатное восстановление ГП проводится в монопольном режиме.
уже сто раз повторялось , при массовом проведении документов растет лог и падает производительность (да и блокировки) , решается перевходом юзверя 1с (для SQL2000 это болезнь) многие в свое время откатывались на SQL 7.0
Так я на сервере, при отсутствии пользователей не мог провести документ, за секунду отрабатывал весь алгоритм проведения, а потом 15 секунд тупило над «Операция.Записать;», при чём другие документы проводились нормально. Поставил время ожидания 30 и документ провёлся за ~30 секунд, потом любой другой документ реализации стал проводится <секунды, как и должно быть.
лог ни причем. проблемы с темпбд. решение тоже очень давно известно (с 2004 года как минимум)
и лог и темп и много чего ;)) у софтпоинта гибкие блокировки но можно и самому написать ЗЫ прикрути 1с++ к проведению документа — будет работать в разы быстрее
Уже вернулось всё на круги своя.
лог к проблеме роста временных таблиц никаким боком не относится. Ошибка называется: Bug 472280: There is a decrease in performance when you frequently create and drop temporary tables in SQL Server 2000
считай остатки от обратного или от конца месяца или от TA т.е. если нужно остаток на начала текущего дня движений за сегодня день гораздо меньше чем движений с 01 по 26 число(а в будущих числах как правило никто не работает ) . Это справедливо для любой даты.
Тэги: 1С 7.7 и ранее
Комментарии доступны только авторизированным пользователям