По теме из базы знаний
- Отчет по размерам таблиц в базе данных как одно из средств анализа проблем
- Свернуть базу и не свернуть себе шею
- Технология доработки типовой конфигурации с использованием конфигуратора
- Начните уже использовать хранилище запросов
- Удаление неактуальных цен, валют и версий объектов – УТ 11.5, КА 2.5, ЕРП 2.5
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(5) в (3) вам дали исчерпывающую информацию, такой объем уже и для простого копирования долгоиграющий, я бы рекомендовал произвести шринкование лог файла на самом мощном компьютере в компании в выходные, либо попробовать создать периферийную ИБ что равноценно выгрузке через дт
(1)Если сервер достаточно мощный то можете попробовать использовать сжатие таблиц. Вот описывающая подобный способ уменьшения размера бд.
(3)
Не путайте клиент-серверный режим с файловым.
(3)
3. проведите ТиС базы с опциями "сжатие таблиц информационной базы" и "реструктуризация таблиц информационной базы".
Не путайте клиент-серверный режим с файловым.
(22) На инфостарте есть обработка которая умеет напрямую выполнять SQL-запросы на сервере БД. Пользовался лет 5 назад. В итоге получилось порезать базу 1.3 террабайт в 20 ГБ. Остались справочники, настройки. Перекинул туда остатки и начали учет. Походу дела решали проблемы с остатками так как резали задним числом.
Рекомендуется провести предварительную работу перед урезанием базы:
1. привести в норму остатки по всем блокам учета
2. провести работу со НСИ
3. переносить остатки с помощью обработок с предварительным просмотром загружаемых данных. отдать обработку ответственным лицам и пусть сами загружают и отвечают за данный участок.
Успешно завершено несколько проектов по такому принципу, как срез базы, так и переход на новые системы.
Рекомендуется провести предварительную работу перед урезанием базы:
1. привести в норму остатки по всем блокам учета
2. провести работу со НСИ
3. переносить остатки с помощью обработок с предварительным просмотром загружаемых данных. отдать обработку ответственным лицам и пусть сами загружают и отвечают за данный участок.
Успешно завершено несколько проектов по такому принципу, как срез базы, так и переход на новые системы.
1. модель восстановления БД у вас какая? для автообрезки журнала транзакций можно поставить "простая"
2. начальный размер файлов БД какой выставлен? выставьте для файла БД ваши 65 Гб, прирост по 200 Мб, для журнала можно поставить 50-100 Мб с приростом по 50 Мб.
3. проведите ТиС базы с опциями "сжатие таблиц информационной базы" и "реструктуризация таблиц информационной базы".
2. начальный размер файлов БД какой выставлен? выставьте для файла БД ваши 65 Гб, прирост по 200 Мб, для журнала можно поставить 50-100 Мб с приростом по 50 Мб.
3. проведите ТиС базы с опциями "сжатие таблиц информационной базы" и "реструктуризация таблиц информационной базы".
(3) kotloff, Initial Size = 900000 Мб. Автоприрост на файл данных и лога стоит по 10%. Попробую уменьшить этот параметр может база уменьшиться. Естественно сделаю бэкап перед этим. Если не получиться попробую выгрузить в *.dt. Реструктуризацию уже сделал порезал где-то 30 Гб.
Попытаться провести сжатие средствами самого сервера.
Есть еще варинт выгрузить средствами 1С базу в *.dt затем удалить на сервере СКЛ базу либо очистить и загрузить туда средствами самой же 1С, правда это процесс долгий довольно.
Если решитьесь на такой маневр, для надежности сделайте векап базы средствами СКЛ сервера, потому как были случаи что сама 1С по каким то причинам не могла залить базу.
Есть еще варинт выгрузить средствами 1С базу в *.dt затем удалить на сервере СКЛ базу либо очистить и загрузить туда средствами самой же 1С, правда это процесс долгий довольно.
Если решитьесь на такой маневр, для надежности сделайте векап базы средствами СКЛ сервера, потому как были случаи что сама 1С по каким то причинам не могла залить базу.
(14) SaschaL, все получилось. В свойствах базы есть параметр Initial Size. У меня стоял 900000 МБ. Изменил на 65 000 МБ. Managemen t Studio думал где-то 1.5 часа. Получается что при изменении его параметра файлы внутри БД которые не входят в эти 940000 МБ перемещаются на дисковое пространство 65 000 МБ. Вот так вот. Источник BOL.
(18) В свойствах БД SQL сервера вы можете указать любой начальный размер файла базы данных и файла журнала, но не меньше текущего занятого объема. Начальный размер, обычно, указывается выше чем реально занимаемый объем БД. Делается это для того, чтобы свести дисковые операции увеличения размера файлов к минимуму и тем самым повысить скорость работы SQL сервера.
Чтобы задать корректный начальный размер желательно знать темпы прироста данных и указывать начальный размер с некоторым запасом. Сильно большой файл делать конечно не стоит, но, в большинстве случаев, процентов 20-30 можно смело накинуть. Главное чтобы в свойствах файла параметры увеличения были не в %, а фиксированного объема, например 50-100Мб, тогда увеличение файла будет проходить и быстрее и с предсказуемым объемом, но все равно заставит SQL сервер выполнять лишнюю работу.
В общем сжатием тоже особо увлекаться не стоит, лучше в рэйд массив дисков добавить.
Когда рэйд массив собран на ссд дисках, то особо актуальным становится сжатие таблиц БД средствами SQL. Это позволяет уменьшить объем файлов данных без особого ущерба в скорости работы. Например у меня из БД в 40Гб получилась база в 8Гб, хотя эффект сжатия больше зависит от хранимой в БД информации и если БД забита картинками, то особого уменьшения размера ждать не стоит.
Если вы прочитали статью, на которую я давал ссылку выше, то уже знаете, что даже сжатая база данных через некоторое время сильно разрастается. Достаточно выполнить обновление конфигурации или запустить ТиИ и выполнить индексирование или реструктуризацию БД. Чтобы этого не происходило необходимо создать регламентное задание сжатия таблиц БД или триггер выполняющий ту же задачу.
Чтобы задать корректный начальный размер желательно знать темпы прироста данных и указывать начальный размер с некоторым запасом. Сильно большой файл делать конечно не стоит, но, в большинстве случаев, процентов 20-30 можно смело накинуть. Главное чтобы в свойствах файла параметры увеличения были не в %, а фиксированного объема, например 50-100Мб, тогда увеличение файла будет проходить и быстрее и с предсказуемым объемом, но все равно заставит SQL сервер выполнять лишнюю работу.
В общем сжатием тоже особо увлекаться не стоит, лучше в рэйд массив дисков добавить.
Когда рэйд массив собран на ссд дисках, то особо актуальным становится сжатие таблиц БД средствами SQL. Это позволяет уменьшить объем файлов данных без особого ущерба в скорости работы. Например у меня из БД в 40Гб получилась база в 8Гб, хотя эффект сжатия больше зависит от хранимой в БД информации и если БД забита картинками, то особого уменьшения размера ждать не стоит.
Если вы прочитали статью, на которую я давал ссылку выше, то уже знаете, что даже сжатая база данных через некоторое время сильно разрастается. Достаточно выполнить обновление конфигурации или запустить ТиИ и выполнить индексирование или реструктуризацию БД. Чтобы этого не происходило необходимо создать регламентное задание сжатия таблиц БД или триггер выполняющий ту же задачу.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот