MSSQL и Oracle

[BokarevSS]

Добрый день.
MS Dynamics Axapta медленно формирует отчеты, из-за больших объемов БД. Является ли спасением переход с MSSQL на Oracle?
Работает ли MS Dynamics Axapta 3.0 с Oracle11?
Если нет, то какая версия Oracle подходит для MS Dynamics Axapta 3.0, и расскажите пожалуйста трудности по переходу с MSSQL на Oracle.

[kashperuk]

Не советую переходить на Оракл.
Советую переходить на АХ 2009

[BokarevSS]

Будет ли совместим код, написаный под 3-ку с 2009. И почему всетаки лучше перейти на 2009 чем на Oracle?

[Wamr]

Цитата:

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

Будет ли совместим код, написаный под 3-ку с 2009.

Многое придется переписать или удалить

Цитата:

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

И почему всетаки лучше перейти на 2009 чем на Oracle?

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

Кстати, и при переходе на оракл особо изощренные запросы будут работать "не так"

[kashperuk]

Цитата:

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

Будет ли совместим код, написаный под 3-ку с 2009.

Как уже ответил Wamr, кода довольно много придется переписать, если у вас много модификаций.

Цитата:

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

И почему всетаки лучше перейти на 2009 чем на Oracle?

Потому что в течении 2 релиз циклов Майкрософт работала как раз над ускорением производительности ресурсоемких операций и т.д., потому что в АХ 2009 практически отсутствуют блокировки, потому что нет проблем с RecId, различными шрифтами благодаря поддержке юникода и .тд. и т.п.
Да и вообще, команда СКЛ сервера тоже без дела не сидела - поэтому последняя версия с АХ думаю пошустрее работает, чем Оракл 11

[db]

Цитата:

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

Добрый день.
MS Dynamics Axapta медленно формирует отчеты, из-за больших объемов БД. Является ли спасением переход с MSSQL на Oracle?
Работает ли MS Dynamics Axapta 3.0 с Oracle11?
Если нет, то какая версия Oracle подходит для MS Dynamics Axapta 3.0, и расскажите пожалуйста трудности по переходу с MSSQL на Oracle.

Какие отчеты?
Что значит большой объем?
Загрузку железяк кто нибудь мерял?

Спасением в 90% случаев не является ни смена СУБД, ни смена версии. И в тот же процент обычно попадают кривые руки разработчиков и админов.

[egorych]

Цитата:

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

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

Как связана поддержка Аксапты и Оракл? И вообще, насчет поддержки -

Цитата:

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

Кстати, и при переходе на оракл особо изощренные запросы будут работать "не так"

Ну хз насколько надо изощряться - мы не поменяли ни одного запроса!
Мое ИМХО - для Ax3 Оракл 10G - лучший выбор. Насчет 2009 - не скажу, но есть сомнения, что будет быстрее Оракла, хотя не тестил еще.

[dn]

А зачем сразу "хоронить" текущую систему. Может подумать насчет оптимизации? Если дело только в отчетах, то это не повод для глобальных "хиругических" операций (как переход на Oracle, так и на AX 2009). А то как в анекдоте: "доктор сказал в морг, значит в морг"

[BokarevSS]

Проблему с SQL, определил, посмотрев загрузку сервера SQL, и сервера АОС. SQL загружен на 98%, АОС вообще курит: 5%.

[AlexeyS]

самое лучшее тут как уже сказали не резать по живому, а оптимизировать отчеты, может добавить индексы на используемые таблицы ?

[Wamr]

23 Гига это немного
а вы еще на SQL200 или уже все-таки на 2005 переехали?
небось, тормозят финансовые отчеты, а код документа ГК выровнен вправо?

[Андре]

Цитата:

Не советую переходить на Оракл.
Советую переходить на АХ 2009

Или на SAP и Linux. А что - менять так уж все

[BokarevSS]

Мы еще на SQL2000.
Да, тормозят отчеты. А что означает: "код документа ГК выровнен вправо"?

[mazzy]

Цитата:

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

А что означает: "код документа ГК выровнен вправо"?

http://axapta.mazzy.ru/lib/adjustment/

[BokarevSS]

Спасибо за разъяснения.
Да, код документа ГК - выровнен вправо

[Wamr]

При правом выравнивании запрос вида:

select sum(AmountCur) from ledgerTrans
where ledgerTrans.AccountNum == '41.100'

на MS SQL-сервер уйдет:

SELECT SUM(AMOUNTCUR)
FROM LEDGERTRANS
WHERE AccountNum LIKE '%41.100'

Что сильно напряжет сервер, так как не будет использован индекс.
При левом выравнивании запрос получится таким:

SELECT SUM(AMOUNTCUR)
FROM LEDGERTRANS
WHERE AccountNum = '41.100'

Что на порядок проще для MS SQL


Для Oracle правое выравнивание - не проблема, так как там получится как-то так

SELECT SUM(AMOUNTCUR)
FROM LEDGERTRANS
WHERE NLS_LOWER(LTRIM(AccountNum)) = NLS_LOWER('41.100')

Причем, индекс на таблице будет как раз по NLS_LOWER(LTRIM(AccountNum))

[egorych]

Цитата:

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

При правом выравнивании запрос вида:

select sum(AmountCur) from ledgerTrans
where ledgerTrans.AccountNum == '41.100'

на MS SQL-сервер уйдет:

SELECT SUM(AMOUNTCUR)
FROM LEDGERTRANS
WHERE AccountNum LIKE '%41.100'

Что-то я таких запросов у себя не наблюдал! На сервер уходит

 
WHERE AccountNum = '       41.100'

т.е с дополнением пробелами до длины EDT, кстати и на Оракле точно так-же. Ну плюс NLS_LOWER конечно-же.

[ZVV]

Цитата:

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

При правом выравнивании запрос вида:

select sum(AmountCur) from ledgerTrans
where ledgerTrans.AccountNum == '41.100'

на MS SQL-сервер уйдет:

SELECT SUM(AMOUNTCUR)
FROM LEDGERTRANS
WHERE AccountNum LIKE '%41.100'

ой жесть то какая была бы, если б так было на самом деле...
страшно представить!

[Logger]

Наверно Wamr имел в виду фильтр

select sum(AmountCur) from ledgerTrans
where ledgerTrans.AccountNum LIKE '41.100*'

[Wamr]

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

Большая загрузка процессора SQL сервера при построении фин.отчетности может быть вызвана не большим объемом данных, а кривым выражением LIKE в запросах, по полям с правым выравниванием (номер счета)

Данное утверждение не теория, а факт, который я наблюдал в этом году.