13.08.2008, 12:57 | #21 |
Administrator
|
Цитата:
Сообщение от gl00mie
Практика показывает, что Oracle "тупой" немного по-иному
... Не зная настроек оптимизатора и конкретики собранной им статистики, очень сложно бывает "въехать", какого фига Oracle так тупит. И дисциплинирует это не столько программиста, сколько руководство - в плане того, что надо искать очень дорого Oracle DBA, который бы мог разруливать такие ситуации подкруткой весов различных параметров, используемых оптимизатором запросов, а не тупым прикручиванием outline'ов, которые слетают при любом изменении таблицы/запроса. Тут тяжело сравнивать. Переход с одной БД на другую - нельзя сказать что делается легко и непринужденно. Были проблемы на SQL2000, перешли на Оракл - проблемы исчезли. Редкая тупизна Оракла (в смысле что какие-то запросы редко зависают по непонятным с ходу причинам) ... ну да решается конечно... Пришлось разориться на Oracle DBA. Вышел SQL 2005. Кто даст гарантии, что при переходе с Оракла на 2005 будет все ок? А если опять проблемы возникнут - кто будет в ответе? И каким образом (это ж все деньги)? Лицензии опять-таки (если говорить о легальном использовании софта) не бесплатные (особенно ораклиные) А туда-сюда метаться - тоже никаких денег не хватит . Да, в общем-то и по SQL Server тоже по хорошему DBA нужен... Работу-то делать надо.
__________________
Возможно сделать все. Вопрос времени |
|
13.08.2008, 13:40 | #22 |
очами вижу
|
Цитата:
Сообщение от egorych
Нет, не быстрее (проверяли на одном и том-же оборудовании) - в пределах погрешности измерения. Вопрос именно в блокировках - если, например, начать создавать одновременно (на +- пару секунд) отгрузки, близкие по номеру блокируется строка(бывает и страница) таблицы и страница индекса - и такой вот итог. Ну не всегда конечно, но частенько.
Возможно это и борется в рамках Аксапты, но уж сильно глубоко копать нужно. |
|
13.08.2008, 13:54 | #23 |
Участник
|
Цитата:
Сообщение от gl00mie
Практика показывает, что Oracle "тупой" немного по-иному Индексы-то на таблицах есть почти всегда, так вот, Oracle подчас хватает совсем не те индексы, которые, бывает, специально ему под определенные запросы создаешь. Получается, конечно, не full scan, но на больших объемах - все равно слишком долго, причем выявляется это, порой, лишь на сопоставимой с рабочей по объему и наполнению тестовой базе, а то и вообще только на рабочей. Не зная настроек оптимизатора и конкретики собранной им статистики, очень сложно бывает "въехать", какого фига Oracle так тупит. И дисциплинирует это не столько программиста, сколько руководство - в плане того, что надо искать очень дорого Oracle DBA, который бы мог разруливать такие ситуации подкруткой весов различных параметров, используемых оптимизатором запросов, а не тупым прикручиванием outline'ов, которые слетают при любом изменении таблицы/запроса.
|
|
13.08.2008, 14:17 | #24 |
Участник
|
Цитата:
Эскалация подразумевает переключение режимов блокировки - строка->страница->таблица->база в моем случае происходит сразу блокировка страницы индекса/таблицы - могу заверить со всей ответственностью, что MS не всегда использует построчную блокировку. |
|
13.08.2008, 14:50 | #25 |
Участник
|
Цитата:
Сообщение от ring
Оракл хватает не те индексы как раз потому что АКСПАТА по своему усмотрению меняет важные оракловые параметры Axapta 3.0 sp3+oracle 10.2.0.3 optimizer_index_cost_adj
|
|
13.08.2008, 14:51 | #26 |
Участник
|
Сразу страницу ?
А почему ? |
|
13.08.2008, 15:10 | #27 |
Участник
|
Охотно вам верю, но в данном случае запросы проверялись через обычный sqlplus который не меняет умолчательных парметров в сессии и разница очень существенна,больше всего раздражает то что аксапта, впрочем как и многие другие програмные продукты к которым мелкософт приложила свои руки, решает за администартора какие параметры выставлять...имхо бред, поэтому говорить о тонкой настройке БД не приходиться...
|
|
13.08.2008, 15:42 | #28 |
Участник
|
Основные причины такого поведения:
1. Отсутствует PRIMARY KEY 2. Отсутствует кластерный индекс 3. Попытка заблокировать большое число записей 4. Нехватает индекса(ов), т.е. нет подходящего для выбора требуемых записей 5. Недостаточно оперативной памяти для реализации блокировки по записям Беcспорно !!! Последний раз редактировалось Alexius; 13.08.2008 в 15:45. |
|
13.08.2008, 17:36 | #29 |
Участник
|
|
|
22.08.2008, 11:09 | #30 |
Microsoft Dynamics
|
Цитата:
MS SQL x64 + МНОГО памяти будет дешевле и бескровнее, чем скрещивать трепеную лань с конем. |
|
22.08.2008, 13:56 | #31 |
Administrator
|
Цитата:
Но тут в соседней ветке Ромка верно заметил: Я со своей стороны после SQL 2000 сильно проникся Ораклом. Ромка заразил
__________________
Возможно сделать все. Вопрос времени |
|
23.08.2008, 06:41 | #32 |
Microsoft Dynamics
|
Цитата:
Я считаю, что на адекватном железе и SQL будет неплохо шевелиться. А если он не шевелится, то миграцией на Oracle положение не спасешь. Возможно не время станет лучше, но в долгосрочной перспективе случится то самое место, из которого у многих руки растут. И вообще, кесарю кесарево, а Аксапте - майкрософтово. Поддержка Oracle в AX сделана чисто для галочки и похоже деградирует. |
|
28.08.2008, 13:38 | #33 |
MCITP
|
Цитата:
Обоснование звучало примерно так: "Нам не выгодно, чтоб Аксапта с Ораклом работала лучше чем с SQLсервером." Логика железная... Жалко.
__________________
Zhirenkov Vitaly |
|
28.08.2008, 14:26 | #34 |
Участник
|
Можно подумать, что поддержка MSSQL нормальная! В чем она заключается ? ни триггеров, ни ХП не используется - все на уровне запросов (ну прям 1С от мелкософта).
Ну может хинты какие-то лучше используются. С ораклом она хоть на уровне нормальных запросов общается, а не курсорами долбаными! |
|
29.08.2008, 09:08 | #35 |
Microsoft Dynamics
|
Цитата:
Цитата:
Люди базы
Целью жизни для людей базы является неуемное стремление нормализовать базу до десятого уровня нормализации и при этом они испытывают состояние близкое к оргазму. Кроме того в их задачу входит полное устранение middle tier, в виду его полной ненужности, а чего, говорят они, все здеся, в наших родненьких stored procedures и ненаглядных triggers. А к этим таблицам не будет вам прямого доступа, щас вам view наваляем. А будете выпендриваться вообще лишим доступа. В идеале кроме базы ничего не должно существовать. База есть вещь в себе и для себя! |
|
|
За это сообщение автора поблагодарили: Vadik (1). |
29.08.2008, 11:16 | #36 |
Участник
|
|
|
29.08.2008, 11:43 | #37 |
MCITP
|
Можно начать почитать с этого:
Подход с использованием принципа черного ящика Особенно читать там где про принцип чёрного ящика
__________________
Zhirenkov Vitaly |
|
29.08.2008, 12:36 | #38 |
Microsoft Dynamics
|
Цитата:
Сообщение от ZVV
Можно начать почитать с этого:
Подход с использованием принципа черного ящика Особенно читать там где про принцип чёрного ящика |
|
29.08.2008, 14:54 | #39 |
MCITP
|
Что-то я уже тоже не догоняю, что Timofey_k хочет нам сказать...
PS Имею ввиду, своей цитатой про человеков базы..
__________________
Zhirenkov Vitaly Последний раз редактировалось ZVV; 29.08.2008 в 14:56. |
|
29.08.2008, 17:35 | #40 |
Microsoft Dynamics
|
Цитата:
На самом деле он хочет многое сказать про сочетание Аксапты и Оракла, но автор темы об этом совсем ничего не спрашивал и вряд ли хочет это слышать. |
|
Теги |
ax3.0, oracle |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|