SQL. Опять переезд баз 1С

13.03.23

Автоматизируем переезд файлов баз данных 1С внутри SQL сервера с диска на диск средствами SQL.

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование		По подписке [?]	Купить один файл
Сказать "Спасибо" & скачать скрипт .sql 2,47Kb 2	2	Скачать (1 SM)	Купить за 1 850 руб.

Админы сообщили радостную весть - "Закуплены диски для модернизации дисковой системы SQL сервера, переносите все базы на один диск".

Прошлый переезд SQL баз был устроен с помощью симбиоза 1С + SQL скрипты. На этот раз задача звучала немного иначе, и трогать кластер 1С не было надобности.

Требовалось все базы 1С расположенные на диске G перенести на диск D, к имеющимся 120 шт, чтобы потом Админы модернизировали дисковую систему SQL сервера и мы завершили задуманное - разделить файлы баз данных и логов по разным физическим дискам.

Смотрим на папку диска G - итить-колотить, 139 баз 1С переносить на другой диск. "Сто тридцать девять, Карл!" Руками ? Да ну на...

Беремся за изучение команд SQL скрипта, тем более что "Секлет * фром оттуда" нам уже знакомо, этож почти язык запросов в нашей родной 1С.

Вопщем, как говорится в одном древнем мультфильме "Лучше день потерять, потом за 5 минут долететь", пишем SQL скрипт и переносим все 139 баз одним кликом. Ну не нажимать же 139 раз Отсоединить\Присоединить базу, тем более что еще и надо угадать какую переносить, а какая уже на диске D.

Скрипт для переноса баз c диска G:\SQL\ в папку на диск D:\SQL_Base\

SQL cкрипт

DECLARE @Database NVARCHAR(255)   
DECLARE @DBName NVARCHAR(255) 
DECLARE @DBLogName NVARCHAR(255)
DECLARE @SQLString NVARCHAR(4000)
DECLARE @NewDBName NVARCHAR(255) 
DECLARE @NewLogName NVARCHAR(255)


SELECT 
B_Name.database_id,
Case 
	When B_Name.type = 0  Then B_Name.physical_name
End as DBase,
Case 
	When t_name.type = 1  Then t_Name.physical_name
End as LogBase  
INTO #work_Base
from master.sys.master_files as B_Name 

left join
  master.sys.master_files as t_Name 
	on B_Name.database_id = t_Name.database_id
Where B_Name.database_id >4 and B_Name.state = 0 
and B_Name.physical_name like 'G:\SQL\%' and B_Name.type = 0 and t_Name.type = 1


-- Отберем базы для выполнения операций
DECLARE DatabaseCursor CURSOR  FOR  
(
SELECT 
	t_Name.name as DatabaseName,
	--t_Name.database_id as database_id,
	Se.DBase,
	Se.LogBase
 
 FROM master.sys.databases  as t_Name 
  Right join   
  #work_Base as SE on t_Name.database_id = SE.database_id 
  WHERE t_Name.database_id > 4
  AND t_Name.state = 0 
)
-- Цикл по всем базам, попавшим в выборку
OPEN DatabaseCursor  
FETCH NEXT FROM DatabaseCursor INTO @Database, @DBName, @DBLogName    
WHILE @@FETCH_STATUS = 0  
BEGIN
   BEGIN TRY   
 
		SET @SQLString = 'USE [master]; ALTER DATABASE [' + @Database + '] SET  SINGLE_USER WITH ROLLBACK IMMEDIATE; USE [master]; EXEC master.dbo.sp_detach_db @dbname = N''' + @Database + ''';'     
		--PRINT @SQLString
		Exec (@SQLString)

		Set @NewDBName = 'D:\SQL_Base\' + @Database + '.mdf'
		Set @NewLogName = 'D:\SQL_Base\' + @Database + '_log.ldf'

		--Копируем Базу данных
		SET @SQLString = 'copy '+ @DBName +' '+@NewDBName
		--PRINT @SQLString
		Exec xp_cmdshell @SQLString
		--Копируем Лог базы
		SET @SQLString = 'copy '+ @DBLogName +' '+@NewLogName
		--PRINT @SQLString
		Exec xp_cmdshell @SQLString			


	 
		SET @SQLString = 'USE [master]; CREATE DATABASE [' + @Database + '] ON ( FILENAME = N'''+@NewDBName+''' ),( FILENAME = N'''+@NewLogName+''' ) FOR ATTACH '
		--PRINT @SQLString
		Exec (@SQLString)

		PRINT 'База ' + @Database +' успешно перенесена' 
      END TRY
      BEGIN CATCH
	 
      PRINT '---'
         PRINT @SQLString
         PRINT ERROR_MESSAGE() 
         PRINT '---'
	-- Удаление временной таблицы
		DROP TABLE #work_Base;
      END CATCH

   FETCH NEXT FROM DatabaseCursor INTO @Database,@DBName, @DBLogName   
END  
CLOSE DatabaseCursor   
DEALLOCATE DatabaseCursor


  -- Удаление временной таблицы
DROP TABLE #work_Base;
GO

+9 –

См. также

Исправление ошибки "В расширении конфигурации используются возможности, недоступные в выбранном режиме совместимости"

Администрирование СУБД Системный администратор Программист Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Бесплатно (free)

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

21.02.2025 1183 Marat1c8 2

Адаптивное обновление индексов MS SQL

Администрирование СУБД Системный администратор Абонемент ($m)

Всегда надо обслуживать индексы SQL. В том числе по рекомендации самой 1С. Но обслуживать все и сразу - долго, тяжело серверу и, главное, бессмысленно. Особенно для больших баз. Данный скрипт выбирает, что надо делать, и делает это автоматически. Готового полного аналога не нашел, поэтому сделал этот. Можно примерять для любых конфигураций и платформ 1С. Проверено на 8.3.25.1501.

10 стартмани

12.02.2025 566 3 GreyCardinal 14

Мастер-класс: нагрузочный тест на 3 тыс. пользователей на PostgreSQL

HighLoad оптимизация Администрирование СУБД Программист Платформа 1С v8.3 Бесплатно (free)

В рамках мастер-класса мы запустим нагрузочный тест на 3К пользователей и посмотрим, как будет вести себя PostgreSQL при такой нагрузке.

11.12.2024 1883 Tantor 1

Как при запуске приложения определить его Идентификатор

Администрирование СУБД Программист Платформа 1С v8.3 1C:Бухгалтерия Россия Бесплатно (free)

Много вариантов определения номера собственного процесса самого 1С8. В ходе поиска, опираясь на общедоступную информацию, дополнил алгоритм, но с учетом определения ИД запущенного приложения.

09.12.2024 888 artly2000 6

Как выжить разработке, когда прод переезжает на PostgreSQL

Администрирование СУБД Системный администратор Программист

В крупных компаниях, где много типовых и сильно доработанных баз с режимом работы 24/7, переход с MS SQL на PostgreSQL затягивается. Получается гетерогенная структура – когда прод уже на PostgreSQL, а разработка и тестирование – пока на MS SQL. О том, какие варианты помогут постепенно перевести прод с несколькими базами MS SQL на PostgreSQL, не сломав среду тестирования и разработки, пойдет речь в статье.

21.11.2024 4252 a.doroshkevich 9

Решение проблемы Values в Postgres

HighLoad оптимизация Администрирование СУБД Системный администратор Программист Платформа 1С v8.3 Россия Бесплатно (free)

Мы исследуем проблему долгого выполнения запросов PostgreSQL при использовании конструкции VALUES: когда она возникает, как на нее можно повлиять, а главное, почему ее продуманная отработка важна для более быстрого функционирования решений на базе 1С

12.11.2024 1660 Tantor 20

Временные таблицы и SELECT FASTTRUNCATE

HighLoad оптимизация Администрирование СУБД Механизмы платформы 1С Программист Платформа 1С v8.3 ИТ-компания Россия Бесплатно (free)

В данной статье мы рассмотрим, как работает механизм временных таблиц на postgres на платформе 8.3.23 и что изменилось в нем при добавлении новых возможностей в платформе 8.3.25. А также на примере покажу, как понимание работы платформы позволяет оптимизировать СУБД для работы с 1С.

29.10.2024 5376 Tantor 38

PostgreSQL CDC c помощью Debezium и Kafka (Часть 1)

Администрирование СУБД Системный администратор Программист Бесплатно (free)

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

08.10.2024 1938 AlexSvoykin 2

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. tchee 20 14.03.23 13:21 Сейчас в теме

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

2. VPanin56 568 14.03.23 14:01 Сейчас в теме

Мои 139 баз весили 450 Гб в сумме, у нас в основном типовушки БП и ЗУП.
И самая большая база весит около 12-14 Гб.

Регламент обслуживания это моя давнишняя боль. 250 баз перестроить индексы и обновить статистику типовыми механизмами обслуживания SQL не может. Дефрагментация индексов из построителя длилась 2-3 суток и была прибита, т.к. начала тормозить сервак в понедельник утром.
В ходе изучения материалов по этой теме нашел пару публикаций интересных скриптов и подхода к этому вопросу, написал (из двух один ) нужный мне по алгоритму SQL скрипт и разделил на 3 потока все базы по выполнению перестроения индексов , теперь успевают раз в неделю за ночь перестроить индексы сильно дефрагментированные и обновить статистику.
По личным наблюдениям\ощущениям ( без замеров) как будто немного поживее стали работать базы.

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