Как уменьшить размер базы?

[Sancho]

во-первых, лог
если Вам не приходилось откатывать базу на полчаса назад, то есть вероятность, что и не придется.
тогда лог можно переделать с full на simple, а заодно шринкануть оставшиеся 2 файла.
база может ужаться процентов на 60.

во-вторых, объем таблиц
можно посмотреть какие таблицы больше всего занимают места, например, 405-я
попробовать оптимизировать протокол
опять же, аналитические отчеты, может в них стоит установить компрессию какую и пересобрать?

если первые 2 варианта не помогут, то тут уже наверное стоит запускать компрессию...

[RedFox]

Цитата:

Сообщение от Wooldoor_Sockbat

Добрый день, возникла необходимость уменьшить размер базы, как это лучше сделать? На данный момент база занимает более одного террабайта. Лог файл небольшой.
Nav 4SP3 + SQL 2000
1)Сильно ли помогут стандартные средства компресии Navision (например, Компрессия Книги Фин. Операций) и быстро ли они работают?
2)Переход на SQL 2005 даст прирост производительности или нет?
3)Посоветуйте, пожалуйста, какие-нибудь другие способы?

Сразу говорю для Nav 4SP3 лучше использовать уже 2005 и желательно с последними паками! Но перед миграцией нужно убедиться, что делается бекап NAV, потому что SQL-бекап сильной производительности не даст до того момента, пока не пересоздатите (именно пересоздать физически!) все ключи. Но на такой операции это займет как минимум выходные на хорошем железе. Так что советую Вам началь с анализа пары данные + ключи.
1. Не сильно помогут, если стандартные таблицы не очень большие или сильно "фрагментированные".
2. в зависимости от того, что у Вас в БД и как Вы будете мигрировать - даст. + Ещё сам NAV можно оптимизировать под него!
3. Пришлите заполненность таблиц в файле Excel (Tables on the form "Database Information") - поссмотрим что можно придумать.

Цитата:

Сообщение от Sancho

во-первых, лог
если Вам не приходилось откатывать базу на полчаса назад, то есть вероятность, что и не придется.
тогда лог можно переделать с full на simple, а заодно шринкануть оставшиеся 2 файла.
база может ужаться процентов на 60.

Не уверен, что это поможет, потому что было написано что лог-файл небольшой. И если нет достаточной инфраструктуры резервного копирования, то НИ В КОЕМ СЛУЧАЕ не меняйте с full на simple, если у Вас Лог файл небольшой.

Цитата:

во-вторых, объем таблиц
можно посмотреть какие таблицы больше всего занимают места, например, 405-я, попробовать оптимизировать протокол
опять же, аналитические отчеты, может в них стоит установить компрессию какую и пересобрать?

Начинание с таблиц это правильно + пересмотреть все ключики, потому что без этого оптимизировать не получится.
А вот про "попробовать оптимизировать протокол" не понял.

Цитата:

если первые 2 варианта не помогут, то тут уже наверное стоит запускать компрессию...

А вот это уже правильно, что почти последнее!
Самое главное понять что именно нужно компрессить и как! Если, например много операций, но нужна аналитика, например за 3 года, то нужно ЗАРАНЕЕ определить горизонт сжатия. И если множество данных попадает в этот горизонт - нет смысла в компрессии. Как долго у Вас данные в БД?
Так же нужно определить какие данные в таблицах "не нужны". Но это нужно делать аккуратно.

P.S. Следующие шаги я смогу сказать после того, что написал выше

[Sancho]

Цитата:

Сообщение от RedFox

А вот про "попробовать оптимизировать протокол" не понял.

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

[Wooldoor_Sockbat]

Спасибо, за советы.
Лог небольшой,шринкование проводится регулярно.
В Change Log все подряд не пишется.
"Начинание с таблиц это правильно + пересмотреть все ключики, потому что без этого оптимизировать не получится." Как их смотреть, я имею ввиду как узнать используется ключ где-нибудь или нет, может быть методики какие-нибудь есть или софт(навиженовский).
Размеры таблиц:
Value Entry строк: 121600007 260 Гб
G/L Entry строк: 257256913 220 Гб
Ledger Entry Dimension строк: 924589997 100 Гб
Item Ledger Entry строк: 67608580 90 Гб
G/L Correspondence Entry строк: 129390127 80 Гб
Вот это вот основные тяжеловесы. Change Log Entry занимает 120 Мб,и число строк там 654000.
По поводу переноса на SQL 2005, есть ли какие-нибудь подводные камни, если можно киньте ссылку на инструкцию.

[Fordewind]

Цитата:

Сообщение от Wooldoor_Sockbat

Спасибо, за советы.
Лог небольшой,шринкование проводится регулярно.
В Change Log все подряд не пишется.
"Начинание с таблиц это правильно + пересмотреть все ключики, потому что без этого оптимизировать не получится." Как их смотреть, я имею ввиду как узнать используется ключ где-нибудь или нет, может быть методики какие-нибудь есть или софт(навиженовский).
Размеры таблиц:
Value Entry строк: 121600007 260 Гб
G/L Entry строк: 257256913 220 Гб
Ledger Entry Dimension строк: 924589997 100 Гб
Item Ledger Entry строк: 67608580 90 Гб
G/L Correspondence Entry строк: 129390127 80 Гб
Вот это вот основные тяжеловесы. Change Log Entry занимает 120 Мб,и число строк там 654000.
По поводу переноса на SQL 2005, есть ли какие-нибудь подводные камни, если можно киньте ссылку на инструкцию.

Компрессия однозначно.
Если не секрет, а за сколько лет такое накопилось? И сколько у вас пользовательских сессий в лицензии?

P.S. Нервно покуриваю поглядывая на размеры базы

[RedFox]

Цитата:

Сообщение от Wooldoor_Sockbat

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

Стандатного ЕДИНОГО места, где используется тот или иной ключ - нет (потому что например SIFT использует комбинации полей, которые просто входят в ключ). Начинать нужно с деббагера и анализа кода (потихонечку отключать ключики и проверять бизнес-процесс на работоспособность). Без знания что используете мне очень сильно трудно сказать где копать.

Цитата:

Размеры таблиц:
Value Entry строк: 121600007 260 Гб
G/L Entry строк: 257256913 220 Гб
Ledger Entry Dimension строк: 924589997 100 Гб
Item Ledger Entry строк: 67608580 90 Гб
G/L Correspondence Entry строк: 129390127 80 Гб
Вот это вот основные тяжеловесы. Change Log Entry занимает 120 Мб,и число строк там 654000.

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

[Imidg_8]

Цитата:

Сообщение от Wooldoor_Sockbat

Спасибо, за советы.
Лог небольшой,шринкование проводится регулярно.
В Change Log все подряд не пишется.
"Начинание с таблиц это правильно + пересмотреть все ключики, потому что без этого оптимизировать не получится." Как их смотреть, я имею ввиду как узнать используется ключ где-нибудь или нет, может быть методики какие-нибудь есть или софт(навиженовский).
Размеры таблиц:
Value Entry строк: 121600007 260 Гб
G/L Entry строк: 257256913 220 Гб
Ledger Entry Dimension строк: 924589997 100 Гб
Item Ledger Entry строк: 67608580 90 Гб
G/L Correspondence Entry строк: 129390127 80 Гб
Вот это вот основные тяжеловесы. Change Log Entry занимает 120 Мб,и число строк там 654000.
По поводу переноса на SQL 2005, есть ли какие-нибудь подводные камни, если можно киньте ссылку на инструкцию.

Откройте тайну6 на каком железе и в каком варианте все это крутите?
Как делаете резервные копии?
У меня 50 Гиг хреновато себя ведут (розница)

[RedFox]

Цитата:

Сообщение от Imidg_8

Откройте тайну6 на каком железе и в каком варианте все это крутите?
Как делаете резервные копии?
У меня 50 Гиг хреновато себя ведут (розница)

Да у меня БД SQL версии 3.60 в 29Г на локальном ПК (Р2140, 2Г оперативки и кучей всякого "мусора") без оптимизации нормально себя вели..
Так что наверное Вам лучше написать серверные данные и как часто (и какой) бекап делаете? Кстати, сетевіе коннекты тоже.

[Imidg_8]

Цитата:

Сообщение от RedFox

Да у меня БД SQL версии 3.60 в 29Г на локальном ПК (Р2140, 2Г оперативки и кучей всякого "мусора") без оптимизации нормально себя вели..
Так что наверное Вам лучше написать серверные данные и как часто (и какой) бекап делаете? Кстати, сетевіе коннекты тоже.

Бэкап - только ФУЛЛ, но каждый день, И кстати как связано быстродействие с моделью Бэкапа?
Лог файл - делаем Бекап, но без Шрикования.

Ежедневно добавляется порядка 20-25 тысяч чеков в среднем по 7 товаров
При возврате - кассир на прямую ищет чек в БД Магазина, на кассах заметное замедление передачи данных в центральную базу.

Сетевых подключений
Лицензировано - 500
но работает порядка 15-20 в ТТ
кассы живут в своих БД и передают данные о продажах через ТранзСервис.

Т.к. Кассы живут в Нативной БД, задолбали "падежи", необяснимый, консультантами рост БД, кончается свободное пространство. На эту тему есть предположение , но Великие ПроизводителиРазработчики - данного ПП (програмного продукта) - не ответили, писали не напрямую, черех продавцов- консультантов. :-(


Хотим перейти на кассах на СКЛ, типа ЕХПРЕСС