Где хранится база sql 1с
Каждая база данных SQL Server имеет как минимум два рабочих системных файла: файл данных и файл журнала. Файлы данных содержат данные и объекты, такие как таблицы, индексы, хранимые процедуры и представления. Файлы журнала содержат сведения, необходимые для восстановления всех транзакций в базе данных. Файлы данных могут быть объединены в файловые группы для удобства распределения и администрирования.
Файлы базы данных
SQL Server имеют три типа файлов.
Файл | Описание |
---|---|
Первичная | Содержит сведения, необходимые для запуска базы данных, и ссылки на другие файлы в базе данных. В каждой базе данных имеется один первичный файл данных. Для имени первичного файла данных рекомендуется расширение MDF. |
Вторичная | Необязательные определяемые пользователем файлы данных. Данные могут быть распределены на несколько дисков, в этом случае каждый файл записывается на отдельный диск. Для имени вторичного файла данных рекомендуется расширение NDF. |
Журнал транзакций | Журнал содержит информацию для восстановления базы данных. Для каждой базы данных должен существовать хотя бы один файл журнала. Для файлов журнала транзакций рекомендуется расширение LDF. |
Например, простая база данных с именем Sales включает один первичный файл, содержащий все данные и объекты, и один файл журнала, содержащий сведения журнала транзакций. Более сложная база данных с именем Orders может содержать один первичный файл и пять вторичных файлов. Данные и объекты внутри базы данных распределяются по всем шести файлам, а четыре файла журнала содержат сведения журнала транзакций.
По умолчанию и данные, и журналы транзакций помещаются на один и тот же диск и имеют один и тот же путь для обработки однодисковых систем. Для производственных сред это может быть неоптимальным решением. Рекомендуется помещать данные и файлы журнала на разные диски.
Логические и физические имена файлов
Файлы SQL Server имеют два типа имен файлов.
logical_file_name: имя, используемое для ссылки на физический файл во всех инструкциях Transact-SQL. Логическое имя файла должно соответствовать правилам для идентификаторов SQL Server и быть уникальным среди логических имен файлов в соответствующей базе данных.
os_file_name: имя физического файла, включающее путь к каталогу. Оно должно соответствовать правилам для имен файлов операционной системы.
Дополнительные сведения об аргументах NAME и FILENAME см. в статье Параметры ALTER DATABASE ((Transact-SQL)) для файлов и файловых групп.
Файлы данных и файлы журналов SQL Server могут использоваться как в файловой системе FAT, так и в системе NTFS. В системах Windows рекомендуется использовать файловую систему NTFS по причинам ее большей безопасности.
Файловые группы, доступные как для чтения, так и для записи, а также файлы журналов не поддерживаются со сжатой файловой системой NTFS. В сжатую файловую систему NTFS разрешено помещать лишь доступные только для чтения базы данных и доступные только для чтения вторичные файловые группы. Для экономии места настоятельно рекомендуется использовать сжатие данных вместо сжатия файловой системы.
Если на одном компьютере запущено несколько экземпляров SQL Server, каждый экземпляр получает отдельный каталог по умолчанию для хранения файлов баз данных, созданных в этом экземпляре. Дополнительные сведения см. в разделе Расположение файлов для экземпляра по умолчанию и именованных экземпляров SQL Server.
Размер файла
Файлы SQL Server могут автоматически увеличиваться в размерах, превосходя первоначально заданные показатели. При определении файла пользователь может указывать требуемый шаг роста. Каждый раз при заполнении файла его размер увеличивается на указанный шаг роста. Если в файловой группе имеется несколько файлов, их автоматический рост начинается лишь по заполнении всех файлов.
Дополнительные сведения о страницах и их типах см. в разделе Руководство по архитектуре страниц и экстентов.
Кроме того, можно указать максимальный размер каждого файла. Если максимальный размер файла не указан, файл может продолжать увеличиваться в размерах, пока не займет все доступное место на диске. Эта функция особенно полезна в случаях, когда SQL Server используется в качестве базы данных, внедренной в приложение, где пользователь не имеет удобного доступа к системному администратору. По мере необходимости пользователь может предоставить файлам возможность увеличиваться в размерах автоматически, тем самым снимая с администратора часть забот по наблюдению за свободным пространством базы данных и по распределению дополнительного пространства вручную.
Дополнительные сведения об управлении файлами журнала транзакций см. в разделе Управление размером файла журнала транзакций.
Файлы моментального снимка базы данных
Вид файла, используемый для хранения копируемых во время записи данных моментального снимка базы данных, зависит от того, создается ли моментальный снимок пользователем или используется внутренними механизмами.
- Данные моментального снимка базы данных, созданного пользователем, хранятся в одном или нескольких разреженных файлах. Технология разреженных файлов является свойством файловой системы NTFS. Изначально разреженный файл не содержит данных пользователя, и место на диске под него не выделяется. Общие сведения об использовании разреженных файлов в моментальных снимках базы данных и о том, как растут моментальные снимки базы данных, см. в разделе Просмотр размера разреженного файла моментального снимка базы данных.
- Моментальные снимки базы данных могут использоваться внутренними механизмами при выполнении определенных команд DBCC. Эти команды включают DBCC CHECKDB, DBCC CHECKTABLE, DBCC CHECKALLOC и DBCC CHECKFILEGROUP. Внутренним моментальным снимком базы данных используются разреженные дополнительные потоки данных исходных файлов базы данных. Подобно разреженным файлам, дополнительные потоки данных являются свойством файловой системы NTFS. Использование разреженных дополнительных потоков данных позволяет связать несколько расположений данных с одним файлом или папкой, не затрагивая при этом размер файла или статистику тома.
Файловые группы
- Эта файловая группа содержит первичный файл данных и все вторичные файлы, не входящие в другие файловые группы.
- Пользовательские файловые группы могут создаваться для удобства администрирования, распределения и размещения данных.
Например, Data1.ndf , Data2.ndf и Data3.ndf могут быть созданы на трех дисках соответственно и отнесены к файловой группе fgroup1 . В этом случае можно создать таблицу на основе файловой группы fgroup1 . Запросы данных из таблицы будут распределены по трем дискам, и это улучшит производительность. Подобного улучшения производительности можно достичь и с помощью одного файла, созданного на чередующемся наборе дискового массива RAID. Тем не менее файлы и файловые группы позволяют без труда добавлять новые файлы на новые диски.
Все файлы данных хранятся в файловых группах, перечисленных в следующей таблице.
Файловая группа | Описание |
---|---|
Первичная | Файловая группа, содержащая первичный файл. Все системные таблицы являются частью первичной файловой группы. |
Данные, оптимизированные для памяти | В основе оптимизированной для памяти файловой группы лежит файловая группа файлового потока. |
Файловый поток | |
Определяемые пользователем маршруты | Любая файловая группа, созданная пользователем при создании или изменении базы данных. |
Файловая группа по умолчанию (первичная)
Если в базе данных создаются объекты без указания файловой группы, к которой они относятся, они назначаются файловой группе по умолчанию. В любом случае только одна файловая группа создается как файловая группа по умолчанию. Файлы в файловой группе по умолчанию должны быть достаточно большими, чтобы вмещать новые объекты, не назначенные другим файловым группам.
Файловая группа PRIMARY является группой по умолчанию, если только она не была изменена инструкцией ALTER DATABASE. Системные объекты и таблицы распределяются внутри первичной файловой группы, а не новой файловой группой по умолчанию.
Файловая группа данных, оптимизированных для памяти
Дополнительные сведения об оптимизированных для памяти файловых группах см. в разделе Оптимизированные для памяти файловые группы.
Файловая группа файлового потока
Дополнительные сведения о файловых группах файлового потока см. в статьях FILESTREAM и Создание базы данных с поддержкой FILESTREAM.
Пример файлов и файловых групп
В следующем примере создается база данных на основе экземпляра SQL Server. База данных содержит первичный файл данных, пользовательскую файловую группу и файл журнала. Первичный файл данных входит в состав первичной файловой группы, а пользовательская файловая группа состоит из двух вторичных файлов данных. Инструкция ALTER DATABASE придает пользовательской файловой группе статус файловой группы по умолчанию. Затем создается таблица, определяющая пользовательскую файловую группу. (В этом примере используется универсальный путь к c:\Program Files\Microsoft SQL Server\MSSQL.1 , чтобы не указывать версию SQL Server.)
Данная иллюстрация обобщает все вышесказанное (кроме данных файлового потока).
Стратегия заполнения файлов и файловых групп
В файловых группах для каждого файла используется стратегия пропорционального заполнения. При записи данных в файловую группу компонент Компонент SQL Server Database Engine записывает в каждый файл количество данных, пропорциональное свободному пространству этого файла, вместо записи всех данных в первый файл до его заполнения. Затем запись производится в следующий файл. Например, если в файле f1 свободно 100 МБ, а в файле f2 — 200 МБ, то в файл f1 записывается одна часть данных, а в файл f2 — две части, и так далее. Таким образом, оба файла будут заполнены примерно в одно и то же время, и достигается простейшее распределение данных между хранилищами.
Например, файловая группа состоит из трех файлов, для всех разрешено автоматическое увеличение. Когда свободное пространство во всех файлах группы закончится, будет расширен только первый файл. Когда заполнится первый файл и в файловую группу снова нельзя будет записывать новые данные, будет расширен второй файл. Когда заполнится второй файл и в файловую группу опять нельзя будет записывать новые данные, будет расширен третий файл. Когда заполнится третий файл и в файловую группу нельзя будет записывать новые данные, будет снова расширен первый файл и т. д.
Правила проектирования файлов и файловых групп
Для файлов и файловых групп действуют следующие правила:
- файл или файловая группа не могут использоваться несколькими базами данных. Например, файлы sales.mdf и sales.ndf, содержащие данные и объекты базы данных sales, не могут использоваться никакой другой базой данных.
- файл может быть элементом только одной файловой группы;
- файлы журнала транзакций не могут входить ни в какие файловые группы.
Рекомендации
Рекомендации при работе с файлами и файловыми группами:
- Для большинства баз данных достаточно использовать один файл данных и один файл журнала транзакций.
- При использовании множества файлов данных создайте вторую файловую группу с дополнительным файлом и сделайте ее файловой группой по умолчанию. Тогда в первичном файле будут храниться только системные таблицы и объекты.
- Чтобы увеличить производительность, по возможности разнесите файлы и файловые группы по нескольким доступным дискам. Объекты, активно конкурирующие за свободное пространство, поместите в разные файловые группы.
- Используйте файловые группы для целенаправленного размещения объектов на конкретных физических дисках.
- Помещайте разные таблицы, использующиеся в одних и тех же запросах с соединениями, в разные файловые группы. Этот этап увеличит производительность, так как для поиска соединяемых данных можно будет использовать параллельный ввод-вывод.
- Часто используемые таблицы и некластеризованные индексы, относящиеся к ним, помещайте в разные файловые группы. Использование разных групп файлов увеличит производительность, так как можно будет использовать параллельный ввод и вывод, если файлы находятся на разных жестких дисках.
- Не помещайте файлы журнала транзакций на тот же физический диск, где находятся другие файлы и файловые группы.
- Если необходимо расширить том или раздел, в котором находятся файлы базы данных, с помощью таких средств, как Diskpart, следует сначала выполнить резервное копирование всех системных и пользовательских баз данных и остановить службы SQL Server. Кроме того, после успешного расширения томов дисков рекомендуется выполнить команду DBCC CHECKDB , чтобы обеспечить физическую целостность всех баз данных в томе.
Дополнительные рекомендации по управлению файлами журнала транзакций см. в разделе Управление размером файла журнала транзакций.
Где должны находиться файлы базы данных sql *mdf и *.ldf?
У меня они находятся в каталоге базы, *mdf -3Гб, *ldf - 2 Гб. Хорошо ли так делать? Может ли из-за этого быть замедление работы? Это сделали до меня.
И еще вопрос. Есть заказ на переход снова на dbf версию. В связи с тем, что многие операции под dbf версию работают быстрее в разы. Про индексацию базы после сбоев предупредила. Чего еще ожидать? Что делать с sql файлами в каталоге базы?
"Земную жизнь пройдя до половины. " как сказал поэт.
Тут уже немного за половину: после 1 гигабайта начнутся проблемы по чтению, придется лепить приблуду kernel33.dll
Что касается SQL-баз - "умные люди" советуют держать лог-файл журнала (*.ldf) на отдельном диске, сам файл базы на другом - это также и 7-чных баз данных касается. Что касается расположения файлов - лучше располагать поближе к "корню диска" и не использовать кириллических символов в названии папок.
Где должны находиться файлы базы данных sql *mdf и *.ldf? - согласна с ответом 4.
Есть заказ на переход снова на dbf версию. В связи с тем, что многие операции под dbf версию работают быстрее в разы
Это что за функции такие, может их не так много и имеет смысл адаптировать под SQL
(5) Я даже не хочу об этом думать. Там почти самописная конфигурация, очень сложная и запутанная в смысле количества документов и процессов.
Базу будем резать однозначно, но вот хотят попробовать перейти на скл, что может под ним будет комфортнее работать.
Может ли дать заметный эффект в скорости если просто скл файлы перенести в другое место, как написано в (4)?
М-да. Вы для начала хоть с направлением определитесь однозначно, а то собираетесь переходить одновременно в противоположных направлениях.
(7)Сорри, это описка. На дбф хотят перейти.
На тестовом сервере в дбф версии многие отчеты работают быстрее. И загрузка самой базы в разы быстрее. Да и вообще тестовый сервер работает быстрее. Может потому что на нем никто не работает, а может, потому что у меня файлы скл сервера лежат не в каталоге базы. ?
Нет. Без модернизации конфигурации заметного прироста не будет.
Действительно, при использовании 1cv77 и MS SQL есть ряд проблем с выполнением регламентных операций
однако при больших объемах данных SQL дает значительный прирост производительности в обычной работе пользователей (операции чтения/записи).
Тут надо рассматривать ситуацию исходя их количества одновременных операций ввода данных. Объема отчетных данных.
Анализа используемых алгоритмов и оптимизации.
Проблемы с выполнением регламентных операция можно обойти следующим образом:
1. Выгрузка в ДБФ
2. Выполнение регламентных операций в монопольном режиме (перепроведение и т.д.)
3. Загрузка в SQL
Особенной разницы в расположении конфигурационных файлов нет. Объем данных конфигурации (md) небольшой.
По поводу файлов.
По "феншую" mdf и ldf на разных физических дисках. НО если файлы лежат на том же компьютере где установлен SQL никакой разницы вы не заметите.
По хорошему - методами ускорения будет:
- Перевод на прямые запросы
- Использование УРИБ для разделения ввода данных
Если запустить эту обработку в первой и второй базе ( обе одной конфигурации УПП 1.3 (1.3.38.4)), то имеем для первой базы имя таблицы SQL = Reference131, для второй имя таблицы SQL = Reference162. Если смотреть структуру полей таблиц, то видим, что имена полей различны.
Вопрос: подтвердите или опровергните вывод: таблицы SQL создаются динамически и могут иметь различные имена (имена полей в том числе). При создании новой базы загрузкой конфигурации из *.cf –файла, получим таблицы новой базы с именами, отличными от имен таблиц базы, из которой был выгружен файл конфигурации *.cf .
cf это метаданные 1С к sql отношения не имеют. из того же cf можно вообще сделать файловую базу.
а вообще - проводлжайте наблюдать, вас столько открытий ждет
В базе1 добавили новый справочник, появилась таблица _Reference131.
В базе1 удалил справочник, таблица _Reference131 удалилась.
В базе1 добавили новый справочник, появилась таблица _Reference132
На базу2 накатили обновление из базы1. в базе2 появился справочник с таблицей _Reference131
но если загрузить в 2 разных базы чистых одинаковый Цф - то и структура с большой долей вероятности будет одинакова
>но если загрузить в 2 разных базы чистых одинаковый Цф - то и структура с большой долей вероятности будет одинакова
одинаковы будут id по которым происходит "быстрая" сверка. также это будет гарантировать что данные не отвалятся при нахлабучивании изменений одной конфы на другую через "загрузить"
(6) Ага. Следует заметить, что отсортированный по имени объектов cf-ник и такой же без сортировки скорее всего даст разные имена таблиц и полей, если, конечно, количество объектов метаданных в каждом типе больше 1 :)
Ребята. Всем СПАСИБО!!
НЕОБХОДИМО из SQL-таблиц получать информацию для другого программного продукта (НЕ 1С). получается, что надо создавать таблицу соответствий что ли, чтооб не изменять код при чтении данных 1С из таблиц в другом программном продукте(базу 1С планируем обновлять. ведь можно разными способами получить базу данных обновленную чистую для учета с нового года, например).
Кто-нибудь решал такую проблему? Может кто подскажет оптимальное решение.
(15) снабди своё 1С вебсервисом, который будет отдавать то , что надо, и ни чего лишнего. Иначе однажды утром 1С не заведется потому. что какой-то осел нечаянно сказал DROP DATABASE не в то окно
(15) Образение через com в 1с и получение структуры оттуда.
Но обычно более эффективным считается работа от обратного, когда 1с отдает в нужном виде.
(15) Другой продукт каждый раз при коннекте каким то образом инициирует ПолучитьСтруктуруХраненияБазыДанных(МассивИменМетаданных)
в конфиге и дальше работает через этот мапинг до конца коннекта.
Как реализовать вызов этой процедуры - уже технические формальности
Я создавал базу данных соответствий НазвваниеОбъекта- таблица SQL.так же с реквизитами. дальше запросом получал соответствие и формировал динамически запрос к базе данных. если менялось название какой либо таблицы или реквизита то я просто в базе соответствий менял значение. и запрос опять давал корректный результат. Это все делалось для сверки с 1С другой учетной системы
(21) это легко оспорить в суде и вертеть потом на вертеле. Другое дело, что это не разумно и не безопасно. Вот это уже вертеть чревато
(24) если данные только получать для отчетов и сверок- то это ничем не чревато. а вот если писать в базу то тут существует опасность.
(25) ему придется отдать насторону огин и пароль к кишкам, из которых получить можно что угодно и ни кто не знает, что потом будет по факту получаться и куда передаваться. Это все равно, что голую задницу в интернет выставить
Создай базу данных в которой будут вьюхи и процедуры(которые будут читать данный из рабочий базы)-как уже сказали зверя создать только на чтение.
я не рискнул вьюхи и процедуры создавать в рабочей базе. данные получал в другую базу во вьюхи.
(33) есть штатный безопасный механизм, дающий любой необходимый программный интерфейс к чему угодно. Вебсервисы. Надо научиться ими пользоваться, а не городить велосипеды с квадратными колесами.
все-таки, еще раз вопрос - что в 1С не хватает ? (38) + - изобретать велосипид, БД зависимый. Типа, круто, на asm ваять, а vb - отстой
(38) прямые (Ровные запросы, а не оптимизированные кривым оптимизатором 1С) запросы гораздо быстрее выполняются напрямую-если важна скорость
(34) Значит все средства интеграции, которые предлагает 1С штатно, мы вертели на вертеле? Или просто лень почитать?
(43) прямыми (Ровные запросы, а не оптимизированные кривым оптимизатором 1С) сделаешь базу кривой. В резюме, потом напиши, что сделал суперские оптимизированные запросы
(47) абсолютно не при чем. "За державу обидно".
Меня устраивает "оптимизатор запросов 1С", хоть и не фан. Как, говорилось на этом форуме не раз, готовить запросы надо уметь.
данные из 1С попадают в систему весовых терминалов. обрабатываются там. затем обратно в 1С. кто работает с весовым оборудованием. средства 1С дают хорошие возможности.
(51) Часть блокировок живет в памяти сервера. Сторонне приложение о них не в курсе.
(56) Например у тебя больше чем 1 кластер ( рабочих процессов) как ты их блокировать то будешь?
v8: Разделяемый или Исключительный режим блокировки
(55) в продолжение темы для "адептов":
Для чего надо делать так (0):
ускорить шибко тугой запрос на уровне СУБД, или, запудрить тех, кто будет это хозяйство разбирать
Для чего не надо делать так:
3. даются средства высокого уровня, зачем лезть в кору
4. потом, после реализатора "нетленки" долго нужно разбираться - из прямых запросов к БД, т.к. это уровень не бизнес-логики
(60)
запудрить тупых рисовальщиков формочек и отчётов
0 что значит бд зависимо? 1с примерно одинаково гененрирут названия полей для разных субд (всего 3 варианта)
2 с учетом оговорок смысла не имеет. тк практически любой объект бд- метаданных можно привести к состоянию требующему разрешённому и рекомендованному фирмой 1с вмешательству.
3. вот тут верно. тк 1с8 на риалтайм систему не тянет.
лучше через коннектор.
мне через саповский коннектор в 10 раз удобней было работать с САП
чем на прямую в скл сервер писать.
4. если делать через view с именами метаданных - то все равно.
(64) Рабочие процессы это реально разные процессы со всоей виртуальной памятью.
Другой кластер это другой компьютер а база у всех одна.
Так как ты будешь хранить эти блокировки? Неужто это будет эффективнее чем хранить блокировки в самой БД?
Меня интересует технический процесс.
(65) (66) Народ, желтые книжки почитайте, я с них цитирую. Конечно я в исходниках платформы не копался, но оснований не верить нет.
Блокировок БД бывает недостаточно, поэтому вводятся блокировки прикладного уровня. Сам не раз реализовывал, в других системах. Некоторые СУБД предоставляют механизмы для того, чтобы и прикладные блокировки жили в БД. Грубо говоря API к своему менеджеру блокировок. Но в случае 1С кроссплатформенность и кросс-СУБД диктует свои правила. Поэтому прикладные блокировки живут в памяти сервера 1С. Очевидно они не могут быть свои у каждого рабочего процесса, поэтому в памяти менеджера кластера.
И не путайте "рабочий процесс" и "кластер".
(69)
"желтые книжки почитайте" -
- какую главу. если Вы сами не использовали что-то
то к ЖК лучше не аппилировать, тк это 1с.
В ней заявленое может не работать, рабочее может быть не декларированным.
поэтому и интересно, можете ли Вы точнее чем общий отсыл к
ЖК или интернет подтвердить работу кластера с разными бд.
(70 >подтвердить работу кластера с разными бд.
Не понял
Главу постараюсь найти.
(38) Ты опоздал, вроде как веб сервисами пользоваться умеют уже все, а поднимать веб сервер дорогого стоит
(71) Нашел.
Клиент-серверный вариант. Руководство администратора. 2.1.3. Сервисы кластера
На ИТС тоже есть.
Мало того в 8 ке применяется оптимистическая блокировка. Управляемые блокировки используют хинты SERIALIZABLE,REPEATABLEREAD
Оптимистическая блокировка осуществляется на уровне поля ._Version v8: Кэши разные нужны, кэши нужные важны.
Пессимистическая на уровне блокировок в транзакции. Нет смысла городить огород там, где он не нужен. Но вот если будут реальные примеры объектных блокировок осообенно в контексте нескольких серверов приложений.
Правда, перечитал еще раз про упр. блокировки, и появилось сомнение в (50). Если они действительно держатся ТОЛЬКО до конца транзакции, то ЧИТАТЬ извне вроде можно. Но не уверен до конца.
(76) Так и объектные блокировки имеют смысл без транзакции.
Управляемые блокировки только на уровне транзакции и на уровне БД. Не управляемы это уже уровень изоляции REPEATABLE READ. Но тогда и на уровне блокировок запросов нет смысла в объектных блокировках для клиент сервера. Для Локальных баз на уровне LockFile
(78) Давай прежде всего не путать объектные блокировки и управляемые. Первые с танзакциями не связаны, они чисто прикладные.
Вот про это я и говорю зачем мешать объектные блокировки и транзакционными блокировками бд. Объектные блокировки так или иначе не взаимодействуют с блокировками БД. Тогда какой в них смысл? Управляемые блокировки это блокировки БД в режиме изоляции Read Commited с помощью хинтов SERIALIZABLE,REPEATABLEREAD. Автоматические это уже на уровне Изоляции REPEATABLE READ.
(81) Давай ты прочитаешь (82), с терминологией и общей концепцией все устаканится, потом продолжим.
Правда, там в тексте упоминается 8.1, кое-что могло и устареть.
(81) > Управляемые блокировки это блокировки БД в режиме изоляции Read Commited с помощью хинтов SERIALIZABLE,REPEATABLEREAD.
Это неправда, при наложении управляемой блокировки никакие блокировки в БД не накладываются.
(84)
раньше
(до 14 релиза)
накладывались блокировки субд.
сейчас может исправили.
ух разошлись про блокировки. Ну и что, выяснили что нибудь? Если, выяснили, то через несколько релизов платформы 1С забудьте. Вам же ясно говорят, нечё лезть куда ни надо
(88) Внутри одного из менеджеров кластера (процесс) запускается служба (в терминах 1С) транзакционных блокировок, конечно, это маршалинг, но если рабочих процессов больше одного, то без этого управляемые блокировки не организовать. Если рабочий процесс один то в предыдущих версиях этот механизм блокировок размещался в рабочем процессе, с тех пор рекомендация, на х64 запускать один рабочий процесс, если нет веских причин поступить по-другому.
(88) Так и сказано управляемые блокировки используют Read Commited (или Snapshot Isolation в 8.3), а блокировки в разрезе объектов 1С держит менеджер блокировок.
(89) Так это и есть официально объяснение лицензионного запрета, вы там наулучшаете, а мы в свою очередь всё переделаем внутри в новой версии и в неё уже автоматом ничего не сконвертируется при обновлении, и могут обвинить в этом не улучшателя, а производителя.
(90) Объясни зачем городить огород если все это можно решить на уровне БД, для рабочих процессов больше 1?
Могут быть кластеры на нескольких серверах. Где выигрыш если рабочих процессов больше чем 1?
(91) Зачем в запрсах применять хинты
FROM _AccRg5523 T3 WITH(SERIALIZABLE)
LEFT OUTER JOIN _Acc6_ExtDim5518 T4 WITH(REPEATABLEREAD)
(91) Глупо изобретать велосипед, там где он уже эффективно работает. Snapshot Isolation хорорша при чтении данных снимка данных до начала транзакции. Если же ты хочешь, что бы данные не изменялись до конца транзакции нужно накладывать блокировки явно.
(92) Например, надо заблокировать одно значение субконто в регистре бухгалтерии по всем счетам, предложи как это сделать блокировками на уровне СУБД.
Менеджер блокировок просто запишет в своих структурах: Пространство блокировок (РБ.Хозрасчетный), Субконто, Его значение. И будет держать его до конца транзакции.
Всё дело в том, что, именно, сервер 1С хранит в себе бизнес модель на предметном уровне. Например, меня огорчает, что журнал регистрации не хранится в БД, но у производителя свои взгляды на продукт.
SET TRANSACTION ISOLATION LEVEL READ COMMITTED
go
SELECT spid, blocked FROM master..sysprocesses WHERE blocked > 0 AND lastwaittype LIKE 'LCK_%'
go
BEGIN TRANSACTION
go
(93) .1 это точно управляемый режим новых версий 8.2?
.2 так это ради Оракла, который версионник, а не блокировочник как MS SQL, поэтому все блокировки они решили делать сами с учётом внутренней природы бизнес объектов (справочники, документы и тд.) и не объектов (регистры). А работать должно везде одинаково!
(96) Для автоматического режима хинт REPEATABLEREAD не имеет смысла.
(97) Для Оракла есть FOR UPDATE и DBMS_LOCK. Но не являюсь хоть каким то знатоком Оракула.
Блокировки могут быть еще в режиме 4 (разделяемая блокировка таблицы share mode, генерируется, например, оператором lock table in share mode) и 5 (разделяемая блокировка таблицы и монопольная блокировка строк share row exclusive; генерируется, например, оператором lock table in share row exclusive mode). Но эти режимы встречаются крайне редко.
Установка SQL Server состоит из одного или нескольких отдельных экземпляров. Как экземпляр по умолчанию, так и именованный экземпляр имеет собственный набор программных файлов и файлов данных, а также набор общих файлов, используемых всеми экземплярами SQL Server , установленными на компьютере.
Для экземпляра SQL Server , включающего Компонент Database Engine, Службы Analysis Servicesи Службы Reporting Services, каждый компонент имеет полный набор файлов данных и исполняемых файлов, а также общие файлы, используемые всеми компонентами.
Чтобы изолировать друг от друга папки установки, формируется уникальный идентификатор экземпляра для каждого из компонентов экземпляра SQL Server.
Программные файлы и файлы данных не могут быть установлены на съемном диске, в файловой системе со сжатием данных, в каталоге расположения системных файлов, а также на общих дисках экземпляра отказоустойчивого кластера.
Может потребоваться настроить программное обеспечение, например антивирусное и антишпионское приложения, чтобы исключить из проверки типы файлов и папки SQL Server. Дополнительные сведения см. в этой статье службы поддержки: Настройка антивирусного программного обеспечения на компьютерах, где выполняется SQL Server.
Системные базы данных (Master, Model, MSDB и TempDB) и пользовательские базы данных компонента Компонент Database Engine можно установить с использованием протокола SMB в качестве хранилища файлового сервера Server Message Block (SMB). Это относится как к изолированному варианту установки SQL Server , так и к установке кластеров отработки отказа SQL Server . Дополнительные сведения см. в разделе Установка SQL Server с общей папкой SMB в качестве хранилища.
Не удаляйте следующие каталоги или их содержимое: Binn, Data, Ftdata, HTML или 1033. При необходимости можно удалить другие каталоги, однако возможно, что не удастся вернуть утраченную функциональность или восстановить потерянные данные без удаления и повторной установки SQL Server. Не удаляйте и не изменяйте HTM-файлы в каталоге HTML. Они необходимы для правильной работы средств SQL Server .
Общие файлы для всех экземпляров SQL Server
Общие файлы, используемые всеми экземплярами на одном компьютере, устанавливаются в папку drive>:\Program Files\Microsoft SQL Server\nnn\. drive> — это буква диска, на который устанавливаются компоненты. Обычно по умолчанию диск C. Значение nnn определяет версию. В следующей таблице перечислены версии для путей. — значение версии, используемое в идентификаторе экземпляра, и путь реестра.
Версия | *nnn* | |
---|---|---|
SQL Server 2019 (15.x) | 150 | 15 |
SQL Server 2017 (14.x); | 140 | 14 |
SQL Server 2016 (13.x); | 130 | 13 |
SQL Server 2014 (12.x) | 120 | 12 |
SQL Server 2012 (11.x) | 110 | 11 |
Расположение файлов и сопоставление данных реестра
Во время установки SQL Server для каждого компонента сервера создается идентификатор экземпляра. В этой версии SQL Server сервер состоит из компонента Компонент Database Engine, служб Службы Analysis Servicesи Службы Reporting Services.
Идентификатор экземпляра по умолчанию указывается в следующем формате.
Для компонента Компонент Database Engine— MSSQL, за которым следуют основной номер версии, символ подчеркивания и дополнительный номер версии (если применимо), затем точка и имя экземпляра.
Для служб Службы Analysis Services— MSAS, за которым следуют основной номер версии, символ подчеркивания и дополнительный номер версии (если применимо), затем точка и имя экземпляра.
Для служб Службы Reporting Services— MSRS, за которым следуют основной номер версии, символ подчеркивания и дополнительный номер версии (если применимо), затем точка и имя экземпляра.
Ниже приведены примеры идентификаторов экземпляров по умолчанию для данной версии SQL Server .
MSSQL.MSSQLSERVER — экземпляр SQL Server по умолчанию.
MSAS.MSSQLSERVER — экземпляр по умолчанию служб SQL Server Analysis Services.
MSSQL.MyInstance — именованный экземпляр SQL Server с именем "MyInstance".
Именованный экземпляр SQL Server , в состав которого входит компонент Компонент Database Engine и службы Службы Analysis Services, имеет имя «MyInstance» и устанавливается каталоге по умолчанию, имеет следующую структуру каталогов.
C:\Program Files\Microsoft SQL Server\MSSQL.MyInstance\
C:\Program Files\Microsoft SQL Server\MSAS.MyInstance\
В качестве идентификатора экземпляра может быть указано любое значение, следует только избегать применения специальных символов и зарезервированных ключевых слов.
Службы Integration Services и клиентские компоненты не привязаны к экземпляру, поэтому им не присваивается идентификатор экземпляра. По умолчанию компоненты, не привязанные к экземпляру, устанавливаются в один каталог: drive>:\Program Files\Microsoft SQL Server\nnn\. Изменение пути установки для одного компонента приводит к его изменению и для всех остальных компонентов. При последующих установках компоненты, не зависящие от экземпляра, устанавливаются в каталог исходной установки.
SQL Server Службы Analysis Services — это единственный компонент SQL Server, который поддерживает переименование экземпляра после установки. При переименовании экземпляра служб Службы Analysis Services его идентификатор экземпляра не изменится. После переименования экземпляра в каталогах и разделах реестра по-прежнему используется идентификатор экземпляра, созданный во время установки.
В разделе реестра HKLM\Software\Microsoft\MicrosoftSQL Server\идентификатор_экземпляра> создается куст для компонентов, привязанных к экземпляру. Например,
В реестре также хранится сопоставление идентификаторов экземпляров с именами экземпляров. Сопоставление идентификатора экземпляра с именем экземпляра осуществляется следующим образом:
[HKEY_LOCAL_MACHINE\Software\Microsoft\MicrosoftSQL Server\Instance Names\SQL] ""="MSSQL"
[HKEY_LOCAL_MACHINE\Software\Microsoft\MicrosoftSQL Server\Instance Names\OLAP] ""="MSAS"
[HKEY_LOCAL_MACHINE\Software\Microsoft\MicrosoftSQL Server\Instance Names\RS] ""="MSRS"
Указание путей к файлам
В ходе установки вы можете изменить путь установки для следующих компонентов:
Путь установки отображается в программе установки только для компонентов с пользовательской целевой папкой.
Компонент | Путь по умолчанию | Настраиваемый или фиксированный путь |
---|---|---|
Компонент Database Engine компоненты сервера | \Program Files\MicrosoftSQL Server\MSSQL.\ | Настраивается |
Компонент Database Engine файлы данных | \Program Files\MicrosoftSQL Server\MSSQL.\ | Настраивается |
Службы Analysis Services сервер | \Program Files\MicrosoftSQL Server\MSAS.\ | Настраивается |
Службы Analysis Services файлы данных | \Program Files\MicrosoftSQL Server\MSAS.\ | Настраивается |
Службы Reporting Services сервер отчетов | \Program Files\MicrosoftSQL Server\MSRS.\Reporting Services\ReportServer\Bin\ | Настраивается |
Службы Reporting Services диспетчер отчетов | \Program Files\MicrosoftSQL Server\MSRS.\Reporting Services\ReportManager\ | Фиксированный путь |
Службы Integration Services | \nnn\DTS\ 1 | Настраивается |
Клиентские компоненты (за исключением bcp.exe и sqlcmd.exe) | \nnn\Tools\ 1 | Настраивается |
Клиентские компоненты (bcp.exe и sqlcmd.exe) | \Client SDK\ODBC\nnn\Tools\Binn | Фиксированный путь |
Объекты COM для репликации и размещения на сервере | drive>:\Program Files\Microsoft SQL Server\nnn\COM\ 2 | Фиксированный путь |
Службы Integration Services библиотеки DLL служб для механизмов преобразования данных в реальном режиме времени и конвейерного преобразования данных и программа командной строки dtexec | drive>:\Program Files\Microsoft SQL Server\nnn\DTS\Binn | Фиксированный путь |
Библиотеки DLL, которые обеспечивают управляемое соединение, поддерживаемое для служб Службы Integration Services | drive>:\Program Files\Microsoft SQL Server\nnn\DTS\Connections | Фиксированный путь |
Библиотеки DLL для каждого типа перечислителей, которые поддерживают службы Службы Integration Services | drive>:\Program Files\Microsoft SQL Server\nnn\DTS\ForEachEnumerators | Фиксированный путь |
SQL Server , поставщики инструментария WMI | drive>:\Program Files\Microsoft SQL Server\nnn\Shared\ | Фиксированный путь |
Компоненты, которые разделены между всеми экземплярами SQL Server | drive>:\Program Files\Microsoft SQL Server\nnn\Shared\ | Фиксированный путь |
Убедитесь, что папка \Program Files\MicrosoftSQL Server\ защищена через ограничение разрешений.
Обратите внимание, что диск по умолчанию для расположений файлов — systemdrive, обычно это диск C. Пути установки вложенных компонентов определяются путем установки родительского компонента.
1 Используется общий путь установки для Службы Integration Services и клиентских компонентов. Изменение пути установки для одного компонента влечет изменение пути для других компонентов. При последующих установках компоненты устанавливаются в расположение исходной установки.
2 Этот каталог используется всеми экземплярами SQL Server на компьютере. При применении обновления к любому из экземпляров на компьютере все файловые изменения коснутся каждого из них. При добавлении компонентов в существующую конфигурацию невозможно ни изменить расположение ранее установленного компонента, ни указать расположение нового. Необходимо либо установить дополнительные компоненты в каталоги, созданные программой установки, либо удалить продукт и установить его заново.
Для кластеризованных конфигураций необходимо выбрать локальный диск, доступный на всех узлах кластера.
При задании пути установки во время установки компонентов сервера или файлов данных программа установки использует идентификатор экземпляра в дополнение к заданному положению для программ и файлов данных. Программа установки не пользуется идентификаторами экземпляров для средств и других общих файлов. Идентификатор экземпляра также не используется для программ и файлов данных служб Службы Analysis Services , но используется для репозитория служб Службы Analysis Services .
При указании пути установки для компонента Компонент Database Engine программа установки SQL Server использует этот путь в качестве корневого каталога этой установки для всех папок, относящихся к экземпляру, включая файлы данных SQL. Если в этом случае в качестве корневого каталога указать "C:\Program Files\MicrosoftSQL Server\MSSQL.\MSSQL\", то относящиеся к экземпляру каталоги добавляются в конец этого пути.
Поэтому при использовании функции обновления USESYSDB в мастере установки SQL Server (режим установки с пользовательским интерфейсом) можно попасть в ситуацию, когда продукт окажется установленным в рекурсивной структуре папок. Например, SQLProgramFiles>\MSSQL14\MSSQL\MSSQL10_50\MSSQL\Data\. Поэтому при использовании функции USESYSDB вместо компонента Компонент Database Engine необходимо указывать путь установки файлов данных SQL.
Обычно файлы данных можно найти в дочернем каталоге с именем Data. Например, если при обновлении вы укажете "C:\Program Files\MicrosoftSQL Server\MSSQL." в качестве корневого каталога данных для системных баз данных, то файлы данных должны располагаться в каталоге "C:\Program Files\MicrosoftSQL Server\MSSQL.\MSSQL\Data".
Данные, которые определяют логику функционирования системы на базе 1С:Предприятия, относятся к информационной базе. Хранение информационной базы осуществляется в базе данных с виде набора таблиц, для чего 1С:Предприятие 8.1 может использовать одну из четырех систем управления базами данных (СУБД):
* Встроенную в 1С:Предприятие 8.1 (файловый вариант информационной базы). В этом случае все данные информационной базы хранятся в файле с именем 1Cv8.1CD. Этот файл имеет двоичный формат и по сути является базой данных для встроенной в 1С:Предприятие 8.1 СУБД.
* Microsoft SQL Server (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных Microsoft SQL Server.
* PostgreSQL (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных PostgreSQL.
* IBM DB2 (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных IBM DB2.
На уровне объектов базы данных (таблиц, полей, индексов и т. п.) как файловый так и клиент-серверный вариант информационной базы имеют сходный формат (отличающийся несущественными деталями). Некоторая информация об этом формате содержится ниже.
Вся информационная база представляется в базе данных в виде набора таблиц. Среди них есть несколько таблиц, которые обязательно присутствуют в представлении любой информационной базы:
* Config - основная конфигурация информационной базы. Эта конфигурация соответствует реальной структуре данных и используется 1С:Предприятием 8.0 в режиме Предприятия.
* ConfigSave - конфигурация, редактируемая Конфигуратором. Конфигурация из ConfigSave переписывается в Config при выполнении "Обновления конфигурации базы данных" в Конфигураторе, а наоборот - при выполнении в Конфигураторе операции "Конфигурация - Конфигурация базы данных - Вернуться к конфигурации БД".
* Files содержит служебную информацию, например, о работе с хранилищем конфигурации.
* Params содержит параметры информационной базы. Среди них:
=> Список пользователей информационной базы.
=> Национальные настройки информационной базы.
=> Таблица соответствия объектов метаданных и объектов базы данных (таблиц, полей, индексов).
=> Некоторая другая информация.
* _YearOffset - смещение дат в базе данных. Эта таблица создается только при использовании Microsoft SQL Server.
* DBSchema содержит информацию о структуре базы данных 1С:Предприятия и определяет другие объекты базы данных, используемые данной информационной базой.
Перечень и структура других таблиц базы данных определяется конкретной конфигурацией, а именно, определенными в ней объектами метаданных. Имя каждой таблицы состоит из буквенного префикса и следующего за ним номера. Префикс определяет назначение таблицы, а номер позволяет различать таблицы одинакового назначения, относящиеся к разным объектам метаданных. Если в качестве СУБД используется IBM DB2, то описанную структуру имеют не имена таблиц, а их псевдонимы.
Если в конфигурации определен хотя бы один план обмена с установленным флагом "Распределенная информационная база", то будут созданы следующие таблицы:
* _ConfigChangeRec - таблица регистрации изменений объектов конфигурации.
* _ConfigChangeRec_ExtProps - таблица имен файлов измененных внешних свойств объектов конфигурации.
Ниже перечислены различные объекты метаданных, которым могут соответствовать те или иные таблицы.
* Константы
=> _Consts содержит текущие значения всех констант, определенных в конфигурации.
=> _ConstsChangeRec - таблица регистрации изменений констант. Создается, если хотя бы одна константа участвует хотя бы в одном плане обмена.
* Планы обмена
=> _Node - таблица плана обмена.
=> _Node_VT - табличная часть плана обмена, создается для каждой табличной части.
* Справочники
=> _Reference - таблица справочника.
=> _Reference_VT - табличная часть справочника - для каждой табличной части.
=> _ReferenceChangeRec - таблица регистрации изменений справочника. Создается, если справочник участвует хотя бы в одном плане обмена.
* Документы
=> _Document - таблица документов для каждого объекта метаданных "документ".
=> _Document_VT - табличная часть документа - для каждой табличной части каждого документа.
=> _DocumentChangeRec - таблица регистрации изменений объекта метаданных типа "документ". Создается для каждого объекта метаданных типа "документ", если он участвует хотя бы в одном плане обмена.
* Последовательности документов
=> _Sequence - таблица регистрации документов - для каждой последовательности.
=> _SequenceBoundary - таблица границ последовательности - для каждой последовательности.
=> _SequenceChangeRec - таблица регистрации изменений последовательности. Создается для каждой последовательности, которая участвует хотя бы в одном плане обмена.
* Журналы документов.
=> _DocumentJournal - таблица журнала документов, создается для каждого журнала документов.
* Перечисления
=> _Enum - таблица перечисления - по одной для каждого перечисления.
* Планы видов характеристик
=> _Chrc - основная таблица плана видов характеристик.
=> _Chrc_VT - табличная часть плана видов характеристик - для каждой табличной части.
=> _ChrcChangeRec - таблица регистрации изменений плана видов характеристик. Создается, если план видов характеристик участвует хотя бы в одном плане обмена.
* Планы счетов
=> _Acc - основная таблица плана счетов.
=> _Acc_ExtDim - таблица видов субконто плана счетов, создается для плана счетов в том случае, если максимальное количество субконто больше нуля.
=> _Acc_VT - табличная часть плана счетов, создается для каждой табличной части плана счетов.
=> _AccChangeRec - таблица регистрации изменений плана счетов. Создается, если план счетов участвует хотя бы в одном плане обмена.
* Планы видов расчета
=> _CalcKind - основная таблица плана видов расчета.
=> _CalcKind_BaseCK - таблица базовых видов расчета, создается для плана видов расчета в случае, если его свойство "Зависимость от базы" имеет значение, отличное от "Не зависит".
=> _CalcKind_DisplacedCK - таблица вытесняемых видов расчета, создается для плана видов расчета в случае, если у него установлен флаг "Использует период действия".
=> _CalcKind_LeadingCK - таблица ведущих видов расчета - для каждого плана видов расчета.
=> _CalcKindDN - вспомогательная таблица для порядка вытеснения, создается, если у плана видов расчета установлен флаг "Использует период действия".
=> _CalcKind_VT - табличная часть плана видов расчета, создается для каждой табличной части.
=> _CalcKindChangeRec - таблица регистрации изменений плана видов расчета. Создается, если план видов расчета участвует хотя бы в одном плане обмена.
* Регистры сведений
=> _InfoReg - таблица движений регистра сведений.
=> _InfoRegChangeRec - таблица регистрации изменений регистра сведений. Создается, если регистр сведений участвует хотя бы в одном плане обмена.
* Регистры накопления
=> _AccumReg - таблица движений регистра накопления.
=> _AccumRegTotals - таблица итогов регистра накопления, если регистр поддерживает остатки.
=> _AccumRegTurnovers - таблица оборотов регистра накопления, если регистр поддерживает обороты.
=> _AccumRegChangeRec - таблица регистрации изменений регистра накопления. Создается, если регистр накопления участвует хотя бы в одном плане обмена.
=> _AccumRegOptions - таблица настроек хранения итогов регистров накопления одна на все регистры накопления.
* Регистры бухгалтерии
=> _AccntReg - таблица движений регистра бухгалтерии.
=> _AccntRegED - таблица значений субконто регистра бухгалтерии, создается в том случае, если он ссылается на план счетов, у которого максимальное количество субконто больше нуля.
=> _AccTtl0 - таблица итогов по счету.
=> _AccTtl - где i от 1 до максимального количества субконто. Таблица итогов по счету с количеством видов субконто равным i.
=> _AccTtlC - таблица итогов оборотов между счетами, только для регистра бухгалтерии поддерживающего корреспонденцию.
=> _AccntRegChangeRec - таблица регистрации изменений регистра бухгалтерии. Создается, если регистр бухгалтерии участвует хотя бы в одном плане обмена.
=> _AccntRegOptions - таблица настроек хранения итогов одна на все регистры бухгалтерии.
* Регистры расчета
=> _CalcReg - таблица движений регистра расчета.
=> _CalcRegActPer - таблица фактических периодов действия для регистра расчета, создается, если у регистра расчета установлен флаг "Период действия".
=> _CalcRegChangeRec - таблица регистрации изменений регистра расчета. Создается для каждого регистра расчета, участвующего хотя бы в одном плане обмена.
=> _CalcRegRecalc - таблица перерасчета регистра расчета, создается для каждого перерасчета.
=> _CalcRegRecalcChangeRec - таблица регистрации изменений перерасчета. Создается, если перерасчет участвует хотя бы в одном плане обмена.
* Бизнес-процессы
=> _BPRoutePoint - таблица точек маршрута бизнес-процесса для каждого бизнес-процесса.
=> _BusinessProcess - основная таблица бизнес-процесса.
=> _BusinessProcess_VT - табличная часть бизнес-процесса для каждой табличной части.
=> _BusinessProcessChangeRec - таблица регистрации изменений бизнес-процесса. Создается для каждого бизнес-процесса, участвующего хотя бы в одном плане обмена.
* Задачи
=> _Task - основная таблица задачи.
=> _Task_VT - табличная часть задачи для каждой табличной части.
=> _TaskChangeRec - таблица регистрации изменений в задачах. Создается для каждого объекта метаданных типа "задача", который участвует хотя бы в одном плане обмена.
При использовании IBM DB2 префиксы псевдонимов таблиц начинаются не с символа подчеркивания, а сразу с буквенной части.
Количество этих таблиц зависит от функциональности конфигурации и может быть достаточно большим. В штатном режиме 1С:Предприятие не выполняет проверку их наличия, а также целостности и непротиворечивости содержащихся в них данных. Поэтому важно, чтобы база данных, в которой размещена информационная база 1С:Предприятия 8.1, была защищена от несанкционированного доступа и ее модификация выполнялась только средствами 1С:Предприятия. Для проверки необходимо использовать функцию "Администрирование - Тестирование и исправление", встроенную в конфигуратор.
Важно также, чтобы резервное копирование и восстановление базы данных, хранящей информационную базу, выполнялось только целиком. С этой целью рекомендуется использование средств резервного копирования баз данных, встроенных в в используемую СУБД. Резервное сохранение файлового варианта информационной базы может быть выполнено копированием файла 1Cv8.1CD.
В конфигураторе есть специальная функция: Администрирование - Выгрузить информационную базу. С ее помощью можно выгрузить в указанный файл (файл выгрузки) все данные, относящиеся к информационной базе, и больше никакие. Обратная ей функция "Загрузить информационную базу" позволяет в текущую информационную базу вместо существующих загрузить все данные из файла выгрузки. Эти функции также можно использовать для резервного копирования данных информационной базы как в файловом так и в клиент-серверном варианте.
Как просмотреть структуру таблиц информационной базы?
Читайте также: