Всем доброе время суток !

Коронавирус коронавирусом но работу хоть по удаленке никто не отменял.

Возникло несколько вопросов по SQL, у кого есть желание / возможность просьба подсказать.

Есть база SQL файл данных которой разбит на две части. Размер базы более 100 Гб. Хочу сделать копию этой базы создав новую базу и восстановив в нее бэкап.

Вопрос - возможно ли восстановить бэкап базы файл данных которой разбит на две части в базу у которой один файл данных ?

Создать новую базу с одним файлом, а потом восстановить в неё бэкап. Попробовать - 2 минуты.

(1) Не даст.

(0) ну через ДТ, но это думаю долго или очень долго

Если комп(сервер) шустрый - то не долго. Базу 200 гб выгружал/загружал недавно - меньше часа заняло.

Тогда DBCC SHRINKFILE(<file2>, EMPTYFILE) а потом удаление этого файла из базы

(5) Мдя... С твоими советами...

(6) Я проверил - это работает. EMPTYFILE "выжимает" данные из указанного файла в другие файлы его группы. И после этого он доступен для удаления из базы.

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

(8) Из одного - запросто.
А когда база разбита на несколько физических файлов - бекап из неё в один файл - у меня в своё время не получилось...

(1) Пробовал. Не дает.

(10) Ну тогда восстанавливай как обычно с двумя файлами, а потом (5), правда это займет определенное время и место на диске в размере исключаемого файла.

(3) У меня в этой базе (данные которой разделены на два файла) идет работа КПП (круглосуточная регистрация въездов-выездов автотранспорта). С обменом с двумя другими.
В базе данные по трем организациям. Одна сейчас закрывается.

Я хочу сделать копию базы, переключить на нее КПП, и из этой новой базы удалять данные по закрываемой организации.
Тогда уже можно будет исходную выгрузить в DT, создать новую базу с одним файлом данных и загрузить в нее данные из DT.

Не пойму еще один момент.

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

Но при этом отмечается что

1. Файлы данных и файл транзакций нужно разносить на разные диски (в моем случае сисадмин который разделил файл данных так не сделал).
2. Файлы скуля желательно выносить на внешний RAID. Или на отдельный быстрый диск. В этом случае при проблеме с сервером RAID подсоединяется к другому серверу и все.

То есть сисадмин не сделав самые простые рекомендации по повышению быстродействия сразу перешел к разделению файла данных на несколько частей.

(13) Оба пункта требуют финансовых вложений( диски хорошие, RAID). Админу дали денег на эти простые рекомендации? А ускорения работы требуют...

Делаешь копию базы, из нее уже выгружаешь дт и загружаешь в третью однофайловую копию

(13) google://секционирование+ms+sql

И откроется истина, что кроме параллельной работы с файлами основная цель - разделение данных по важности/частоте использования/твоим признакам. Что влечет уменьшение нагрузки на диск, уменьшение эскалаций блокировок и прочие плюшки.

А ты в свой рейд уперся.

(13) при реструктуризации 1с8 все  равно вернет все таблицы в primary.

модераторы, перенесите тему из 1с v8  it admin

(16) 1c не использует секционирование

(19) 1с нет. А вот mssql - вполне.

(15) Прочитай еще раз внимательно (12) пожалуйста. Там подробно написано почему нельзя остановить эту базу на время выгрузки в DT и загрузки из него.

(16) "Что влечет уменьшение нагрузки на диск, уменьшение эскалаций блокировок и прочие плюшки."

Поясни свою мысль пожалуйста более подробно.

В базе ведется учет ремонта автомашин. То есть операции - поступление товаров на склад, перемещение в производство, оформление заказ нарядов.
Ну и резервирование товаров с заказами поставщикам конечно же.

Заказ наряды после закрытия пользователь не редактирует - это запрещено. Только через возвращение в работу бухгалтерией или мной.
Месяц регулярно закрывается. То есть данные прошлого месяца могут править только бухи или я (причем бухи только с моего ведома).

В чем смысл в таком случае разделения файла данных на две части ?

(16) "что влечет уменьшение нагрузки на диск"
Для этого первый совет - расположение файла данных и журнала транзакций на разных дисках. Но сисадмин это реализовывать не стал.

"уменьшение эскалаций блокировок".
В базе работает 50 юзеров, документы максимум по 30-50 строк. Никаких блокировок и близко нет. Конечно если я параллельно работе юзеров запущу проведение документов они появятся.

"прочие плюшки."
Какие например плюшки ощутимо можно получить при этом ?

(22) добавь узел с полной регистрацией, на копии сделай выгрузку, загрузку, потом в копию перенеси измененияиз основной и поменяй их местами. Усё

(24) Так основная проблема в том что нужно сделать копию базы с такой же структурой (два файла данных и один файл лога).

Остановить КПП на полчаса чтобы сделать бэкап и восстановить его в копию вполне можно.

(25) А зачем останавливать для бекапа??

(26) Между базами с периодичностью в 2 минуты идет обмен.

То есть смотри ситуация.

База 1 это там где КПП регистрирует въезд выезд. Круглосуточно.
Эта база обменивается с базой 2 и базой 3. В каждой из них данные по своей организации. Обмен двухсторонний.

Для того чтобы копия базы 1 после восстановления была идентичной нужно

1. Остановить регламентное задание по обмену в базе 1.
2. Прервать работу пользователей КПП которые регистрируют там въезды выезды.
3. Сделать после этого бэкап базы 1.
4. Создать новую базу 4.
5. Восстановить в нее бэкап базы 1.
6. Запустить в базу 4 пользователей КПП которые регистрируют там въезды выезды.
7. Включить регламентное задание по обмену в базе 4.

Без остановки (без выполнения пунктов 1 и 2) к моменту окончания реализации пункта 5 данные в базе 1 и базе 4 будут отличаться на те которые пользователи КПП введут руками и на на те которые придут в нее с обменом.

(21) Тупишь

(27) В фуллбекап попадают все данные из транзакций, завершённых на момент завершения бекапа..

(29) "В фуллбекап попадают все данные из транзакций, завершённых на момент завершения бекапа"

Ну да.

Смотри.

В 10-00 ты начал делать фуллбекап базы 1.
Предположим что регламентный обмен в ней остановил. Но в ней продолжают работать пользователи КПП которые вводят данные.

В 10-05 создание фуллбекапа базы 1 закончилось.
В 10-10 ты начал восстанавливать фуллбекап базы 1 в базу 5.

В 10-15 восстановление фуллбекапа базы 1 в базу 4 закончилось.

За 15 минут (с 10-00 когда ты начал делать фуллбекап базы 1 до 10-15 когда восстановление фуллбекапа базы 1 в базу 4 закончилось) у тебя в базе 1 пользователи КПП забьют еще несколько документов. Которых в базе 4 не будет.

Поэтому и нужно перед созданием фуллбекапа базы 1 прервать там работу пользователей КПП (помимо остановки регламентного задания по обмену).

(5) Спасибо за подсказку. Проверил по форуму sql.ru ваш совет - все правильно.

(6) Он все правильно написал.

Цитата:

DBCC SHRINKFILE with the EMPTYFILE parameter will move all data out of a file into other files in the filegroup. Once this is complete, the empty file is essentially marked as read-only, preventing new data from being added.

(6)
Цитата:

EMPTYFILE

Переносит все данные из указанного файла в другие файлы в той же файловой группе. Другими словами, EMPTYFILE переносит данные из указанного файла в другие файлы в той же файловой группе. EMPTYFILE гарантирует, что новые данные не будут добавлены в файл, даже если в него разрешена запись. Для удаления файла можно использовать инструкцию ALTER DATABASE. Если с помощью инструкции ALTER DATABASE изменяется размер файла, флаг "только для чтения" сбрасывается, позволяя добавлять данные.

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

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

(30)несколько документов могут и перезабить наверное. Не космические корабли же там у вас.

(34) "у меня вопрос-а почему нельзя просто сделать бэкап,а потом в той же базе начать удаление данных ненужной организации-если она действительно не нужна,то к ее данным обращения не будет."

В базе 1 есть данные учета по организации которая закрывается но эти данные нужны. Поэтому смысл того что я сделал - создать для КПП отдельную базу (в которой будут только регистрации въездов и привязки к заказ нарядам.

Все данные по организации которая закрывается в новой базе можно уже удалять. В результате
1. В базу 1 КПП больше не заходит.
2 В базе 4 после удаления данных по закрываемой организации останутся данные только регистрации въездов и привязки. Итого из 100 Гб база похудеет до 1-2 Гб.

(34) "опять же,включив в базе узел распределенного файла обмена можно получить в нем все сделанные изменения,которые спокойно перегнать в базу бэкапа.
на момент же смены базы все равно будет остановка."

Конечно можно сделать и так. Но зачем лишняя головная боль ?
Остановил доступ в базу, остановил обмен, сделал бэкап. Восстановил бэкап, запустил КПП. Запустил обмен. Менее чем за полчаса все сделал.

Подскажите пожалуйста еще один момент.

На сервере создание бэкапов настроено через вызов хранимой процедуры.

То есть в плане обслуживания стоит конструкция

exec DBA.dbo.usp_DatabaseBackup

с указанием параметров.

Хочу посмотреть текст хранимой процедуры.

Выполняю на сервере

use DBA
go
sp_helptext usp_DatabaseBackup

Получаю сообщение

Текст для объекта "usp_DatabaseBackup" зашифрован.

Что можно сделать в этом случае чтобы текст прочитать ?

(38)
http://www.t-sql.ru/post/Encryption.aspx

Еще один вопрос возник. Не пойму как такое может быть.

Смотрю размеры самых больших таблиц в базе.
Вижу таблицу размером 9 Гб.

Смотрю по идентификатору.

РегистрНакопления.ТоварыВПроизводстве.Остатки

Регистр пустой (удалены движения всех документов по этому регистру).

После полного пересчета итогов по этому регистру размер уменьшился с 9 до 6 Гб.

Какие-то чудеса.

Как может таблица итогов ПУСТОГО регистра занимать 6 Гб ?

"Смотрю по идентификатору.

РегистрНакопления.ТоварыВПроизводстве.Остатки" // Покажи на картинке

(41) Что именно показать ?

В скуле вижу

_AccumRgT9043
размер 9 Гб

В структуре таблиц базы 1С вижу

AccumRgT9393    РегистрНакопления.ТоварыВПроизводстве.Остатки    РегистрНакопления.ТоварыВПроизводстве    Итоги

(42) легко
Как удалить "фантомные" записи в таблице итогов средствами 1С

(43) к (40)

(40) скуль сразу не освобождает занятое место. Это примерно как с файлами в винде: при удалении файлов из корзины они не удаляется физически, продолжают "невидимыми" лежать на диске, пока другие данные не запишутся поверх удалённых файлов

(16) "уменьшение эскалаций блокировок"

ты что-то путаешь

(40) "Как может таблица итогов ПУСТОГО регистра занимать 6 Гб ?"
Это особенность работы 1с с итогами. Поскольку для применяемых в 1с СУБД delete в базе значительно более тяжелая операция, чем update, то при полном закрытии регистра в ноль  не происходит удаления комбинации измерения-ресурсы, а она сохраняется в базе с нулевыми значениями ресурсов. И только при полном пересчете итогов эти записи удаляются.

(42) Там, где слово "Остатки" видишь, показать. Нет такой таблицы в БД. А вот "Итоги" - все понятно.

(25) А что мешает развернуть бэкап в 2 файла данных? Никаких проблем с этим нет.

(49) "Никаких проблем с этим нет"

Серьезно ?
И как ты это будешь делать ? Если у тебя бэкап исходной базы сделан из трех файлов.
У меня сейчас два файла данных. Во втором файле 20 Гб данных. Куда ты будешь восстанавливать эти данные при восстановлении бэкапа ?

(48)     СтруктураБД = ПолучитьСтруктуруХраненияБазыДанных();

AccumRg9376    РегистрНакопления.ТоварыВПроизводстве            РегистрНакопления.ТоварыВПроизводстве    Основная
AccumRgT9393    РегистрНакопления.ТоварыВПроизводстве.Остатки    РегистрНакопления.ТоварыВПроизводстве    Итоги

Далее в скуле получаем запросом размеры таблиц.

Видим
AccumRgT9393 размер 9 Гб.

После полного пересчета итогов по регистру РегистрНакопления.ТоварыВПроизводстве размер стал 6 Гб.

Ночью прошел полный бэкап этой базы.

Сейчас смотрю запросом размеры таблиц - _AccumRg9376 и _AccumRgT9393 уже 0. То есть до полного бэкапа после пересчета итогов регистра размер _AccumRgT9393 был 6 Гб, после него стал 0.

(47) "И только при полном пересчете итогов эти записи удаляются"

У меня после полного пересчета итогов по регистру размер таблицы итогов снизился с 9 до 6 Гб.
Нулевым стал только после ночного полного бэкапа.

Сейчас попробую еще раз смоделировать ситуацию - разверну базу из бэкапа, получение размера таблицы итогов, полный пересчет итогов по регистру, получение размера таблицы итогов, полный бэкап, получение размера таблицы итогов.

(43) По твоей ссылке

"кому интересно скрипт для скуля по формированию таблиц для очистки".

Я вижу только формирование списка таблиц. Что дальше с этим списком ты делаешь ?

(48) "Нет такой таблицы в БД".

Серьезно ?

its.1c.eu/db/metod8dev#content:1591:hdoc

Регистры накопления
_AccumRg<n> - таблица движений регистра накопления.
_AccumRgT<n> - таблица итогов регистра накопления, если регистр поддерживает остатки.

(53) Ну на выходе готовый скрипт со всеми таблицами итогов, настроек и истории работы пользователя. Далее запускаю полученный скрипт и он очищает эти таблицы

(50) Скриптом без проблем. Хоть 100 файлов. Через ГУИ не пробовал, но, скорее всего, оно вообще автоматом развернет.

(56) Не развернет.

У тебя через ГУИ диалог где нужно указать куда три файла исходной базы восстанавливать (два файла данных и файл лога).

И если у тебя два файла в базе приемнике и три файла в базе источнике то как ты это будешь делать ? Там нет варианта "разверни два файла данных исходной базы в один файл приемника".

+(56) Типа так:


RESTORE DATABASE AdventureWorks2012
    FROM AdventureWorksBackups
    WITH NORECOVERY,
      MOVE 'AdventureWorks2012_Data' TO
'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data\NewAdvWorks.mdf',
      MOVE 'AdventureWorks2012_Log'
TO 'C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Data\NewAdvWorks.ldf';
RESTORE LOG AdventureWorks2012
    FROM AdventureWorksBackups
    WITH RECOVERY;


Инструкций MOVE может быть сколько угодно.

(57) Что мешает создать нужное количество файлов в приемнике?

(55)
Смотри что получается

USE [МояБаза]
GO
SELECT 'TRUNCATE TABLE ' + name+';' FROM sys.tables WHERE name like '_AccumRgT%'


После выполнения я получаю сообщения

TRUNCATE TABLE _AccumRgT9181;

Проверяем что получилось.

USE [МояБаза]
GO
SELECT * FROM _AccumRgT9181

И видим что все записи присутствуют (в колонке _Period записи со сдвигом 2000 от 4014-02-01 по 4020-04-01)

(58) "Типа так"

У тебя в источнике ТРИ файла а в приемнике ДВА.

Avto_Data_01
Avto_Data_02

Avto_log

Ты утверждаешь что можно эти три файла восстановить в два. Если это это так то покажи как.

"Что мешает создать нужное количество файлов в приемнике".

Ничего не мешает.
Мало того - это единственный способ восстановить базу данных.

(59) у тебя получился список из TRUNCATE TABLE
TRUNCATE TABLE _AccumRgT9181;
...

Далее просто берешь и вставляешь этот список опять в консоль запросов
USE [МояБаза]
GO
TRUNCATE TABLE _AccumRgT9181;
...

TRUNCATE TABLE - это удаление всех строк таблиц. А что бы руками не прописываеть все имена таблиц итогов, скрипт как раз и генерирует эту команду со всеми именами таблиц

Вот после TRUNCATE TABLE у тебя будут действенно пустые таблички

(60) Ну и в чем проблема? Создал 3 пустых файла, развернул бэкап. Затем уже удалил ненужный файл.

(51) (54) Покажи на картинке, где будет видно "РегистрНакопления.ТоварыВПроизводстве.Остатки"

(63) "Ну и в чем проблема"

Проблема в том что ты утверждал что можно развернуть источник у которого два файла данных (Avto_Data_01 Avto_Data_02) в приемник у которого один файл данных (Avto_Data_01).

А это сделать нельзя.

(65) Прочитай еще раз мои ответы и найди, где я утверждал, что 2 файла можно развернуть в 1. Читать советую начинать с (25), чтобы не протупить еще раз. Нет никаких проблем сделать "копию базы с такой же структурой (два файла данных и один файл лога)". Достаточно создать пустую базу с необходимым количеством файлов и развернуть в нее бэкап. Если поискать - думаю, даже можно найти скрипт, который все сделает автоматически.

Если организация закрывается, напиши скрипт который удалит все движения этой организации из базы.

(67) "напиши скрипт который удалит все движения этой организации из базы"

Движения удалить достаточно быстро.
Проблема была удалить документы поскольку как только количество помеченных документов переваливает за 100 тысяч 1С (точнее скуль) умирает на поиске ссылок по этим объектам.

(66) "Достаточно создать пустую базу с необходимым количеством файлов и развернуть в нее бэкап".

Значит я тебя не так понял.
Развернуть базу источник с тремя файлами в базу приемник с тремя файлами проблем нет.

Я думал ты знаешь способ как развернуть базу источник с тремя файлами в базу приемник с двумя файлами.