gifts2017

Свертывание объемной базы средствами SQL

Опубликовал Валерий Федоров (barelpro) в раздел Обработки - Свертка базы

Свертывание объемной базы средствами SQL

Каждый настоящий 1С-внедренец хотя бы раз в жизни свертывал большую базу. Например, требуется мягко перейти с УПП 1.2 на 1.3, а вес базы за 100Gb. Казалось бы, зачем уничтожать историю? Без истории нет будущего! Но не в этот раз. По плану проекта надо было снести старый функционал управленческого учета и создать новый, параллельно перейти на новый план счетов, а так же с партионного учета перейти на расширенную аналитику. Архитектура новой базы, как водится, будет понятна ближе к запуску в продуктив. Времени жалко, поэтому идем в ускоренном режиме по стандартным фазам "обследование-моделирование-разработка", но методом набегающей волны. Кто плавал, тот знает. Ну не суть. В общем, вырисовывалось два варианта перехода:

 

  • пишем правила конвертации и переносим остатки и справочники в новую пустую базу, пока не закроется прошлый год в старой базе (а ля БП1.6->2.0)

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

Ничтоже сумняшеся выбрали второй вариант, т.к. посчитали его менее трудозатратным. Кроме того, что-то подсказывало, что данные прошлого периода в новой базе могут еще понадобится, со всеми своими «особенностями и уникальностями». Ну а соблазн у продвинутых пользователей свалить свои «особенности» на нашу конвертацию всегда велик, так зачем дразнить гусей?

Первое понимание, что базу надо срочно сворачивать хотя бы на начало текущего года пришло после реструктуризации конфигурации, на которую ушло 8 часов. Разработка конечно велась в компактных локальных базах, подключенных к хранилищу, но тестирование и демонстрацию контрольных примеров заказчик справедливо потребовал проводить в копии базы, наполненной живыми данными. Выходит и учебную базу придется обновлять в течение дня, т.е. оперативно, и в будущем в промышленной эксплуатации рабочую точно так же придется обновлять с кратковременным выходом всех 250 пользователей. А на динамическое обновление лучше не надеется, особенно более одного раза между монопольными режимами. В общем приступаем к свертке.

Для свертки естественно будем использовать стандартную методику 1С – обработка СверткаБазы.epf с ИТС. Последовательность действий в ней такая:

 

  1. на закладке «Общие настройки» устанавливаем дату свертки, например 31.12.2012 23:59:59. Именно на этот момент времени на последнем этапе обработки останутся два вида документов со свернутыми остатками: «Корректировка записей регистров» (КЗР) для регистров накопления и сведений, и «ОперацияБух» (ОБ) для бухгалтерских регистров.

  2. на закладке «Настройка способа свертки» выбираем какие регистры будем сворачивать. Бухгалтерские регистры точно все, а вот про накопления и сведений – внимательно читаем инструкцию к обработке и исключаем лишние. Документы устанавливаем все.

  3. на закладке «Документы ввода остатков» нажимаем «Сформировать». После этого достаточно быстро будут созданы документы КЗР и ОБ, но на 01.01.2013 00:00:00 с выключенной активностью регистров. Причем в свертку не попадают оборотные регистры накопления и непериодические регистры сведений.

  4. нажимаем кнопку «Свернуть базу». Запускается длительный процесс удаления записей выбранных регистров до момента 31.12.2012 23:59:59 включительно. Выбранные оборотные регистры накопления тоже будут удалены. Останутся нетронутыми только непериодические регистры сведений. При этом отключается использование итогов регистров для ускорения процесса. При удачном завершении этого этапа использование итогов включается обратно. Но если этого не произошло по причине остановки по ошибке, вам нужно сделать это вручную. Если на этапе 2 выбран хотя бы один документ, то после удаления записей регистров будет предпринята попытка пометить на удаление документы, не содержащие ни одного движения.

  5. на закладке «Документы ввода остатков» нажимаем кнопку «Активизировать». Все созданные документы КЗР и ОБ будут перенесены на дату 31.12.2012 23:59:59 и включена активность регистров.

От себя к этому добавлю:  надо обязательно убедиться, что документ КЗР является регистратором для всех регистров. Например, у типовой конфигурации УАТ для своих регистров есть свой КЗР с именем «уатКорректировкаЗаписейРегистров», и если вы имеете объединенную конфигурацию УПП+УАТ, то мой совет будет нелишним.

