AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 12.04.2017, 09:25   #21  
ppson is offline
ppson
Участник
Аватар для ppson
Ex AND Project
1C
 
2,102 / 114 (8) +++++
Регистрация: 25.06.2002
Адрес: SPb, Msk
Цитата:
Сообщение от gkochkin Посмотреть сообщение
Может, какие-то ресурсы, ссылки и тп по очистке таблиц подскажете?
Не чистите таблица DAX, кроме тех которые рекомендует MS.
все это от лукавого
В случае эпического катаклизма люди из бизнеса придут за ответами именно к вам.
__________________
Старый 12.04.2017, 22:52   #22  
db is offline
db
Роман Долгополов (RDOL)
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
 
393 / 692 (24) +++++++
Регистрация: 01.04.2004
Адрес: Москва
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
330 ГБ не так уж и много. Если вернуться к начальной постановке вопроса - что будет, если ничего не делать?
поддерживаю
330 гб это не то что не очень много это вообще ниочем
Проблема не в гигабайтах, а в неоптимальных запросах dax к бд, неоптимальных индексах, неправильных настройках самой бд, несоответсвующим задачам оборудовании, отсутствии здравого смысла в настройках журнала базы данных в частности и здравого смысла применительно к настройкам системы вообще , кривых доработках и т.д. и т.п.

ищите узкие места, думайте, оптимизируйте. резать на таких объемах проводки это всё равно что отрезать голову при головной боли
За это сообщение автора поблагодарили: Vadik (1), ivas (2), eugene egorov (2), IvanS (1).
Старый 12.04.2017, 23:15   #23  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Сказать много или мало можно только посмотрев на железо на котором все это крутится.
Старый 13.04.2017, 21:29   #24  
ivas is offline
ivas
Участник
Аватар для ivas
 
252 / 68 (3) ++++
Регистрация: 22.12.2005
Цитата:
Сообщение от gkochkin Посмотреть сообщение
Объем - порядка 330 ГБ.
Если честно, не совсем понимаю - пересесть в новую базу и что?
Над новой компанией точно не думали..
330гб это не много, объем таблицы InventTrans на производительность влияет косвенно (если конечно вы не суммируете проводки например в дисплей методах ).
Интересно было бы посмотреть объем других таблиц например InventDim, InventSum, Cust/Vend/Trans/TransOpen. А в целом нужно конечно видеть хотя бы топ 25 тяжелых запросов и знать конфигурацию SQL серверов.

Ах, да, чистить быстрее всего с помощью TRUNCATE TABLE https://msdn.microsoft.com/ru-ru/library/ms177570.aspx
__________________
aLL woRk aNd nO JoY MAKes jAck a dULL Boy

Последний раз редактировалось ivas; 13.04.2017 в 21:35.
Старый 13.04.2017, 22:58   #25  
eugene egorov is offline
eugene egorov
Участник
Аватар для eugene egorov
 
273 / 97 (4) ++++
Регистрация: 05.06.2002
Адрес: Москва
Цитата:
Сообщение от ivas Посмотреть сообщение
Ах, да, чистить быстрее всего с помощью TRUNCATE TABLE https://msdn.microsoft.com/ru-ru/library/ms177570.aspx
DROP DATABASE [IF EXISTS] db_name гораздо гораздее
__________________
любитель портвейна и снов с прокисшей капустой в усах
Старый 14.04.2017, 00:43   #26  
ivas is offline
ivas
Участник
Аватар для ivas
 
252 / 68 (3) ++++
Регистрация: 22.12.2005
Цитата:
Сообщение от eugene egorov Посмотреть сообщение
DROP DATABASE [IF EXISTS] db_name гораздо гораздее
Тоже неплохой вариант по производительности но после команды DROP TABLE/DATABASE теряется структура таблицы, а отчистка подразумевает удаление только данных
__________________
aLL woRk aNd nO JoY MAKes jAck a dULL Boy
Старый 14.04.2017, 10:06   #27  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 248 (9) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от db Посмотреть сообщение
330 гб это не то что не очень много это вообще ниочем
Проблема не в гигабайтах, а в неоптимальных запросах dax к бд, неоптимальных индексах, неправильных настройках самой бд, несоответсвующим задачам оборудовании, отсутствии здравого смысла в настройках журнала базы данных в частности и здравого смысла применительно к настройкам системы вообще , кривых доработках и т.д. и т.п.
С оптимизацией запросов понятно, но вот обслуживание большой БД при отсутствии приличного технологического окна может превратится в кошмар, о чем мне кажется и писал :
Цитата:
Сообщение от gkochkin Посмотреть сообщение
InventTrans у нас очень большая, такая, что с ней практически невозможно проводиться какие-то операции (реиндексация, секционирование и т.д.).
Старый 08.06.2017, 22:34   #28  
vmoskalenko is offline
vmoskalenko
Участник
Аватар для vmoskalenko
 
145 / 334 (12) ++++++
Регистрация: 25.01.2007
Адрес: Toronto
Ко мне приходили слухи, что IDMF будет кусочком нового варианта Миграции данных при апгрейде с AX2012 на AX7.

Т.е. IDMF режет все транзакции в AX2012, а потом DMF экспортит/имопртит оставшееся в AX7.

Но опять же, это все слухи. Посмотрим что нам предложат для Апгрейда данных на AX7.
Старый 09.06.2017, 21:42   #29  
ALES is offline
ALES
Участник
Злыдни
 
220 / 45 (2) +++
Регистрация: 11.08.2004
Цитата:
Сообщение от db Посмотреть сообщение
Проблема не в гигабайтах,..
Проблема в отсутствии мысли у "архитекторов системы" о типовых "объемах", работе бизнеса "в реальном времени" и "физическом смысле" транзакционных вычислений по всей истории от "царя гороха".
И если к датским основателям "маленькой бухгалтерской программки" вопросов с текущего "уровня развития" особо и нет, то авторов DMF можно было бы и заставить лично "мигрировать" любое "живущее" (хотя бы лет несколько) решение..
Старый 11.06.2017, 21:05   #30  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,651 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
У меня одного ощущение, что такую тему я уже читал? Такое ощущение, что подняли какую-то старую тему, просто поменяли даты? Даже ответы как "под копирку". И снобизм в отношении размеров таблицы точно такой же, что печально К сожалению, поиском не нашел в форуме...

Относительно приемлемое решение:

Разделить базу данных на 2: рабочая и архивная часть.

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

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

Размер таблиц

330 ГБ на одну таблицу - это много! Не с точки зрения оптимизации запросов, а с точки зрения администрирования таких таблиц. Создание полей, создание индексов, переиндексация, создание backup - все это будет чудовищно тормозить на таких размерах

----------------

Только что обратил внимание, что тема двухмесячной давности. Но снобизм в отношении размеров - постоянно возникающий мотив... Как только кто-то заикнется, что размер большой и приведет размер таблицы/базы в байтах, так тут же кто-то "встрянет" на тему, что это немного...
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...

Последний раз редактировалось Владимир Максимов; 11.06.2017 в 21:15.
Старый 13.06.2017, 21:59   #31  
ALES is offline
ALES
Участник
Злыдни
 
220 / 45 (2) +++
Регистрация: 11.08.2004
:)
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
...Принять волевое решение, что все данные, созданные, скажем, более 2 лет назад - это архив и тупо перемещать их в архивную базу. Формально, по дате создания без какого-либо дополнительного анализа.
...
Да, да.. это надо кому-то "продать" как яркое подтверждение "зачем "дорогой" консалтинг кормить, ведь и так все очень просто и быстро решается без анализа" :
1. всех "старых добрых проверенных" контрагентов "в архив"
2. "постоянный ассортимент" номенклатур "в архив"
3. за два года так и не "списанные" полностью проводки (те же приходы на склад) "в топку" и пусть главбух возрадуется "излишкам" инвентаризации (большая часть которых после такого решения и до "первого пересчета" физически не доживет)
4. все формы и отчеты не должны из архива данные выводить
...
В итоге "исправляйте... это же ошибки... работать же нельзя... да вы нас не правильно поняли... очевидно же не вообще все zzzzz таблиц "в архив"... конечно же не все "возращенное" из архива должно обратно "при очередном архивировании" помещаться, раз мы это обратно вернули значит нам оно нужно.. пользователи не будут "смотреть и возвращать только действительно нужное" из архива.. есть же какой-то более дешевый "аппаратный" архив на уровне СУБД который сам все автоматически.. а докажите, что задавали вопросы.. мы не помним, что разговор был.. вы же профессионалы должны были.. какие такие доп. требования.. бюджет фиксирован... все консультанты непоймикогопонабиралинаработупродаютвтридорога )) и т.д."

Тема действительно регулярно "всплывает", т.к. "от версии к версии" десятилетиями ничего не меняется и базы растут . Как только будут конкретные критерии "архивирования", запилить "схлопывание истории" по транзакционным таблицам в "начальный остаток" дело и посильное и тестируемое... жаль вендор не торопиться это сделать сразу для всех
За это сообщение автора поблагодарили: Dreadlock (1), Vadik (1).
Теги
dax, dynamics ax, администратор бд

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Описание таблиц DAX 2009 Segador DAX: Программирование 3 07.10.2013 08:13
Генерация таблиц runtime DAX 2012 Idler DAX: Программирование 6 30.10.2012 16:47
Переход на DAX 2009. Проблема с повторяющимися id таблиц. Как исправить? Murlin DAX: Программирование 18 02.11.2009 15:42
Пустые названия системных таблиц в report data range (DAX 4.0) Qaz Qwerty DAX: Функционал 3 06.08.2008 00:05
удаление больших таблиц Nikolaich DAX: Программирование 9 31.01.2006 13:35
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 02:33.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.