|
|
27.01.2007, 13:53
|
#1 |
|
Участник
|
В унисон.
Тормозит прогнозное планирование |
|
|
|
05.02.2007, 12:54
|
#2 |
|
Moderator
|
Цитата:
В теории - индекс будет "быстрее" - так как наименее селективное поля держать в начале не соответвует рекомендациям.
|
|
|
|
05.02.2007, 12:59
|
#3 |
|
Moderator
|
Про ms sql сходу не найду, но по поводу Оракла у Кайта есть такая статья: "Миф: столбцы с максимальным количеством разных значений должны указываться первыми"
Цитата:
Кажется, это следует из соображений здравого смысла. Если предполагается созда-
ние индекса по столбцам С1, С2 таблицы со 100000 строк, при этом столбец С1 имеет 100000 уникальных значений, а столбец С2 — 25000, индекс создается по столбцам Т(С1,С2). Это означает, что столбец С1 должен указываться первым, что соответствует "здравому смыслу". Фактически при сравнении векторов данных (пара значений Cl, C2 задает вектор) порядок столбцов не имеет значения. Рассмотрим следующий пример. ..... |
|
|
|
05.02.2007, 13:00
|
#4 |
|
Участник
|
кстати, в качих случаях и насколько дает преимущество переход на нативного клиента. Я, честно говоря, особой разницы не заметил
|
|
|
|
05.02.2007, 15:23
|
#5 |
|
Модератор
|
Цитата:
Сообщение от belugin
кстати, в качих случаях и насколько дает преимущество переход на нативного клиента. Я, честно говоря, особой разницы не заметил
) стабильно давал прирост около 15% по числу обработанных строк в минутуAxapta 3.0 SP5+KR3, MSSQL2005 SP2. Причины пока не анализировал, но точно не погрешность измерения
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
|
| За это сообщение автора поблагодарили: belugin (12). | |
|
05.02.2007, 16:41
|
#6 |
|
Участник
|
[QUOTE=Vadik;129863]Локально запущенный на ноутбуке Sales order скрипт из Benchmark tool (одна, но пламенная страсть
) стабильно давал прирост около 15% по числу обработанных строк в минутуAxapta 3.0 SP5+KR3, MSSQL2005 SP2. Причины пока не анализировал, но точно не погрешность измерения [/QUOTEийЕсли есть время - с помощью рекомендаций по анализу задержек (в атачменте), - найдете, что сам слой ODBC-OLEDB дает существенные задержки. Уверен, это связанна с новой реализайцией клиента Юкона. Также, в атачменте, еще одну руководство от MS - все найденно на TechNet |
|
|
|
05.02.2007, 16:45
|
#7 |
|
Модератор
|
Цитата:
Сообщение от Torin
Также, в атачменте, еще одну руководство от MS - все найденно на TechNet
также What do I need to know about SQL Server database engine I/O?
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
|
05.02.2007, 17:14
|
#8 |
|
Участник
|
Цитата:
Сообщение от Vadik
Oracle пишет о MS значительно понятнее и лучьше, чем сам MS. 
|
|
|
|
05.02.2007, 15:39
|
#9 |
|
Участник
|
Может быть причина - SP2?
__________________
Axapta v.3.0 sp5 kr2 |
|
|
|
05.02.2007, 15:49
|
#10 |
|
Участник
|
Что есть "нативный клиент"? Поясните, пожалуйста.
|
|
|
|
05.02.2007, 16:28
|
#11 |
|
Участник
|
Цитата:
Сообщение от fomenka
Что есть "нативный клиент"? Поясните, пожалуйста.
|
|
|
|
05.02.2007, 20:02
|
#12 |
|
Участник
|
__________________
Axapta v.3.0 sp5 kr2 |
|
|
|
05.02.2007, 22:13
|
#13 |
|
Участник
|
Раскажу я лучьше другую поучительную историю, связанную с железом. На момент запуска стоял вопрос об использовании 64 разрядной архитектуры. Купили на серверной платформе SuperMicro с одним процессором Intel Core 2 Duo E6600 (2,4), 4G, Serial ATA дисков (без RAID) за 2 штуки денег. Поработали - прикольно ;-)
Купили сервер за 15 штук денег - на тойже платформе, 2 проца Xeon 3.2, 16 G, RAID 5 на сказевых винтах (итого 1Tb), 2 канала, кеш 64Mb, вообщем все круто, насколько возможно. Как мы были удивленны, после специальных тестов и реальной работы, что первый "типо сервер" быстрее "сервера" на 40-60%. Это не шутка. Начали сравнивать - ничего особенного, ну память чуть медленнее, ну RAID5 вроде подтормаживает, но самое отличительно - кеш процессора. у 6600 он 4Mb, а у Ксеона - 2. Если "типо сервер" мы разгоняли до 6-8 тыс batch/sec, то "сервер" более 4 делать не хочет. На одних и тех же данных и одну и туже операцию. Вот такие пироги.. 
|
|
|
|
06.02.2007, 12:07
|
#14 |
|
Злыдни
|
Цитата:
Сообщение от Torin
Если "типо сервер" мы разгоняли до 6-8 тыс batch/sec, то "сервер" более 4 делать не хочет. На одних и тех же данных и одну и туже операцию.
Вот такие пироги..
__________________
люди...считают, что если техника не ломается, то ее не нужно ремонтировать. Инженеры считают, что если она не ломается, то нуждается в совершенствовании. |
|
|
|
06.02.2007, 12:22
|
#15 |
|
Участник
|
Цитата:
Сообщение от KiselevSA
У Вас RAID 5 всю производитеьность съел. Надежность повысилась, а вот запись данных снизилась прилично.
Он, конечно, подтормаживает, но на чтении, но не так сильно, чтобы объяснить разницу.. |
|
|
|
16.02.2007, 22:43
|
#16 |
|
Участник
|
Цитата:
Сообщение от Torin
Ожиданий чтения/записи нет. Тем более, что на запись стоит кеш в рейде - 64 Mb.
Он, конечно, подтормаживает, но на чтении, но не так сильно, чтобы объяснить разницу.. RAID 5 тормозит при записи - факт. RAID 10 - однозначно, и чем больше туда дисков - тем лучше. -- У нас на стойке MSA 1000 (КЭШ 512Mb) база >70ГБ диски 72ГБ 15К RAID 10 И то наблюдаю очереди к диску. - Планирую разбивать базу на файловые группы, на разные диски, выносить в отдельные файловые группы отдельные тяжелые таблицы и отдельно на диски их индексы. Последний раз редактировалось vesna dba; 16.02.2007 в 22:48. |
|
|
|
06.02.2007, 12:09
|
#17 |
|
Member
|
Цитата:
Сообщение от Torin
...
первый "типо сервер" быстрее "сервера" ... А бывает подключишься к серверу с возрастом, и чувствуешь, что локально быстрее... Если база тестовая, конечно (например, когда только настраиваешь при внедрении).
__________________
С уважением, glibs® |
|
|
|
06.02.2007, 10:10
|
#18 |
|
Ищу людей. Дорого.
|
Тут были сообщения про DATAAREAID и их отключения из базы? база сдохла? бакап вчерашний подняли?..
2 Vadik Вы скорее всего уже ответили на мой вопрос, но я его так и не увидел.. повторюсь.. можно ли разом отключить все DATAAREAID в базе и какие отрицательные стороны этого события |
|
|
Комбинированный вид
