Как уменьшить размер базы? - NAV: Администрирование

Wooldoor_Sockbat · 24.09.2009, 11:38

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

**Sancho** · 24.09.2009, 11:59

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

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

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

RedFox · 24.09.2009, 12:16

Цитата:

Сообщение от 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** · 24.09.2009, 12:37

Цитата:

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

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

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

Wooldoor_Sockbat · 24.09.2009, 13:18

Спасибо, за советы.
Лог небольшой,шринкование проводится регулярно.
В 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, есть ли какие-нибудь подводные камни, если можно киньте ссылку на инструкцию.

**Sancho** · 24.09.2009, 14:49

мда.
тут терапия бессильна.
к хирургу.

имхо, только компрессия

с 2005-м сервером были некоторые проблемы. например

"Там может быть проблема что из нава не видно базы на сервере. (ибо они поменяли систему разграничения доступа)
Решается так

Заходим:
SQL Server Configuration Manager -
SQL Server 2005 services -
SQL Server (MSSQLServer) -
Properties
- закладка Advanced -
Параметр Startup parameters - добавляем в конец строки ;-T4616

без пробелов "

Fordewind · 24.09.2009, 15:42

Цитата:

Сообщение от 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 · 24.09.2009, 16:40

Цитата:

Сообщение от 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.

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

rmv · 24.09.2009, 17:27

Перевод клиента на 5.1 + сервер SQL 2005 несколько сократит размер базы за счет отказа от сифт таблиц в обмен на индексированные представления .
Кардинально же поможет только компрессия.

Wooldoor_Sockbat · 24.09.2009, 18:00

Накопилось за 3 года, компания-дистрибьютор.
Лицензированных сессий:536,используются не больше 50, но это не так важно впринципе,данные в Navision, попадают из другой системы.
Спасибо большое всем за помощь.

RedFox · 24.09.2009, 22:49

Цитата:

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

Накопилось за 3 года, компания-дистрибьютор.

Сжимать трудоновато будет, хотя можно сжать за последний (старый) год (но только не товарные операции! или подправить Отчет по 32!) можно, делая уточнение на то, какие аналитики нужны для анализа (был случай...)

Цитата:

Лицензированных сессий:536,используются не больше 50, но это не так важно впринципе,данные в Navision, попадают из другой системы.

А вот можно в этом месте немного поподробнее?? Каким образом они попадают и в каком кол-ве? "Сжимаются" ли в товарном журнале в разразе дня по Товару-Варианту или по 1 товарной позиции все приходит? Поститься в размере горы измерений, как можно судить по таблице?

**Sancho** · 24.09.2009, 23:29

фин. журнал... 3 года,
234 938 записей в ДЕНЬ
либо это форматы гораздо более дорогих систем, либо что-то там не так учитывается (например, многократное дублирование документов одной сделки с различными измерениями: Компания А продала компании Б, та купила и продала В, В купила и продала Г...)
163 проводки в минуту при круглосуточном режиме работы...

**Sancho** · 24.09.2009, 23:35

это, конечно, лирика, но я под впечатлением.
нумерацию документов я даже представить боюсь, но элементарный integer при таком объеме у вас просто может кончиться...
сейчас прикину...

**Sancho** · 24.09.2009, 23:39

до окончания integer-а у вас осталось 22 года работы в Фин. Книге Операций
время еще есть

Imidg_8 · 25.09.2009, 14:04

Цитата:

Сообщение от 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 · 27.09.2009, 00:18

Цитата:

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

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

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

Imidg_8 · 28.09.2009, 08:17

Да нет фигня в том, что, когда одновременно пытаются работать с одной табличкой то возникают задержки , причем нагрузка на проц , можно считать , что ее нет, а вот систама в целом "тормозит".
Да и учетные операции не совсем быстро, я так понимаю на Ваших объемах пользователи на жалуются на "долгое" проведение документов.
У нас типовой набор:
- Файловая группа (Дата и Дата_1)
- лог файл

Похоже что даже если разнести ВСЁ на отдельные винты картину это радикально не улучшит, - есть какие - то настройки на быстродействие ???

Imidg_8 · 28.09.2009, 08:30

Цитата:

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

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

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

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

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

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

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