Скульная база 1с что это
До этого было тоже самое с общим модулем: изменения были только по нему, после сравнения/объединения показывает, что конфигурация изменена, принимаем изменения, открываем модуль, а там нет изменений.
"Как-то при соединении обратно к хранилищу была сделана полная замена из .cf через сравнением/объединение, все галки проставлены, четко анализировалось всё." А в хранилище старая конфигурация была? Или в хранилище заменили конфигурацию? Сравнивали как? Подробнее можно?
Но даже вчерашнее изменение меня в тупик ставит: как можно перенести реквизиты и элементы формы, а обработчики событий этих элементов нет. Выполнялось не динамически.
обновить платформу религия не позволяет? В релизе 8.3.7.1917 пофиксили проблемы с хранилищем и динамическим обновлением.
До этого база сидела год на версии, которую 1с отозвала - жрала оперативку. Так с боем обновили. Вернее обновили, свои проблемы решили, а потом отхватывали.
может изменения перенеслись, а на экране не видны, как это было у меня. Почисти кэш на клиенте и открой конфигурацию заново.
Очищаю кэш, делаю выгрузку в cf из архива, где были мои изменения, делаю сравнение/объединение в живой базе - после анализа конфигуратор не видит различий, хотя они есть. Значит с захватом в хранилище всё было нормально, да и у меня сомнений в этом не было, т.к. всё контролировалось. Что тогда может быть? Может я чего-то и не знаю - подскажите, пожалуйста!
за последнее время сравнение/объединение изменилось. почитай, может ты делаешь по-старинке, а оно, Михалыч, уже не так работает)
К примеру, в конфигурации был макет регистра, он был скопирован, чтобы сохранить первоисточник, а в оригинале внесены изменения. При сравнении/объединении было показано, что внесены изменения в первоисточник и создан новый. Это я на все 100% контролировала, т.к. было очень важно. По факту: копия действительно есть, а в первоисточнике изменений нет. И повторное сравнение не показывает различий. Причем такие изменения были в двух регистрах: в одном всё нормально, а в другом нет.
1С сервер сдох сразу при добавлении в список ИБ такого количества баз,
наплодил более 1000 рабочих процессов и как следствие "сдох" сервер, те ОС Win 2008R2 c 32 гигами памяти.
Настройки стояли по умолчанию - 8 ИБ на процесс, 128 подкл. по процесс
Дальнейшее кручение 1С сервера не помогло.
Решил разнести сотню на 3 сервака, по 30+ баз, результат тот же, только процессов стало по 30-40 шт, но лучше от этого не стало - теперь 3 сервака загружены под 100% проца и памяти.
Вопрос - чего делать-то?
или на такое кол-во 1С сервер не способен и забыть про эту платформу
%(
Пилить кластер из 1с серверов?
Попробовал - те же . тк баз опубликованных на нем остается столько же, итог опять же - куча рабочих процессов.
значит то, что куча рабочих процессов сжирает все процы и память
соотв. сервак перестает реагировать на всякие внешние раздражители в виде клавы и мыши
и как следствие - раз в 60-90 сек отваливаются 1С с ошибкой
(0) Поставить одну базу, но пользователям написать База1, База2. База100, которая ссылается на одну базу.
Разрулить всех правами.
не выйдет - тк это бух аутсорс - и когда клиент уходит - то база передается клиенту
или когда приходит клиент, приносит свою базу
и тд, сценариев очень много
Базы разворачивались из архивов? Может какие то фоновые задания типа полнотектовых поисков плодят процессы и убивают диск ?
(17) Ну и что, выгружаешь нужные данные в др. базу и отдаешь клиенту.
Когда приносит то загружаешь из его.
(26) вот кстати вариант. одновременно со всеми базами не работают.
ещё вариант - несколько серверов, запускать при необходимости, давить неиспользуемые
Не верю, что сервер 1С не потянет 100 баз.
Если плодятся процессы, то стоит заглянуть сюда:
v8: Подскажите с чего вдруг сервер 1С 8.3 запускает при запуске 44 тыс. процессов
И неплохо всё-таки огласить параметры сервера: сколько процов и ядер, что еще крутится на этих 32 гб кроме сервиса "сервера 1С"?
(35) Платформа Supermicro, 2хE5-2620v2, 64Gb, 4x SSD intel 350 серии
стоит Hyper V 2012R2 на нем 3 виртуалки, одна из них была отдана на 1С сервер
при добавлении баз за 5 десяток - "оторвало крышу" рабочим процессам - начали активно размножаться, решили добавить памяти до 32 гигов - не помогло. Снесли.
Разделили на 3 виртуалки (Win2008r2) в каждой только роль 1С_сервер и список ИБ на каждом чуть более 30.
Через час у всех трех наблюдали кучу рабоч.процессов и загрузку всего и вся под 100%.
Досталось и вирт.хосту - выросла очередь на диске, где лежат виртуалки.
Все прибили.
Живем пока на файловом варианте.
Недавно обнаружил, что если парва на папку с сервером 1с "неверно упорядочены" то идет разрастание процессов
(43) а, нет тут все в порядке
проверял на нескольких пустых\голых\только что установленных Win 2008 r2 как рус так и англ дистрибутивах
- результат один
мысли пока - что косячит HyperV
ну например вот бухгалтер ведет 5 фирм, но разделитель я могу поставить только один. И какой выход? Заводить 5 пользователей?
Т.е. в случае автора я завожу 1000 фирм * 50 бухов = 50 000 пользователей?
далее, что делать со справочниками? они будут общие или как?
Далее что делать когда нужно отдать базу клиенту? Отдавать базу со всеми 1000 фирмами??
Так что именно ты хотел сказать фразой "Для таких сценариев и придуманы разделители данных"?
(46) отлично, проконсультируйте, пож. как быть в таких сценариях:
- ООО, ИП стало 200-300 активных\рабочих
за год (например) прошло более 400, те около 100-200 надо свернуть в архив и сложит на полку.
как быть в таком случае?
Смысл разделителя в том что разделитель делит одну базу на несколько "независимых". По большому счету эта вещь предназначена для облачных решений, что бы не обновлять конфигурацию каждой базы.
Т.е. разделитель НЕ ПОДХОДИТ к раздельному учёту
(0)Я так понял услуги по ведению бухгалтерии оказываете?
Используйте файловые базы.
Нафиг там клиент серверная архитектура непонятно.
200баз прекрасно чувствуют себя на серваке красная цена которому 50тыс рублей.
(57)Какие именно удобства управления в данном режиме использования?
Все прекрасно управляется и бэкапиться.
Сервак i5, 32ram, зеркало из ssd на котором система и базы, и зеркало из двух hdd, на котором все остальное.
Бэкап делается встроенными в винду средствами (теневое копирование) каждый час. Этого достаточно.
Хотя при желании можно делать каждые пять минут.
Я не вижу проблем чтобы сделать двести скульных баз на одном сервере, даже маломощном.
Просто не вижу смысла.
Если много пользователей на базу - скуль без вариантов.
Если с базой работать будут 1-2 пользователя - однозначно файловый вариант.
А если загружать базу в скуль только на момент работы с ней - не уверен, что будут работать со всеми 100 базами одновременно.
Конечно, если давать пользователям удалённый доступ к "своей" базе, то нужно пытаться найти другие пути.
(62)Ну трудно представить ситуацию чтобы потребовалось одновременно запустить такое количество баз.
С ними же должен кто-то работать.
Обычно количество открытых баз = количество пользователей.
И кстати в чем трудность предоставления удаленного доступа к "своей" базе? Зачем искать другие пути.
(64) Ну, к своей базе можно через Web-публикацию работать, и там придётся для каждого свой Web-сервер поднимать - думаю, что это будет тоже ещё та задача.
Хотя, можно сделать один общий сервер, где переход в базу идёт после дополнительной авторизации на основной странице входа - тогда можно всех "зверей" в одной системе пасти.
(66)+1
Если это последние версии типовых, то там нафиг ненужные задания типа "Обновление агрегатов", "Установка периода рассчитанных итогов" запускается каждые 10 сек по умолчанию!
(67) во-во. При условии что в типовой они не используют агрегаты, нафига это делать - непонятно. Хотя бы авто использование включили бы
кстати
---------------------
ервер уровня КОРП "1С:Предприятие 8.3" предназначен для корпоративных клиентов. Он приобретается вместе с определенным количеством клиентских лицензий уровня КОРП, рассчитанным, исходя из числа автоматизированных рабочих мест.
Данный продукт обладает расширенным функционалом по сравнению со стандартным 64-разрядным сервером:
Для пользования перечисленными функциональными возможностями необходимо заключение договора ИТС ПРОФ.
(0) похоже, завелась зараженная база.
Которая при запуске порождает 100500 процессов, сливает все данные других баз в интернет и затирает данные)
(69) вот мне и интересно на самом деле app 1C_сервер версии корп отлич. от версии Проф
тк вроде платформа то одна - 8.3
(70) а зараженных баз не может быть - тк в скуле создал пустышки (скриптом) и в 1С_сервере - тоже пустышки создавал через пакетный режим
Предыдущую тему "Атака через уязвимость smb" отправили в спам, миа кульпа, но не было времени растекаться мыслью по клавиатуре,т.к спешно проверял репорты WSUS. Недавно был такой рансом "спора",так вот он успешно кушал файловые базы 1с. У меня , еще тогда мысль возникла - "Все в сад!", то есть в скуль, ведь там файлы заняты службой субд, а завладеть ими можно только после остановки службы. Хотя сейчас читаю что разновидность сегодняшнего wcry шифрует и скульные базы, только пока не понял как, или стопит сервис, или получает права админа субд. Есть на чем подумать.
Всем срочно ставить обновления винды!
А так же проверить бэкапы )
Куча зараженных машин по всему миру. В России много зараженных машин в ведомствах и крупных корпорациях
ПС: Был проведен эксперимент. Свежеустановленная винда смотрит в интернет. Через 15 минут попал вирус .
массовая проблема @WanaDecryptor@.exe зашифрованы файлы, расширение WNCRY
ПС: Кстати использует дыру винды, кот. использовали АНБ и была вскрыта в марте сего года.
Хороший повод напомнить руководству про "бэкапы- наше все" и выпросить второй nas )) или даже об "облаках" задуматься.
(1)Как временный вариант можно закрыть на шарах 445 порт, все диски к терминальному серваку и пусть ходют туды за общими файлами, пока все не проапдейтите.
(5) Собственно криптор не может зашифровать скульную базу, пока работает сам скуль, также как не может зашифровать файловую 1с, если она открыта хоть где-то
угу, понятно. давненько уже такого не было, чтобы вирь эксплуатировал уязвимость в серверных службах. Последний из массовых, кажется, kido был. А вот к 2003 и ХP заплатку не выложили :(
Понятно, игрушки АНБ вылезли наружу и попали в добрые руки бизнесменов. Винда опять показала себя как решето.
кто-нибудь в курсе, более ранние системы чем Vista могут быть атакованы? В бюллетене про них нет данных, понимать как то что они не подвержены атаке или как то что MS не будет для них ничего делать?
крипторы - это неприятно, но не смертельно. А вот уязвимость на порту и наличие программ которые ее эксплуатируют - это уже серьезно. Подобных эпидемий с сетевыми червями в истории Windows было с начала нулевых не так уж и много. Похоже, это еще одна.
(10) при наличии прав или использовании "уязвимостей АНБ" это понятно, но из практики у меня пока не было случаев, когда шифровались открытые базы.
В свете случившегося меня в особенности беспокоят XP и 2003. Их все ещё очень много, особенно с учётом того что с деньгами у многих контор сейчас туго и многие выжимают последнее из инфраструктуры середины нулевых, когда бабки были. Патчей нет. Вот где реальная задница. (
(23) Да никакой задницы. Все работает.
В плане безопасности на XP все настраивается отлично.
Есть теневое копирование, есть настройка прав доступа, что еще надо?
(22) здесь проблема в том, что при эксплуатации уязвимости код, скорее всего, запускается с полными правами. В отличие от обычных шифровальщиков, которые запускаются из-под того юзера, который неудачно открыл вложение.
Единственная проблема со старыми системами - не поддерживают современное железо и софт.
Если с этим проблем нет - можно спокойно работать.
(25) см. (26). Права тут не помогут. Код, который срывает стек в сетевой службе, простартует с правами службы. Т.е. с полными.
Полную гарантию может дать только заплата, которая закроет дыру. Ну или антивирус. Надеюсь, в свежих базах уже есть опознание этой дряни.
(25) ну если освоить всего Русиновича, то можно и заплатки самому ваять и жить да жить. пока нтфс нё заменят
В том-то и беда, что запустившая вложение курица вполне может работать под ограниченной записью - нет ничего криминального в опросе сети и коннектам на 445 порт. А на атакованных с Ее машины компах код уже запустится под системной учётной записью с полными правами. Хошь процессы прибивай, хошь SQL останавливай.
(28) Именно права тут и помогут.
Основная проблема шифровальщиков заключается в том что они не являются вирусами, и как следствие антивирус против них абсолютно бесполезен.
А в большинстве случаев вся защита строится на использовании антивируса.
Тут нужна комплексная защита, и это в первую очередь права.
(26)Насчет куриц - какого хрена у курицы есть право запускать левые файлы?
Настраивается это очень легко - не быстро конечно, повозиться придется, но сложного ничего нет.
И пользователь банально не сможет запустить вредоносный код.
В итоге - порт наружу не смотрит, уязвимость бесполезна.
Через письма и прочую социальную инженерию протащить тоже не получиться, ибо банально нет прав на запуск.
Вот и все.
(31) так на скульном ей делать нечего , ее 1с общается с рагентом, а он уже со скулем . В файловом то да шара на севаке для нее открыта
Логика простая - у пользователя на рабочем комьпютере не должно быть помойки.
Никакого левого софта.
Весь софт с которым пользователь будет работать ставит админ в папку ProgramFiles.
В итоге у пользователя есть права на запуск из системных директорий, куда он не может ничего записать.
Но нет прав на запуск софта из всех других директорий, куда он может писать, например с рабочего стола, или с папки APPDATA.
(33) Ну на скульном сервере SMB запущена чаще всего, а этого достаточно похоже.
Наличие расшаренных папок вроде не обязательно.
(34) ну стоит у нее прога которой нужен джаваскрипт , доклайнер какой нибудь и все, запускает она файли док а дальше.
локальному компу 6 лет, без переустановки винды, стоит nod32
в карантине только 3 файла из инетовских темпов. что я не так делаю и почему за 6 лет меня не зашифровали?
В прошлый раз мы рассказали, как изменялись наша инфраструктура и принципы работы с базами 1С, коих у нас бесчисленное множество уже полтысячи, и про то, как мы автоматизируем работу с таким количеством данных. Однако, трудности и костыли всё ещё есть, и с ростом числа клиентов Кнопки нам приходится придумывать новые и улучшать старые способы оптимизации. Одна из основных проблем при работе с большим количеством баз 1С — накатывание обновлений. Сегодня мы расскажем о технологии разделения данных, которая позволяет уменьшить количество баз и упростить их обслуживание.
Найти документацию по механизму разделения баз достаточно трудно: есть небольшая статья на основополагающем сайте, но нам она принесла мало пользы. Есть старый добрый Гугл, но чтобы разобраться в тонкостях, придётся долгими часами бороздить выдачу в поисках нужного куска информации. У нас другого выбора не было, а у вас теперь есть эта статья. Надеемся, она пригодится.
Хватит это терпеть!
При работе с 1С, обновлять приходится многое: конфигурацию, КЛАДР, списки банков (лишают их лицензий, знаете ли), курсы валют (ох уж эти экономически нестабильные евро и доллары), списки пользователей, обработки, версию платформы. На хорошем железе обновление КЛАДРа со всеми регионами для одной базы занимает около получаса. Обновление конфигурации занимает от 10 минут до нескольких часов (при накатывании пачкой).
Не стоит забывать и о том, что в каждой отдельной базе живёт её величество Конфигурация, которая не отличается от базы к базе ни на байт. Живёт и ест место, при том, что в конфигурацию так же нужно загружать изменения, вставлять обработки и расширять стандартную функциональность.
Итак, если у вас есть несколько ничем (кроме организаций) не отличающихся баз, с одинаковой конфигурацией, механизм разделения может существенно облегчить жизнь (не без дёгтя, но об этом позже). Иначе очень скоро придётся нанимать армию админов:)
Базовая сегрегация
Для начала, нужно определить признак, по которому вы будете разделять базу. Разделитель может иметь любой тип данных, мы используем строку длинной 10 символов: ИНН организации. Главное — название разделителя (общего реквизита) не должно совпадать с уже существующими объектами конфигурации, то есть его нельзя назвать, например, «Организации», так как уже есть такой справочник. Мы назвали разделитель «Группа компаний».
После этого берём вашу типовую конфигурацию с пустой базой, заходим в конфигуратор и открываем раздел «Общие реквизиты». Добавляем общий реквизит и меняем значение «Разделение данных» на «Разделять»:
Конфигуратор предложит создать параметры сеанса — безмолвно соглашаемся и идём дальше. После создания «Общего реквизита» с включённым свойством разделения, база данных становится похожа на многоэтажный дом. В доме есть элементы доступные всем и с каждого этажа: лифт, лестничный пролёт, коммуникации, а есть уникальное, доступное только в пределах этажа: квартиры, коридор, окна. Метафора простая, и, надеюсь, понятная:)
Для входа в определённую организацию (или область базы) необходимо сообщить разделитель в строке подключения к базе или указать его в v8i файле (о которых мы рассказывали в прошлый раз).
После /Z указываем общие реквизиты по порядку. Так как в нашей типовой бухгалтерии уже есть два общих системных реквизита, указываем для них значение -0 чтобы они не использовались, а в качестве третьего (который мы создали) передаём ИНН.
1000 и 1 чекбокс
Теперь нужно определить, какая часть данных будет являться общей для всех областей. Всё это настраивается через конфигуратор. В свойствах общего реквизита, который мы только что создали, есть пункт «Состав» открывающий небольшой список из 800 параметров:
Подбор параметров оставляем на ваше благоразумие, усмотрение и окружение. Вот наш вариант (аккуратнее, там 20 000 пикселей).
Разделитель также даёт возможность настроить отдельный список пользователей для каждой базы — это может пригодиться, если у вас сотни пользователей — при входе в определённую базу не придётся проматывать этот список до кровавых мозолей. Мы это не используем, потому что настроили прозрачную авторизацию.
Выгружаем данные из текущих баз
Для выгрузки данных из текущих баз, мы используем универсальный . Нельзя просто так взять и выгрузить базу, нужно настроить правила обмена, иначе при загрузке могут (и обязательно возникнут) ошибки и конфликты, а вторая база просто не пролезет. Напомним, что мы делим области базы для каждой организации и в нашем случае работают такие правила обмена. Если вам вздумается использовать другой разделитель, придётся пораскинуть мозгами и чекбоксами. Главное — не использовать типовую выгрузку — это приведёт к дублированию всех предопределённых записей.
Хозяйке на заметку: справочники и документы лучше выгружать отдельно — так можно избежать лишних ошибок в момент загрузки.
Загружаем данные в разделённую базу
Запускаем 1С с параметром /Z «-0,-0,+%ваш разделитель%», указывая разделитель той организации, данные которой собираемся загрузить. Запускаем универсальный обмен и скармливаем ему полученные при выгрузке файлы: сперва справочники, потом документы. Повторяем эту операцию для каждой .
Чтобы упростить задачу, мы осуществляем выгрузки массово, предварительно запуская чуть исправленную стандартную обработку через командную строку (/Execute c:\выгрузка.epf). Затем вручную загружаем полученные файлы в разделённую базу.
Как потратить больше времени, чтобы потратить меньше времени
Процесс разделения — штука не быстрая. Напомним, что у нас сейчас больше 500 организаций, но за пару недель мы успели разделить только 70. Однако, мы точно знаем, что уже через полгода поблагодарим прошлых себя за проделанную работу и кучу сэкономленных времени и сил.
Бухгалтеры Кнопки не замечают перехода организаций из обычной базы в разделённую, для них процесс проходит безболезненно. Попа горит только у админов:)
Побочные эффекты: экономия места 1 к 20, косвенное увеличение скорости работы — неоценимо. В абсолютных цифрах: 50 организаций занимают 2 Гб пространства в SQL, тогда как одна отдельная база занимает от 800 Мб.
Кнопка — не самая обычная бухгалтерская компания, но бухгалтерию мы ведём в 1С, как и большинство отечественных коллег. На текущий момент у нас на сервере проживают сотни баз, поэтому нам пришлось научиться быстро и качественно всё это богатство администрировать. Если вы — бухгалтерская компания, хостер с сервисом 1С, или у вас просто взялась куча 1Сок, вы знаете, как это трудно. Мы любим приносить пользу, поэтому поделимся опытом, практическими советами и инсайтами, которые успели нас посетить за бессчётное количество ночей, праздничных и выходных дней, проведенных за обновлением и актуализацией всего нашего хозяйства.
Мы не продаём 1С, а потому рассказ будет без купюр, цензуры, а главное — без маркетингового булшита. Бонустреком, по ходу поста можно найти несколько полезных скриптов и советов для тех у кого действительно много баз 1С.
Итак, почему у нас вообще так много баз? В действительности, прямо сейчас мы исследуем технологию разделения данных, но использовать её ещё не начали, поэтому для каждого бизнеса, который мы обслуживаем, вынуждены создавать отдельную базу (и часто не одну).
Невероятный путь от облачной 1С до собственного кластера серверов
В начале нашего пути мы пользовались облачным : этот сервис в меру удобен, насколько может быть удобно использовать настольное приложение через браузер. Однако, довольно быстро мы накопили полсотни баз и администрировать их через веб стало невыносимо — начал тормозить, плюс появилась необходимость программно интегрировать 1С с нашими внутренними инструментами, чего Фреш категорически не умеет. Пришлось мигрировать, выгружая все данные из облака. Благо сделать это было нетрудно («Выгрузить данные в локальную версию» → «Загрузить данные из сервиса»).
Вторым важным этапом эволюции стало использование , и нас, опять же, всё устраивало, пока баз не стало больше сотни. Обновления конфигураций, как и публикация с добавлением пользователей, происходили через письмо в техподдержку. В принципе, всё оперативно, но не интерактивно.
Особые неудобства доставляла невозможность запуска. без предварительного согласования (добавления в разрешающие политики домена), а нам, напомню, была необходима интеграция. Также были проблемы с тем, что, по непонятным причинам, СХД провайдера неправильно синхронизировало ноды на блочном уровне. Так мы потеряли несколько важных баз, которые пришлось долго и мучительно восстанавливать. С системами хранения часто всё непросто и нечестно.
Хозяйке на заметку: тестируйте хранилище. Если вы хостер, то уделите этому больше внимания. Если вы пользуетесь сторонним хостингом — обязательно проверяйте хранилище и диски. Это детские грабли, наступать на которые ещё больнее, чем на взрослые :)
После всех приключений мы решили мигрировать на свой VPS. Мощности современных виртуальных серверов позволяют спокойно содержать пару сотен , без труда допуская к ним пару десятков бухгалтеров. Провайдеры VPS, зачастую, не отвечают за лицензирование программных продуктов, которые вы запускаете внутри, поэтому нужно озаботиться приобретением лицензии на пользователей и покупкой конфигурации.
Хозяйке на заметку: при лицензировании большого количества баз вас могут ждать сюрпризы — активация каждой базы для каждого пользователя через программный ключ может стать вашей основной работой на ближайшие недели. Этого недостатка лишёнкрякаппаратный ключ, но его нельзя просто так взять и начать использовать в VPS.
Не будем забывать, что даже самый лучший VPS (выбранный с использованием вот этого клёвого сервиса) не сравнится с тёплым и ламповым собственным сервером. Мы решили мигрировать в третий раз.
Однажды вечером наш VPS не запустился. Был самый пик отчётности — последние её часы, и сервер находился в дауне неоправданно долго. При этом через панель управления мы сделать ничего не могли — сервер находился в стадии запуска, а техподдержка просто разводила руками. Как оказалось, на хосте с нашей виртуалкой закончилась оперативная память, и на запуск её просто не хватало.
Итого
Сейчас, имея сотни баз пройдя путь от , через боль, миграции, неконсистентность баз, некомпетентность техподдержки, проблемы с синхронизацией нод у хостера, публикацию через веб, экспорты, импорты, резервные копии и массу восстановлений, мы пришли к своему кластеру серверов.
- думайте о лицензиях;
- если вам нужна интеграция — используйте выделенный сервер или VPS;
- позаботьтесь о хранилище или тщательно тестируйте его у вашего провайдера;
- резервные копии — это правда важно;
- сразу откажитесь от , если нагрузка будет серьёзной и важна стабильность.
Как упростить жизнь, если вы вынуждены работать с кучей баз
Создание базы со ссылкой на неё в профиле текущего пользователя
Мы разворачиваем все наши базы из заранее подготовленного шаблона (с загруженными обработками, справочниками, настроенной подпиской ИТС и резервным копированием).
Для файлового варианта:
Для SQL варианта:
Как создать или удалить пользователя сразу в сотне баз?
Как подключить пользователю сразу сотню баз?
Для добавления сразу всех нужных баз в список пользователя мы используем v8i общих баз, размещённые на файловой шаре. Ссылки на эти файлы добавляются в профиле пользователя (например, через GPO или в профиль ) в файл %AppData%\1C\1CEStart\1CEStart.cfg:
Либо из самой 1С (уже под пользователем) добавляем список общих информационных баз:
Внутри файлы v8i выглядят так:
Создать их можно прямо из окна выбора базы («Сохранить ссылку в файл») или же взять в профиле базы — %AppData%\\1CEStart\ibases.v8i. Ссылка может быть на базу работающую в любом режиме (файловый, серверный, веб). Рекомендуем хранить в одном файле не более ста баз, иначе файл может попросту загрузиться не до конца :)
Как обновить сразу сотню баз?
Обновление баз лучше производить на отдельном сервере (а еще лучше сразу на двух :) — это и быстрее, да и управлять процессом проще. Мы используем типовые конфигурации (без снятия с поддержки), обновляемые через ИТС. В первом квартале этого года для «Бухгалтерии 3.0» вышло более 10 обновлений, накатить их даже на десяток баз вручную — та ещё веселуха. Потому мы разработали некоторую стратегию.
Прохладная история: в первый отчетный период 2014 наши любимые гос органы и 1С внезапно лишили нас сна, выпустив в период с марта по апрель более 10 апдейтов только для конфигурации Бухгалтерия 3.0! Конечно, мы не стали обновлять всё подряд, но даже 3–4 обновления для сотен баз за столь короткий срок — хорошая проверка на прочность.
Читатель может задаться вопросом, откуда столько хлопот? Ответ прост: изменения в законодательстве и при этом в самый последний момент. Например: с начала 2014 года не было утверждённых форм ФСС и ПФР. В одном из первой обновлений их добавили, но только для сдачи в бумажном виде, а в электроном — нет. И так происходит постоянно.
Блокировка
Или через создание файлика в каталоге базы 1Cv8.cdn вот с таким содержимым:
Обновление
Для файлового варианта:
Для SQL варианта:
Как правильно делать резервное копирование баз?
Если вы используете SQL, следующий абзац можно безжалостно скипнуть — он актуален только для файлового режима.
В нашей практике мы не раз встречали базу в неконсистентном состоянии. Более того, в файловом варианте, не существует специальных инструментов, чтобы сообщить базе о начале копирования, нет возможности заблокировать работу с ней, если она идёт прямо сейчас. Мы справлялись с этим так: в полночь сервер RDP переходил в режим запрета новых подключений, через пару часов всех пользователей мягко выгонял скрипт. Затем срабатывало регламентное обновление и резервное копирование.
Выгрузка в dt
Для файлового варианта:
Для SQL варианта:
Все выше сказанное справедливо для 1С Предприятие, платформа 8.3; Бухгалтерия 3.0; Зарплата и Управление Персоналом 2.5.
В следующий раз мы расскажем о работе в режиме разделения данных для нескольких сотен фирм на одну базу. Будем рады услышать вопросы, замечания и предложения. А всем тем кто столкнулся с подобными задачами — хочется пожелать терпения, упорства и веры в победу.
Читайте также: