На небольших базах операции ТиИ не вызывают сложностей с выполнением. Но вот на больших базах весом порядка 70 гиг (база sql) время выгрузки может занять 7 часов загрузки и того больше все 12.
Время которое база может находится в офлайне с 21 до 9, а это максимум 12 часов. Возникает резонный вопрос как же ее обслуживать?

(0) Копирую базу (средствами SQL); делаю ТиИ на копии -> сколько времени это занимает волнует только меня одного. Если ТиИ выявило проблемы - есть повод на рабочей базе проверить и устранить.

(39) Да не фига. Это зависит от СУБД. Вы какую субд используете?
(40) (41) Вот вы сначала ответьте на вопрос выгрузку/загрузку вообще для каких целей предлагаете делаеть средствами СУБД?
(42) Это все понятно. я так же делаю. Вопрос в том что на рабочей этого не получится сделать. даже при необходимости.

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

А вот выгрузка/загрузка, тестирование - зачем?

(43) sql 2008 r2

(0) Начать с того что если база 70 гиг то что то в ней неладно ))

Как минимум надо делить базу (свертка старых данных) на актуальную и архивную

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

Регламентные задания по индексации и пересчетам итогов не помогают?

(0) Работать ночью не предлагали? :)

(47) дык база сильно большая - в таймаут не укладывается ))

(49)ТС подробных характеристик базы не привёл. Может быть, он и не пытался

у меня на базу в 25 гиг уходит максимум 4 часа

(46) >>  если база 70 гиг то что то в ней неладно ))

Бред какой. И как же люди живут с базами размером 1Тб и более?

>> Как минимум надо делить базу (свертка старых данных) на актуальную и архивную

Зачем? В чём сокральный смысл сего действа? Единственными реальными причинами свёртки базы могут быть чисто административные:
а) желания спрятать данные старых периодов (от налоговой, от хозяв фирмы или еще от кого-то)
б) учет ведётся по слишком большому объему аналитики, которая постоянно меняется. Например, номенклатура постоянно сильно обновляетя причем так, что старая никогда не используется, или такая же фигня с контрагентами. В результате получаем огромные справочники, в каждом из которых в повседневной работе используется только малое количество элементов. Но подобные задачи часто решают обработками по переносу и замене старых данных на какой-нибудь служебный элемент того же справочника.
в) В базе сильно накосячили (например, неверно изначально организовав учет) и хотят нормализовать сами данные и привести в порядок учет.

Всё остальное - ИМХО, от лукавого.

>> Причем можно сделать что отчеты в актуальной базе используют по факту данные из архивной...
Мусье знает толк в извращениях. Работа ради работы - наше фсё. Зато какой простор для профессионального роста и развития навыков по настройке неочевидно работающих мутных интеграций между боевой базой и её архивами. Можно еще потом поразвлекаться с пользователями, когда они вдруг решат попереименовывать нескольких контрагентов или номенклатур, сделав это только в боевой базе.

(49) >>  база сильно большая

70Гб - это большая база?....
Это, ИМХО, вполне себе нормальная база - не маленькая конечно, но и никак не большая.

Сколько юзверей? что в таком количестве может находится в базе?

Так уважаемые коллеги. БОЛЬШАЯ ПРОСЬБА - Читаем внимательнее топик!

1. В таймаут не одна операция не укладывается.

2. Понятие большой и малых баз сильно субъективно. Все тут почему-то думают что раз SQL это обязательно Микрософт. Так вот нет - у меня IBM DB2. Думаю хранения плотность хранения данных в разных субд тоже разная и то что в MS SQL занимает 450 гиг в DB2 может занять только 50. Это раз. Для более объективной оценки размера базы, предлагаю сравнивать размеры dt файлов поскольку на их формат применяемая СУБД ни как не влияет.

Введи на предприятии Санитарный день

(56) дорого - торговая сеть несколько городов и пока в этом нет абсолютной необходимости. надеюсь, что и не появится. думаю есть резон поэкспериментировать мне с мелкомягкими.

(55) На кой черт делать выгрузку загрузку?
Делай проверку логической целостности и ссылочной на копии, если есть ошибки исправляй на рабочей.
Пересчет итогов можно делать без ТИИ.
что еще нужно то?

(55) для более объективной оценки скажите где вы бэкапы храните?

и сколько (кол-во их и срок) храните?

и какой размер бэкапа? сча?

(59) я протелепачу:

автору достался настроеный DB2 и он в него боится лезть, человек который настраивал давно уволился...

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

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

По настоящему большая база - это та в которой регламенты не успеваются делатся средствами субд, у тебе баз для 7.7 большая, а для скуля маленькая...

(58) для реиндексации/компрессии таблиц. Да, все можно сделать без такой фигни, но мож ему вставляет от этого

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

(0)  Идешь к начальству и говоришь: для обслуживания баз мне нужно вот такое количество часов. Если этого не делать - будут вот такие последствия. Начальство озвучивает тебе время. Желательно это время как-то утвердить официально. Например, каждую третью среда месяца - с 00 до 05 проводятся технические работы, утверждаю, подпись ген.дира.

+63 Это касаемо планового обслуживания. Внеплановые - так же через "бумагу". "В связи с производственной необходимостью прошу..." и т.д., согласованная дата/время и подпись "высших богов".

В этой же бумаге можно дописать " в связи с затраченным временем прошу предоставить мне премию/доп.выходной".

(38) +1
на копии определяем нужно ли ТиИ или нет
если нужно то определяем что именно сломалось:
1. битые ссылки - это быстро поправить можно и в рабочей
2. итоги неверные - тоже можно определить какой регистр и в каком периоде слетел - можно штатно поправить переносом ТА в нужный период и обратно - можно нештатно поискать пересчет итогов напрямую в скуле по конкретному регистру
проверить битость регистром можно и без ТиИ - по простой формуле НачОст + Приход - Расход = КонОст - по каждому регистру в разрезе хранения итогов

(62) у меня база в 20 гигов востанавливается их бекапа за 3 минуты, при этом на древнем сервере....

100 гигов востанавливаются не более 15 минут....

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

(67)там наверно в 5 метрах от сервера воздух ионизируется...

(68) Наверное, он индексы куда попало не лепил в базе.

(62) >> свертка базы нужна тогда когда время восстановления из бэкапа переходит границы дозволенного.

И сколько же будет восстанавливаться из бэкапа база 70Гб, чтобы это превышало границы дозволенного?
10 минут вместо 5?....

И каковы границы дозволенного?
Восстановление базы из бекапа - это критичная ситуация. Если до неё дошло, то речь идёт о крушении рабочей базы. А в таком случае важнее правильность восстановления данные, чем скорость.
Вы же не перезаписываете из бекапа боевые (рабочие) базы каждый день?

(55) >> то что в MS SQL занимает 450 гиг в DB2 может занять только 50. Это раз

Не верю. Это раз.
450 Гб - это тоже не смертельный размер. Это два.

>> Для более объективной оценки размера базы, предлагаю сравнивать размеры dt файлов

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

(67) В это время входит копирование базы по сети с сервера архивов и раскрутка из rar, zip или что там еще?

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

(72) в это время входит поднятие скульного бекапа хранявшегося на соседнем сервере.

бекапы средствами 1с разумеется я не расматриваю....

(71) Разумеется что 450 к 50 гиг, но идею думаю Вы поняли. У меня размер dt 5.7 гиг. Если не сложно сделайте выгрузку сравним.

Раз уж заговрили про архивацию/восстановление отмечу, что на этот процесс уходит порядка полутора-двух часов но не как не 15 минут! Разумеется архивация как базы так и журналов выполняется средствами СУБД.

+ под регламентом в (0) подразумеваются операции ТиИ, а не регламенты обслуживания базы предлагаемой СУБД.

(75) мда.... размеры детские, полтора часа - это наверно через конфигуратор?

(77) шутник?)

(78) наверно нет, может просто Ваш сервер по нормальным меркам (характеристики) это как современный смартфон?

(40) > А зачем делать выгрузку средствами 1С?

Для семерки в файл выгрузки попадают и метаданные. Если просто делать сохранение данных из 1С - не попадут таблицы,
если делать только скулем - в бэкапе будут только таблицы, но не будет описания метаданных.

Но мы не знаем, у ТС 1С 8 или 7.

6 гиг дт это маленькая база
70 скуля тоже, даже для 7.7 (лет 7 назад когда сталкивался с 7.7 пустая свежепокромсанная база только с НСИ и остатками 35 весила)

(0) раз в месяц. Суббота + воскресенье. Согласованно с руководством.

(79) Может, а может и нет. Если вкрадце то под СУБД выделена отедльная машина Intel® Core™2 Quad Processor Q9300 , 8 гиг оперативки, win 2003 r2. Сама база крутится на SSD диске. По поводу того какая там память информацией не располагаю, но не думаю, что это слабое место.

(80) Но мы не знаем, у ТС 1С 8 или 7
Не ленитесь обратить внимание на раздел в котором опубликован пост

+ не думаю что сейчас многие еще сидят на костылях

(83) ..

(85) извините, я .. не понимаю. У Вас какое-то конкретное мнение по конфигурации или как?

(86) мнение по "отдельная машина с ssd" в качестве sql сервера

ЗЫ еще вопрос а сам 1С сервер где? и какая сетка у вас (100 или гигабит)

(87) а под сервер 1С еще одна машина. на ней терминалка, а вот с ней по rdp работают пользователи. так что от скорости сетки ничего не зависит.

(88) да ну? а как "сервер субд" соединен с "сервер 1с" ? :)

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

(12) Я в ужасе.
Махровый идиотизм.
Только скулевые бекапы! Какие нахрен dt для скулевой базы? Тем более размером 70 гиг.
Dt нужен только для перехода с файловой на скулевую и наоборот. Только для этого!

(91) да вы сути обсуждения не поняли. не про бакапы мы тут говорим)))

(46) Не мешайся, мальчик :))
У меня клиент был с базой консолидации на 170 гигов и ничего, нормальная база.

(92) Так и я не про бекапы.
Если хочется поиграться с базой — делается копия средствами скуля и играется.
Если нужно сделать что-то из ТиИ — только на копии и потом по логу точечными ударами в рабочей базе.
Если нужно сделать какие-то регламентные операции типа пересчета итогов — только максимально детализированными порциями, а не скопом.

+(94) Вот, товарисч в (66) абсолютно прав :))

так никто на рабочей базе и не экспериментирует. ТОЛЬКО НА КОПИИ. да и копия средствами субд разумеется))

+ а с мнением (66) никто и не спорит!!! вопрос в том, если потребуется ремонт, что тогда? как избежать простоя?

+ так же в ходе дискуссии у меня возникли вопросы если mssql лихо работает с базой в пол гига, быть может стоит ее рассмотреть как альтернативу db2

(0) 70 Гиг - не сказать, что большая база. Средняя, скорее. Ничего особого. Разумеется, работать с базой средствами конфигуратора без конкретных целей (ошибки) не стоит. Проще, имхо, работать через SQL.

(97) Так в (94) написал: "точечными ударами в рабочей базе".

(98) Вообще не вижу ни единого аргумента за db2.

(90) в курсе что у Вас железо не соответствует объемам базы? конечно еще нагрузку надо смотреть

Вообщем на прежней работы достался в наследство db2,выгрузка/загрузка через dt действительно по сравнению с скулем в раза два медленей.Чесно говоря по опыту db2,postgr даже на средних базах еле справляются.

(93)(99) так и мне приходилось работать с большими базами

4 ляма только одного вида доков в год как? со 160+ точек полученных

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

и никаких проблем типа в (0), точнее были легкие в конце года

ЗЫ а "копление" всего в одной базе это похоже на "не выкидывание" старого хлама (мебели, быттехники, книг-журналов и прочего) на помойку или на дачу ))

типа нет все дома храним и ходим по потолку, ну иногда еще новую хату покупаем и туда все перетаскиваем ))

(100) идея понятна. только все ли можно исправить в режиме предприятия, что можно средствами конфигуратора?

(105) Да вроде как все. А что нельзя из необходимого?

хвастаюсь
а у нас базы 2T,  6T ...

(106)
а реиндексация, реструктуризация, упаковка не в счет?
(107) если уж хвастаетесь так предметней пожалуйста. отдельная ли машина под базу какая субд, дисковая подсистема, память ЕСС или нет и т.д.??

(108) Реиндексацию не делаю и прекрасно живу.
Реструктуризация - что это?
Упаковка - шринк в скуле.

(0) "Но вот на больших базах весом порядка 70 гиг (база sql) время выгрузки может занять 7 часов" . А если 700 .. 70 часов ? Вы это серьезно ?

Имея сервер СУБД продолжать забивать гвозди микроскопом...

(109) Честно говоря сам не знаю что под реструктуризацией подразумевают в 1С. А "Shrink" Вы предлагаете напрямую в обход 1С делать?

(112) Не знаю, что это, но надо?
Шринк нельзя делать не в обход 1С, это чисто сиквельное понятие.

(113) Не думаю что ковыряние в базе напрямую является штатой работой с базой 1С мягко говоря.

(114) почитать бы про субд Вам...

что такое журнал/лог транзакций

(107) 1С ? Какие конфигурации?

(112) А у 1С появилась возможность делать шринк собственными средствами?

(117)Сжатие таблиц информационной базы в ТиИ не оно?)

Итак потестил дома базу на mssql 2012. Небольшой отчет:
Время загрузки в базу из dt файла 2.5 часа в сравнении с 10 часами для дб2. Результатом очень доволен.
Размер загруженной базы вышел даже меньше чем у дб2 - 53 гига.
Получилось даже ТиИ выполнить.
Контроль логической, ссылочной целостности выполнялся по частям. Время всей проверки и исправления составило 30 часов. После исправления, повторный прогон занимает только 2.5 часа. Опции исправления были выбраны "Очищать ссылки" и "Удалять объекты". Размер текстовых файлов логов исправлений 1с'ом ошибок в общей сложности составил 1.1 Гб! Таким образом о точечном исправлении такого числа ошибок в режиме предприятия не может быть и речи.
После такого "лечения" пациент усох с 53 до 37 гиг))
Одна ошибка таки осталась неизлечимой -
Проверка логической целостности. РегистрНакопления.ТоварыВПроизводстве :0
    Не определена ссылка
В режиме Удаления помеченных объектов 1С видит только справочники. Документов же помеченных на удаление нет, хотя их море.
Выводы. База конечно сильно кривая, но раборает невзирая на обстоятельства, дб2 хоть и не очень быстрая, но надежная бесплатная СУБД, а ms sql очень удобный и понятный интструмент в настройке и сопровождении но весьма не дешев.

кстати, в дб2 нет чисто сиквельного понятия shrink, есть правда reorg, но это немножко другое.

db2 бесплатная? А IBM Об этом знает?

(121)ну не совсем бесплатная разумеется, у нас бесплатная версия работает

(114) Послушайте, вы условно говоря в Газель загрузили 10 тонн и жалуетесь что плохо едет, вам предлагают варианты, вы говорите, что "не пойдет, этого нет в инструкции".

(122) А что не взять бесплатную же MSSQL?

(124)
http://tavalik.ru/redakcii-ms-sql-server-2012/
http://www.ibm.com/developerworks/ru/library/dm-1204db2expressc/

+ http://efsol.ru/articles/comparison-dbms.html

(119) а на постгресс если опыт провести?

(127) не вижу смысла, а на мс субд есть возможность перехода.

(123) а кто предлагает? не вижу конкретики.

(129) какая конкретика? Вы сходу задаете вопрос: "где в документации 1С это написано?". Понимаю так что недокументированными 1С методами пользоваться не хотите. Я правильно понимаю?

не совсем. скажем так я не очень доверяю недокументированному подходу, но если хорошо сам понимаю, что предлагается, то вариант вполне реален.

(118) Нет не оно. Сжатие таблиц и сжатие файлов базы(шринк) -две большие разницы.

(114) Документированные средства СУБД работы с базой не задумывались для внесения изменений в данные. А 1с из базы получает только их. Отсюда следует, что вы или страдаете паранойей, или таки плохо представляете работу СУБД. Улучшить свои знания в этой области вам уже предлагали.

А говорили уже, что бекапить базу на скуле можно не выгоняя юзеров?

(134) Говорили, в том числе и я.

А что тут писали про 7.7 ? Там же , емнип , нет DB2 , там тока MSSQL.

(133) это все лирика. не вижу конкретики. какие знания вы предлагаете мне улучшить?
(134) вот вы щас наверно думаете, что америку открыли
(136) а, клюшки вообще не в теме.

(137) А какие стратегические цели (может уже спрашивали, тогда не обижайтесь) должны быть достигнуты при выгрузке в формат dt ? Какие вообще данные предполагается отправлять в "архив" и т.п. ?

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

(138) Выгрузку в дт с последующей загрузкой рекомендуется выполнять для устранения ошибок в базе. Это ни коим образом не метод архивации.
Можно подвести некий итог. После исправления мероприятий по устранению проблем в базе время выполнения регламентных операций таких как пересчет итогов занимает 4 часа на DB2, что вполне приемлимо для выполнения во внерабочие часы.

пациент уже объяснил зачем он выгрузку-загрузку делает вместо стандартного ТиИ?