Не выгружается в *.dt из SQL. 1с 8.2 #740123

ОЗУ сервера: 16Gb Место на диске: пердостаточно windows server 2008 R2 Enterprise х64 размер файлов базы : 3.5Gb mdf, 9.2 Gb - log (после деаттача - 1 Mb) ошибка: При выгрузке в *.dt пишет "Ошибка разделенного доступа к информационной базе" Что испробовано: - на этом же сервере другая база выгружается (без галочки блокировок регЗаданий, без выключения консоли) правда размер базы меньше. 1Gb mdf и 200 Mb log - Перезагрузка сервера - перезагрузка sqlserver и агент сервера 1с - развертка второй базы из бэкапа - очищение LOG.ldf - детач - аттач (чобы лог файл обнулился) - SELECT FROM dbo.Config WHERE DataSize > 125829120 в результате (пусто) - снятие с поддержки конфигурации - полное ТиИ, пересчет итогов Остановился на Технологическом Журнале. В логах ТЖ следующее: Descr='Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 10.0: Ошибка связи HRESULT=80004005 и ниже 27:52.5739-0,EXCP,3,process=rphost,p:processName=wano1,t:clientID=112,t:applicationName=Designer,t:computerName=DELEIL,t:connectID=55,SessionID=5,Usr=Администратор,Exception=dd149677-3d47-4e05-a55f-4e75b13a441f,Descr='SrcRemoteInterfaceImpl.cpp(1629): dd149677-3d47-4e05-a55f-4e75b13a441f: Сеанс работы завершен администратором. dc31263e-ecbf-41bd-9b3a-7b55897d5fd6: Соединение с сервером баз данных разорвано администратором Microsoft SQL Server Native Client 10.0: Поставщик общей памяти: С обоих концов канала отсутствуют процессы. Помогите с решением.

увеличьте размер пакета в настройках ms sql до 32000

GO EXEC sp_configure 'show advanced options', 1; GO GO EXEC sp_configure 'network packet size', 32000 ; GO RECONFIGURE; GO так? это значит выгнать всех надо с сервера?

нет размер пакета кратен килобайту 32000 я указал примерно. "это значит выгнать всех надо с сервера?" нет "Параметр вступает в силу немедленно, без перезапуска сервера."

В общем выполнил. на 30720. не помогло.

если надо, team viewer подключу. Заранее благодарен. просто сил уже нету.

>Ошибка разделенного доступа к информационной базе регламентные и фоновые останови

ну и не выгружай в dt скульную базу - это полностью бессмысленное действие

вырублено все. и в конфигураторе и в свойствах базы.

в другой город надо передать базу учредителям. для анализа.

передавай дамп скульный

не вариант. надо выгрузить в dt

Зависшие фоновые задания?

это как раз выгрузить в dt не вариант

отключите shared memory.

зачем? просто, чтобы поциент был чем-то занят и не жаловался?

как посмотреть зависшие фоновые? сервер перезагружался, службы тоже. Фоновые отключены в конфигураторе. где и как отключить shared memory?

:) только не деритесь пожалуйста.

А уверен, что размер какой-нибудь внутренней таблицы не больше 4Гб?

"Microsoft SQL Server Native Client 10.0: Поставщик общей памяти: С обоих концов канала отсутствуют процессы. " возможно проблема в протоколе.

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

"размер файлов базы : 3.5Gb mdf, 9.2 Gb - log (после деаттача - 1 Mb) - детач - аттач (чобы лог файл обнулился)" Вы так базу не убили часом? Или это новый способ обрезания лога транзакций?

вот тут какие-то сказки еще рассказывают, что снятие с поддержки помогает починить ситуацию, но я лично в это верю не больше, чем в shared memory

это рабочий способ шринкануть лог. Варварский, но рабочий. Базу так не потеряешь, если после детача ее руками не грохнуть шифтделитом.

скорее новый способ. Ну что вычитал, то вычитал. Я же не проверяю на других форумах Ваши рекомендации. Вот и пробовал что советовали. снятие с поддержки тоже пробовал. в описано.

рядом база на сервере. только размером поменьше. выгружается же. платформу 1С обновить или кого?

8.2.19.106 и 8.2.19.130 не велика разница. но если это так принципиально. то попробую.

я вообще про 8.3.5 думал, но можно и так

те сказки читал еще вчера ночью. и другие читал. не помогло как видите. аж до 8.3.5? хм. а она заведется в режиме обычного приложения? нам управляемый не нужен.

посмотрите с помощью ms sql profiler, последние действия 1с с mssql. Возможно это наведет на источник проблемы.

заведется

если сервер 1С 64Х и на сиквеле стоят SP, то путь один - выгрузить cf, поднять на любом другом не MS сиквеле базу, залить через выгрузкузагрузкавидентичную данные и из этой базы получить dt при этом можно попробовать и в файловый залить

для упп снятие с поддержки основной и рабочий вариант

то есть из x64 скуля в dt оно в принципе вообще не выгружается по техническим причинам непобедимого характера?

по uid ошибки "dd149677-3d47-4e05-a55f-4e75b13a441f" нашел

конфигурация: Бухгалтерия для Казахстана. (2,0,18,11) с небольшими дописками. просто документов Реализация и СФ мнооооого.

т.е. из 32Х может не выгружаться

взято на вооружение. и откуда Гилев все знает?

я не понял из обрывков ни уя, думаю, что автор - тоже. При каких условия "x64" и где выгружаться не будет?

это к сабжу не имеет отношения, т.к. там симптомы другие

обширная частная и Рарус практика

на сервере IPv6 отключено. Но в реестре не трогали. как описано в статье, надо IPv6 вырубать еще и в реестре. попробую ночью. когда можно будет серв перезагружать.

может тебя заняться чем-то полезным ?

shuhard, я не пойму, ты на куски развалишься, если сформулируешь свою мысль полностью от начала до конца в одно предложение?

сделал как описано. перезагружу сервер ночью.

сервер приложений у тебя x64 или x32?

у меня похожая аналитика была при отсутствии на MS 2008 сервиспака, правда не при выгрузке dt, а при обновлении конфы итого - SP стоит ?

1) сервер 1с и СКЛ на одной машине? 2) делаете по сети или прямо на серваке? 3) фаерволы выключены?

простите? сама сервак? или что то другое? винда 64 бита. sql фиг иво. как посмотреть то? можно пару слов хотя бы, как профайлером смотреть?

на одной машине. подключаюсь удаленно RMS-ом, под администратором. да и другими вариантами пробовал. фаерволы не смотрел. но другая база же выгружается. всего на сервере 3 базы.

агент 1С , он же rphost сколько разрядный ?

сервер приложений 1С. Который "Агент сервера и блаблабла", который  rphost'ы запускает. Вот он - -какой?

и подключены они под одним и тем же юзером?

брандмауер выключен. C:Program Files (x86)1cv828.2.19.106in agent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:Program Files (x86)1cv82srvinfo" означает ли это что он 64?

[на одной машине]+[ОЗУ сервера: 16Gb] тогда диагноз прост, 90% памяти отдано сиквелу, rhost либо 32Х, либо 64Х и памяти у него меньше 8Гбайт ошибка, как ни странно - мало памяти лечить - переходом на 64Х + выделением ему достаточной памяти + крайний SP на сиквел

он 32Х

вот, все сказал вроде

рпхост и рагент *32 грузятся. наверно всет таки 32

может еще квоты на диски выделены

Ограничь на время выгрузки скулю место в памяти на гигов 6-7

кого перевести на 64? агента сервера 1С?

как посмотреть? как ограничить?

если у тебя денег только на жигули, а тебе предлагают мерс, тогда никак ) в яндекс

угу нужен ключ на 64Х и отобрать побольше памяти у сиквела или разнести сервер 1С и сиквел строка запуска выглядит так C:Program Files1cv828.2.19.90in agent.exe" -srvc -agent -debug -regport 2541 -port 2540 -range 2560:2591 -d "C:Program Files1cv82srvinfo" имя службы 1C:Enterprise 8.2 Server Agent (x86-64)

не понял обоснования. ладно спасибо. буду гуглить.

ПКМ в Менеджмент студии по корню - свойства - память но ограничение памяти сиквела обоюдоострый вариант, начнет расти темп и могут отвалиться часть отчетов

ему ж временно надо, судя по тому как он там все ребутает, вообще не критично имхо :)

отдай людям sql-дамп. Даже, если ты выжмешь каким-то образом dt, они с другой стороны столкнутся с такими же проблемами при загрузке. Сэкономь свое и чужое время

ну да.

на горячку можно менять параметр? когда в других базах люди? там стоит сейчас 2147483647 причем в Mb написано хочу поставить 6144 (Mb) сойдет?

у тебя проблема с сервером 1С, ему памяти мало и поскольку он 32Х , то помочь ему нельзя

можно

кстати ты дисковые квоты так и не посмотрел

не могу найти как посмотреть...

пкм по диску - свойства -квота

отключены

ниче не понял, что мне там профайлер написал...

ты думаешь, у каждого учредителя скуль Enterprise установлен?

еще и на ноуте. а еще он как админ, знает как все развернуть обратно.

память поставил 6 Гб сделал как в статье. перезагрузил сервак. результата нету. остался этот вариант. не знаю реализуем ли он. Можно ли на серв доставить 64х чтобы не навредить 32х. и потом на него базы перевести (хотя бы ту, из которой надо выгрузку сделать)?

[не знаю реализуем ли он] легко ставишь на 25-ие порты 8.3.ХХ.ХХ 64 к нему эмуль и в параллель живут 8.2 32 и 8.3 64 но есть же лобовое решение: - выгрузить cf - выгрузитьзагрузитьчерезXML если файловая рабочая. то не придётся париться

я тут наковырял в ТЖ еще ошибку на файл SELECT TOP 8 [FileName]       ,[Creation]       ,[Modified]   FROM [wano1].[dbo].[Files] работает , а вот если добавить столбец  binarydata то на 7 строках пашет а если на 8 строках то ошибка Поставщик общей памяти, error: 0 - С обоих концов канала отсутствуют процессы.) SELECT TOP 8 [FileName]       ,[Creation]       ,[Modified]       ,[Attributes]

а в ТЖ было 52:45.2574-0,EXCP,1,process=1cv8,Usr=Администратор,Exception=9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3,Descr="srcInfoBaseImpl.cpp(9749): 9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3: Неправильный путь к файлу 'c01b78f6-1525-41b1-9cc1-69e3da58d2ac.pfl'"

Можно ли удалить 8 строку в таблице Files. ?

Кстати, в 9 строке в столбце FileName и есть c01b78f6-1525-41b1-9cc1-69e3da58d2ac.pfl то что он не может найти. значит мне надо удалить 9 строку.

на копии точно можно =)

ну в общем удалил ее. не помогло. сейчас ищу ошибку следующую в ТЖ

ошибка та же. на c01b78f6-1525-41b1-9cc1-69e3da58d2ac.pfl НО. в таблице FILES данной строки уже нет. и где ее искать теперь? как по sql базе можно найти ссылку?

выгрузилась. и почему то выгрузка весит 120 Мб. ща попробую развернуть в файле и сравнить данные

выгрузилась после удаления 2 строк в таблице Files. Строки удалял те, которые не выводились запросом в со столбцом BinaryData. после чего сделал DBCC  CHECKTABLE('wano1.dbo.Files', repair_allow_data_loss), он там чего то восстановил... о результате сообщу.

Есть инструкция как воспользоваться этим дампом? Мне иногда надо потренироваться на другом сервере с базой клиента.

В общем развернулась база. все нормально. весит чуть меньше sql. данные в порядке. кратко о решении: в получается что не в сервере и не в ПО дело. хотя все вышеописанные рекомендации тоже делал... спасибо за помощь.

молодца можешь отписать рецепт Гилеву

ок. спасибо.

в итоге на БОЕВОЙ базе было сделано сразу DBCC  CHECKTABLE('BaseName.dbo.Files', repair_allow_data_loss) без удаления 8 и 9 строк таблицы Files. Результаты DBCC для "Files". Исправление: индекс Clustered успешно перестроен для объекта "dbo.Files" в базе данных "BaseName". Исправление: удален выходящий за границу строки столбец с идентификатором 63773278208, для объекта с идентификатором 660301512, идентификатор индекса 1, идентификатор секции 72057595708112896, идентификатор единицы размещения 72057594642300928 (тип LOB data) на странице (1:179420), область памяти 3. Исправление: удален выходящий за границу строки столбец с идентификатором 64356745216, для объекта с идентификатором 660301512, идентификатор индекса 1, идентификатор секции 72057595708112896, идентификатор единицы размещения 72057594642300928 (тип LOB data) на странице (1:270082), область памяти 0. Исправление: удалена запись для объекта с идентификатором 660301512, идентификатор индекса 1, идентификатор секции 72057595708112896, идентификатор единицы размещения 72057595684716544 (тип In-row data), на странице (1:118), область памяти 7. Индексы будут перестроены. Исправление: удален выходящий за границу строки столбец с идентификатором 64356745216, для объекта с идентификатором 660301512, идентификатор индекса 1, идентификатор секции 72057595708112896, идентификатор единицы размещения 72057595684716544 (тип In-row data) на странице (1:118), область памяти 7. Сообщение 8945, уровень 16, состояние 1, строка 2 Ошибка таблицы: идентификатор объекта 1, идентификатор индекса 660301512: индекс будет перестроен.         Данная ошибка была исправлена. Сообщение 8965, уровень 16, состояние 1, строка 2 Ошибка таблицы: идентификатор объекта 660301512, идентификатор индекса 1, идентификатор секции 72057595708112896, идентификатор единицы размещения 72057594642300928 (тип LOB data). На данный узел внестрочных данных на странице (1:179420) (область памяти 1, идентификатор текста 64356745216) ссылается страница (1:270082) (область памяти 0), однако при просмотре данный узел не обнаружен.         Данная ошибка была исправлена. Сообщение 8964, уровень 16, состояние 1, строка 2 Ошибка таблицы: идентификатор объекта 660301512, идентификатор индекса 1, идентификатор секции 72057595708112896, идентификатор единицы размещения 72057594642300928 (тип LOB data). У внестрочного узла данных на странице (1:179420), область памяти 3, идентификатор текста 63773278208, отсутствует ссылка.         Данная ошибка была исправлена. Сообщение 8965, уровень 16, состояние 1, строка 2 Ошибка таблицы: идентификатор объекта 660301512, идентификатор индекса 1, идентификатор секции 72057595708112896, идентификатор единицы размещения 72057594642300928 (тип LOB data). На данный узел внестрочных данных на странице (1:270140) (область памяти 0, идентификатор текста 63773278208) ссылается страница (1:179420) (область памяти 3), однако при просмотре данный узел не обнаружен.         Не удалось исправить эту ошибку. Сообщение 8929, уровень 16, состояние 1, строка 2 Идентификатор объекта 660301512, идентификатор индекса 1, идентификатор секции 72057595708112896, идентификатор единицы размещения 72057595684716544 (тип In-row data): ошибки, найденные во внестрочных данных с идентификатором 64356745216, принадлежащих записи data, обнаружены RID = (1:118:7)         Данная ошибка была исправлена. Имеется 19 строк на 1 страницах для объекта "Files". CHECKTABLE обнаружил 0 ошибок размещения и 4 ошибок согласованности в таблице "Files" (идентификатор объекта 660301512). CHECKTABLE исправил 0 ошибок размещения и 3 ошибок согласованности в таблице "Files" (object идентификатор 660301512). repair_allow_data_loss - это минимальный уровень исправления для ошибок, найденных DBCC CHECKTABLE (BaseName.dbo.Files, repair_allow_data_loss). Выполнение DBCC завершено. Если DBCC выдает сообщения об ошибках, обратитесь к системному администратору. после чего выгрузка прошла успешно.