Скоро сказка сказывается, да нескоро 4 пункт делается. Через два часа работы 4 пункта я осознал, что удаление одних только регистров будет идти неделю. А потом еще удаление документов примерно столько же. В таких случаях советую применять принцип «Бритва Оккама» - делай только то, что нужно для достижения главной цели. А моя главная цель – минимизировать время реструктуризации базы. При этом размер базы и количество оставшихся объектов – побочный эффект главной цели, но именно с него мы и начнем.

Для начала узнаем, какие 20% таблиц вносят 80% вклада в размер базы. Именно с ними и будем работать в первую очередь. Для этого используем стандартный скрипт на TSQL:

set nocount on

if exists(select name from tempdb..sysobjects where name='##tmp')

drop table ##tmp

create table ##tmp(nam varchar(50), rows int, res varchar(15),data varchar(15),ind_sze varchar(15),unsed varchar(15))

go

declare @tblname varchar(50)

declare tblname CURSOR for select name from sysobjects where xtype='U'

open tblname

Fetch next from tblname into @tblname

WHILE @@FETCH_STATUS = 0

BEGIN

insert into ##tmp

exec sp_spaceused @tblname

  FETCH NEXT FROM tblname INTO @tblname

END

CLOSE tblname

deallocate tblname

go

select nam Table_Name,rows Total_Rows,res Total_Table_Size,data Data_size,ind_sze Index_Size,unsed Unused_Space from ##tmp

order by Total_Rows desc

drop table ##tmp

Результат будет интересный, но нечитабельный. Я сделал простенький отчетик, в котором сопоставил названия таблиц SQL и объектов метаданных. И вставил его в обработку СверткаБазы.epf на закладке «Доп. возможности» кнопка «Размеры таблиц». Надо только правильно задать имя SQL-сервера, имя SQL-базы, и логин-пароль SQL-сервера. Получилось примерно следующее (фрагмент):

               
               

ИмяТаблицыХранения

Назначение

Метаданные

Total_Rows

Total_Table_Size, KB

Data_Size, KB

Index_Size, KB

Unused_space, KB

_AccumRgT19952

Итоги

РегистрНакопленияезавершенноеПроизводство

8 623 004

2 761 240

1 499 656

1 261 432

152

_AccumRgT19699

Итоги

РегистрНакопленияДСПартииТоваров

1 304 981

1 584 640

360 008

1 224 272

360

_InfoRg17813

Основная

РегистрСведенийписанныеТовары

553 823

1 020 968

894 144

126 408

416

_Document492

Основная

ДокументегламентированныйОтчет

803

834 504

833 536

760

208

_Document559_VT14882

ТабличнаяЧасть

Документ._ПрочиеЗатратыСпискомабличнаяЧасть.Затраты

1 333 145

823 432

820 400

2 976

56

_AccumRgT43095

Итоги

РегистрНакоплениявободныеОстатки

3 371 952

800 800

451 088

349 648

64

_InfoRg17190

Основная

РегистрСведенийраваДоступаПользователейКОбъектам

1 692 429

798 824

211 560

587 112

152

_AccumRgT18765

Итоги

РегистрНакоплениянутренниеЗаказы

2 952 384

784 928

414 376

370 464

88

_Document564_VT15065

ТабличнаяЧасть

Документ._НастройкаРегламентированногоОтчетаабличнаяЧасть.Настройки

348 817

781 536

780 744

728

64

_AccumRgT20021

Итоги

РегистрНакопленияезавершенноеПроизводствоНалоговыйУчет

1 201 744

777 432

300 440

476 824

168

_AccumRgT20161

Итоги

РегистрНакопленияартииТоваровНаСкладах

1 634 649

621 728

328 648

292 992

88

_AccumRgT20190

Итоги

РегистрНакопленияартииТоваровНаСкладахБухгалтерскийУчет

1 578 791

597 584

315 760

281 768

56

_AccumRgT20742

Итоги

РегистрНакопленияоварыВРезервеНаСкладах

1 680 884

567 816

210 176

357 424

216

_InfoRg15891

Основная

РегистрСведенийдресныйКлассификатор

1 023 892

550 216

132 064

417 664

488

 

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

Допустим, вы выбрали 20% таблиц для свертки. Но временной показатель работы 4 пункта не сильно изменился. Ну что же, раз уж мы взялись за прямые запросы к SQL, то не будем себя ни в чем ограничивать. Будем удалять записи в таблицах средствами SQL.

Disclaimer: кто-то упрекнет меня, что я якобы нарушаю лицензионное соглашение с 1С, нельзя мол вторгаться в базу 1С «неродными» инструментами. Специально для таких людей скажу: это демонстрационный пример, ни в коем случае не пытайтесь повторить его на рабочих базах ваших заказчиков, и вообще лучше дальше не читать от греха подальше! А для тех, кто умеет считать свое время и деньги, продолжим.

Как быстро удалить 50млн записей в таблице регистра? С регистрами сведений и накоплений все просто – достаточно удалить записи в основной таблице типа _AccumRg  или_InfoRg с отбором по полю _Period и после этого пересчитать итоги. В регистрах бухгалтерии кроме основной таблицы _AccRg надо еще почистить таблицу ЗначенияСубконто _AccRgED.

Теперь какой выбрать метод TSQL? Метод DELETE не подходит. Он медленный, потому что один из главных его недостатков – неотключаемое разрастание журнала транзакций, даже если у базы параметр Recovery model установлен в  Simple.

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

if exists(select name from tempdb..sysobjects where name='##tmp')

drop table ##tmp

select * into ##tmp from _AccRg36504 where _Period >= '40130101 00:00:00'

truncate table _AccRg36504

insert into _AccRg36504 select * from ##tmp

drop table ##tmp

GO

select * into ##tmp from _AccRgED36536 where _Period >= '40130101 00:00:00'

truncate table _AccRgED36536

insert into _AccRgED36536 select * from ##tmp

drop table ##tmp

GO

 

В предлагаемой обработке на закладке «Доп. возможности» по кнопке «Удаление регистров (СкриптSQL)» вы получите текст TSQL-скрипта, который надо запустить в оснастке «Среда SQL Server Management Studio». Почему-то я его не захотел делать из обработки, хотелось контролировать процесс и читать сообщения по ходу его работы. Замеры показали, что такой скрипт по всем регистрам работает несколько десятков минут на базе весом 120Gb. Прибавим сюда пересчет итогов, который я сделал здесь же на кнопке «Пересчет итогов», и у нас получилось сэкономить несколько дней жизни проекта!

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

USE YourDataBaseName

declare @SQL char(200)

DECLARE @TableName char(100)

DECLARE SysCur CURSOR FOR SELECT name FROM sysobjects where type = 'U' and name like '%Chng%'

OPEN SysCur

FETCH NEXT FROM SysCur INTO @TableName

WHILE @@FETCH_STATUS=0 BEGIN

set @SQL = 'truncate table ' + @TableName

execute(@SQL)

FETCH NEXT FROM SysCur INTO @TableName

END

CLOSE SysCur

DEALLOCATE SysCur

 

Разумеется, перед всеми действиями по сворачиванию регистров не забывайте архивировать  базу данных. Мой совет – лучше это делать средствами SQL: Tasks – Back Up. И на закладке Options не забывать устанавливать параметр “Set backup compression”: “Compress backup”. В этом случае размер архива будет почти таким же, как при выгрузке информационной базы в файл *.dt, а скорость в разы выше!

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

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
СверткаБазы от Barelpro
.epf 53,16Kb
14.04.14
123
.epf 2 53,16Kb 123 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Дмитрий Елисеев (w-divin) 08.01.14 16:54
прикольно... оч полезно и познавательно... Можно поподробней про удаление? ибо тема больная очень... база ок 120Гб, работает 24/7, так что монопольный доступ - беда большая...
2. Валерий Федоров (barelpro) 08.01.14 17:12
спасибо! Подробней пока не могу, времени нет. Вкратце концепция:

Типовой механизм платформы "Удаление помеченных объектов" имеет два недостатка: работает очень медленно и требует монопольного режима.

Медленно потому, что:

1. пытается сделать все и сразу для всех объектов. Хотя есть возможность ручного выбора объектов, но ты же не будешь как дятел по одному объекту выбирать каждые пять минут?

2. пытается найти и показать все ссылки на объект (хотя справедливости ради надо отметить: в упр формах есть режим "Полное удаление" - там на это время не тратиться, но опять же сразу для всех объектов)

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

Я сделал свою обработку, в которой пришлось повторить механизм платформы на поиск ссылок. Работает он быстро, примерно секунду уходит на анализ каждого удаляемого объекта. Кроме того, я анализирую документы без проводок (т.е. проводки мы уже удалили, но документ еще не пометили на удаление, экономим время!), значит вероятность, что за 1 секунду пользователи создадут ссылку на такой документ ничтожно мала. Поэтому она работает в разделенном режиме. Как умный пылесос - ходит по квартире и никому не мешая убирает пыль.
3. Дмитрий Елисеев (w-divin) 08.01.14 21:18
да теория как раз понятна... больше интересует практика. я столкнулся с парой проблем:
1) перекрестные ссылки (когда один объект, помеченный на удаление ссылается на другой, тоже помеченный)
2) и из п.1 вылезает геометрическая проверка ссылок.
т.е. если все объекты, которые ссылаются на удаляемый помечены на удаление, то первый можно удалять, но тут входим в рекурсию и зачастую возвращаемся к ссылкам на первый объект где-то на 3-9 уровнях (((
4. Валерий Федоров (barelpro) 08.01.14 21:28
Да, я тоже думал про рекурсию. Но я с ней пока не стал заморачиваться, т.к. моя задача - удалить документы и сделать это быстро, значит надо пожертвовать качеством. Такие сложные случаи я просто не удаляю.

В общем я на досуге причешу свою обработку, если удастся добавить туда справочники и решить проблему взаимных ссылок, то выложу статейку с ними.
7. Дмитрий Елисеев (w-divin) 09.01.14 02:27
(6) barelpro, Спасибо - действительно был не в курсе (((

ПыСы. переклацал все на сайте - но так и не нашел где можно пополнить руб. кошелек ((( В разделе кошелек только состояние, транзакции - только история, вывод есть, а ввода нету (((
8. Максим Биенко (Bienko) 09.01.14 10:54
(1) w-divin, на ИТС есть специальная обработка для удаления помеченных объектов. Она позволяет без проблем удалять в и без монопольного режима...
Новиков; +1 Ответить 3
9. Алексей Новиков (Новиков) 09.01.14 11:05
(8) Bienko, верно.

Хотелось бы услышать мнение автора по этому поводу :)
10. Валерий Федоров (barelpro) 09.01.14 15:46
О да, есть такая обработка УдалениеПомеченныхОбъектов.epf (или DeleteMarkedObjects). :)

Но вы видимо не пробовали ее запускать в базе от 100Gb и с количеством помеченных объектом несколько десятков тысяч.
Недостатки у нее те же, что встроенной в платформу (писал выше), кроме возможности удалять в разделенном режиме.

PS. Она использует все тот же ущербный, встроенный в платформу метод ТаблицаСсылок = НайтиПоСсылкам(МассивКУдалению). Именно он работает крайне медленно. Даже если переписать обработку и подсовывать ей объекты по одному, она будет искать все ссылки на объект, на чем тратится безумное количество времени. Я этот метод переписал по своему. Я готов выложить свою обработку хоть сейчас, но хочется красиво написать. Поэтому ждите статейку :)
11. Дмитрий Елисеев (w-divin) 09.01.14 17:28
(8) Bienko, не успел отписать... выше уже все сказали по этому поводу...

(10) по свертке: пробовать тока начал - пока поразворачивал тестовые базы, то да се... первые грабли.
select * into ##tmp from _InfoRg3091 where _Period >= '4010-10-31 00:00:00'
у меня не отработало:
Сообщение 242, уровень 16, состояние 3, строка 3
Преобразование типа данных varchar в тип данных datetime привело к выходу значения за пределы диапазона.
Выполнение данной инструкции было прервано


переписал на
select * into ##tmp from _InfoRg8680 where _Period >= '40101031'
смотрю дальше...
12. Валерий Федоров (barelpro) 09.01.14 17:35
(11) w-divin, а что за версия SQL? Я пробовал на 2008. На более древних такой сюрприз возможен.
13. Дмитрий Елисеев (w-divin) 09.01.14 17:58
14. Дмитрий Елисеев (w-divin) 09.01.14 17:59
Надо будет на 2012 еще потестить - а то собираемся перелазить на 12 скуль...
15. Nathan Rothschild (Rothschild) 09.01.14 18:10

Остается только TRUNCATE. Он мгновенно очищает все содержимое таблицы

я бы не стал утверждать так категорично!

Как то раз мы попробовали таким образом "зачисить" в тестовой базе
один кривой "распухший" регистр сведений.
***
в этом регистре одни франчи вздумали в строковый ресурс неограниченной длины
записывать некоторое строковое представление объектов довольно большого размера.
(могли вы для этого ХранилищеЗначения использовать - придурки!)
***
так вот руль скуля завис капитально - и пришлось его ... убить
16. Дмитрий Елисеев (w-divin) 09.01.14 19:15
17. Дмитрий Елисеев (w-divin) 09.01.14 19:29
(8) Bienko, и да, чуть не забыл - еще в платформе есть обалденная вещь - непосредственное удаление - оно тоже работает без монопольного режима )))
18. Дмитрий Елисеев (w-divin) 09.01.14 19:32
По теме - в процедуре пересчета итогов не хватает индикации прогресса пересчета - как во всех остальных действиях )))
19. Валерий Федоров (barelpro) 09.01.14 19:50
(11) w-divin,

нда, согласен, мой косяк. Надо было дату представлять в каноническом виде 'YYYYMMDD HH:MM:SS'. Его скуль понимает при любой языковой раскладке. Вот статья: http://www.sql.ru/faq/faq_topic.aspx?fid=109

Сегодня исправлю и перезалью обработку
20. Станислав Патырило (wondermaker) 10.01.14 05:02
(10) barelpro, я для такого дела немного "допилил" эту обработку и там можно задать порциями объекты по типу - если знаю, что элементы номенклатуры не используются нигде - выбираю для удаления только ном-ру, или сначала чистим документы реализации, затем поступления, потом заказы и т.д.

У нас база колеблется в пределах 100-120GB (УТ 10.3 доработанная, по опыту работы с УПП не думаю, что они очень сильно отличаются) и особых проблем при удалении нескольких тысяч элементов не наблюдалось.

Может у вас проблемы с настройкой SQL?

Когда пробно проводили свертку базы в 120 GB (бух-рия говорит, мол, 5 лет не прошло, ждем, потому и не свернули рабочую), то чисто технически управились в районе 36-40 часов - создание документов остатков, удаление старых движений.
И у нас регистры по размеру были побольше - за гигабайт перевалило с два десятка таблиц SQL.

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

Всё же, не так велика база, чтобы из-за этого "бриться опасной бритвой", при наличии в продаже "станков для бритья".

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

P.P.S. По поводу РН "НезавершенноеПроизводство" и "НДСПартииТоваров" - если я не ошибаюсь, они должны "закрываться в ноль" при правильных движениях. Может причина роста этих регистров в некорректных движениях?
Год назад мы навели порядок с одним похожим регистром - совершенно некорректные движения (для платформы) проходили. Для пользователей всё хорошо - отчет сворачивает движения и остатки до требуемых измерений, а вот внутри было примерно так
И1 - И2 - (+1)
И1 - NULL - (-1)
т.е. один документ делал "приход" с указанием двух измерений, а второй делал расход с указанием одного, а это приводит к тому, что итоги по регистру растут - и первая и вторая строка тянут свой остаток, который переносится на следующий месяц.
После наведения порядка с этим регистром итоги по нему уменьшились с 20 GB до 3-4GB - в пять-шесть раз.

Картина с итогами по правильным регистрам у нас выглядит так - движений по регистру 1-2 миллиона за пять лет работы, а таблица итогов - 7-8 тыс по количеству реальных остатков.
21. Валерий Федоров (barelpro) 10.01.14 09:08
(20) wondermaker,

спасибо за развернутый комментарий!

Мой случай немного другой. УПП 1.2 к нашему приходу была сильно доработана, с натянутым УАТ, УПО и БИТ Финанс. Итоговое количество таблиц - 7800. в УТ 11 из всего 2800. Значит на поиск ссылок или на ту же реструктуризацию уходит больше времени. Количество записей в некоторых таблицах доходило до 50млн (ЗначенияСубконто в Регистре бухгалтерии).
Добавим сюда не очень поворотливый сервер на виртуальной машине и фактор времени (мы подрядная организация на жестко фиксированном договоре), то невольно начинаешь ценить каждый потраченный день на свертку!
Да, в нашей команде присутствовал один из одинесиков-разработчиков УПП. Он так же как и вы был категорически против прямых запросов. IMHO это тонкая религиозная материя. Но в итоге должен побеждать здравый смысл.
22. Дмитрий Елисеев (w-divin) 10.01.14 09:52
(20) wondermaker, типовым конфигурациям - типовые решения... А что делать тем у кого конфигурации ну совсем не типовые? Да, нас мало, но зато мы в тельняжках!

И я не совсем понял Ваше
Ну и мои личные ощущения - не на столько сильно влияет "прямой SQL" на сворачивание, чтобы рисковать базой и отказываться от типовой схемы. Не на много быстрее работает удаление данных командой SQL - проверял на разных базах, на разных серверах (в том числе и почти рабочих станциях временно превращенных в "сервер" с весьма посредственными характеристиками).
Вы обработку-то смотрели? Там прямыми запросами только удаление и сделано...

провести дефрагментацию файлов и таблиц SQL - вот это реально даст эффект.
особенно на SSD )))
24. Alexander Speshilov (speshuric) 10.01.14 10:52
Кратенько критика:
  • На небольших базах в 100 ГБ прямые запросы скорее вредят чем помогают.
  • Не используйте sysobjects, если у вас база не на 2000м SQL. Это прямая рекомендация от MS. Если у вас база на SQL Server 2000, то очень давно пора подумать о миграции на что-то более свежее (2008R2 или 2012).
  • Размер таблиц 1С можно выяснить элегантнее:
    Код
    sel ect 
       t.name as table_name, 
       sum(sz.used_page_count*8) used_size, 
       sum(sz.reserved_page_count*8) reserved_size, 
       max(sz.row_count) row_count
    fr om 
       sys.dm_db_partition_stats sz 
       inner join sys.tables t on t.object_id = sz.object_id
    group by t.name
    order by reserved_size desc
    Показать полностью
    И никаких курсоров и временных таблиц. Тут, правда, учитывается, что в 1С нет ни хранимых представлений, ни секционирования, ни схем отличных от dbo, а размеры индексов и данных суммированы.
  • Не описан переход от 2013 года к 4013, на самом деле есть немало баз где смещение 2000 не используется. Ну и неаккуратное преобразование строк в даты. В скриптах я бы использовал формат "{ts '4013-12-13 00:00:00'}"
  • У truncate/insert есть некоторая сложность, если применять не к регистрам, а к документам или справочникам. В объектных типах есть поле timestamp. Его нельзя просто так взять и вставить, нужно конвертировать.
  • Delete кусочками хоть и медленнее, чем truncate/insert, но тоже применим (и журнал остаётся в предсказуемых пределах)
  • GO не является частью синтаксиса T-SQL и ваши скрипты можно запускать только из SSMS
25. Alexander Speshilov (speshuric) 10.01.14 11:09
странно покорёжился скрипт. Sel ect и fr om, конечно же не должны разрываться пробелами :)
26. Олег Филиппов (comol) 10.01.14 11:56
Только за Truncate Table админ SQL, если таковой имеется, подвесит за... уши. Далее о том что в базе могут быть ошибки, ошибки скрипта с датами и т.п. я думаю не стоит уже говорить... а уж о том что конечно данные надо разделять а не сворачивать я тем более промолчу...
27. Айтуар Баубериков (Bajo) 10.01.14 12:19
Разумеется, перед всеми действиями по сворачиванию регистров не забывайте архивировать базу данных. Мой совет – лучше это делать средствами SQL: Tasks – Back Up. И на закладке Options не забывать устанавливать параметр “Set backup compression”: “Compress backup”. В этом случае размер архива будет почти таким же, как при выгрузке информационной базы в файл *.dt, а скорость в разы выше!


не совсем согласен. у нас база 8 гб. бэкап с компрессией весит 1 гб, а дт-файл 170 мб
28. Валерий Федоров (barelpro) 10.01.14 12:21
(26) comol,

Олег, уважаю твое мнение, но это не голая теория, опробована на реальном проекте. Да риск есть, но кто не рискует, тот не выигрывает! :)
29. Айтуар Баубериков (Bajo) 10.01.14 12:25
иногда лучше сделать "рестарт" учета в новой базе, потому что со временем копится очень много "мусора" как в данных, так и в разработках. но при этом возможны проблемы с битыми ссылками, переносом пользователей, но в интернете полным полно грамотных разработок для решения этих проблем
30. Nathan Rothschild (Rothschild) 10.01.14 12:26
(27) Bajo,
да ... но ходят слухи, что из файла *.dt не всегда удается развернуть базу
:)))
31. Валерий Федоров (barelpro) 10.01.14 12:30
(24) speshuric, спасибо за критику!

Про timestamp знаю, но я и не предлагаю применять insert к ссылочным объектам.

За короткий скрипт определения объемов - спасибо!

Про смещение 2000 - в сервере 1С:8.3 он уже зашит по умолчанию без возможности изменения.

Про GO знаю, но я его и не выполняю через ODBC, моя обработка просто выдает текст скрипта, который надо запустить в SSMS. После каждого GO завершается транзакция и выдается комментарий, за которым я предлагаю наблюдать.

Ну а в целом - приятно поговорить с человеком в теме! ))))
32. Валерий Федоров (barelpro) 10.01.14 12:35
(27) Bajo,

да, SQL жмет не сильно, раз в 5. Но делает он это быстро. А в нашем деле время - деньги!
33. Дмитрий Елисеев (w-divin) 10.01.14 14:35
(30) Rothschild, а иногда удается развернуть битую )))
(27) и почему разработчики БСП и типовых конфигураций при попытке сделать бекап клиент-серверной базы пишут "пользуйтесь средствами СУБД"? они наверное не в теме (((
34. Юрий Осипов (yuraos) 10.01.14 18:31
(25) speshuric,
да - есть такой косяк в движке сайта

...
хоть по 1с -ному пиши:
ВЫБРАТЬ *** 
ИЗ ***
Rothschild; +1 Ответить
35. Александр Дуденков (haggart) 13.01.14 15:17
Первый вопрос. Хоть у кого-то получилось из тех кто скачал?
Второй вопрос. После того как Recovery model установлен в Simple и базу свернули, опять можно возвращаться к предыдущему варианту Recovery model? Но тогда будут ли работать Tasks?
36. Валерий Федоров (barelpro) 13.01.14 23:41
(35) haggart,

а что конкретно не получилось?
37. Алекс Одинэсник (Alex1Cnic) 14.01.14 08:30
А картинка то в тему!!! :-)
38. Антон Щекачев (ASchekachev) 14.01.14 15:09
39. Валерий Федоров (barelpro) 14.01.14 18:58
Антон, спасибо, это альтернативный способ вычисления размеров таблиц через запрос к sysobjects
а у меня используется хранимая процедура sp_spaceused

преимущество моего метода в том, что я кроме Total_Rows, Data_Size и Index_Size вижу еще и Unused_space и полный размер Total_Table_Size
Прикрепленные файлы:
БИТ_АнализТаблицБазыДанныхSQL.erf
40. Вадим Никонов (V.Nikonov) 23.01.14 09:47
Лично у меня несколько другой подход к выбору приоритетов по зачистке Регистров. Предпочитаю ориентироваться не столько на размер таблиц (Записей, Занимаемое место), сколько на ключевой характер остатков (влияние на логику оперативного проведения). В частности есть большое количество регистров носящих вспомогательный характер (для ускорения отчетов), а часть регистров влияет на логику поведения. Соответственно Регистры отвечающие за Взаиморасчеты, Товарные остатки, Резервы и некоторые другие надо зачищать в первую очередь.

После зачистки Ключевых регистров можно даже пользователей в программу пускать продолжая зачистку штатными средствами. При этом работоспособность (кроме отдельных видов отчетов) будет полная, хотя и будет наблюдаться увеличенная нагрузка на Сервера (сниженная производительность оперативного потока).
Збянтэжаны Саўка; +1 Ответить
41. Osiris_ (StaticUnsafe) 31.01.14 10:24
42. Валерий Федоров (barelpro) 25.02.14 13:31
на фото та самая матчасть, которую надо курить )
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа