информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяSpanning Tree Protocol: недокументированное применениеВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ростелеком заподозрили в попытке... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / sysadmin
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Ближе к OLTP. Клиенты не выполняют прямо никаких SQL... 27.04.06 05:12  Число просмотров: 2297
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
> Во всех ли таблицах используются кластерные индексы?
> Используются ли кластерные индексы в таблицах с частым
> добавлением и изменением данных?
> Какие значения параметров БД, регулирующих заполенение
> страниц?
> Иными словами - это база ближе к OLTP или OLAP?
>
> З.Ы. Сколько всего оперативки на железе, где крутится
> MSSQL2005?
Ближе к OLTP. Клиенты не выполняют прямо никаких SQL запросов. Их дело - вызвать процедуры на сервере. Запросы не возвращают рекордсеты пользователем. Внутри только добавление, удаление и вставка данных. Структура базы простая, как и запросы в хранимых процедурах. В общем, это как бы лог всех операций системы, который почти в реал тайм пишет сивкел сервер. Кроме этого, один из серверорв системы (другой бокс) пишет лог выполненых процедур, типа EXECUTE Proc1 par1, par2 ...
Для тестирования я беру этот лог и "выполняю" одну за другой процедуры (тестовое приложение). Это достаточно близко к тому, что происходит в рабочее время. В секунду сервер должен выполнять 200-1000 хранимых процедур.

Окружение такое,

W2k Version 5.0.2195 Service Pack 4 Build 2195
System Manufacturer Dell Inc.
System Model Precision WorkStation 370
Processor x86 Family 15 Model 4 Stepping 1 GenuineIntel ~2992 Mhz
BIOS Version Phoenix ROM BIOS PLUS Version 1.10 A04
Total Physical Memory 522,332 KB
Available Physical Memory 9,852 KB
Total Virtual Memory 2,309,548 KB
Available Virtual Memory 1,245,904 KB
Page File Space 1,787,216 KB
Page File C:\pagefile.sys
Page File E:\pagefile.sys

При установке SQL2005 выдал предупреждение, что мол ресурсы - сакс. Сегодня вообще всё креш.
Короче, поставил W2003 + 1G оперативки 2CPU Dell. К концу недели получу результаты. Доложу, обсудим.

Спасибо за мнение.
<sysadmin>
MS SQL2000/2005 25.04.06 03:30  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Поделитесь плз. опытом. Вопрос в том, что SQL 2005, установленный на W2k prof работает на 20-40 медленне, чем SQL2000. База маленькая. 90% запросов на вставку, удаление, обновление. Всё только в хранимых процедурах. Каких ему мозгов( или мне ) ещё в конце концов добавить...
Где собака зарылась?
Привет, парни. 26.04.06 05:57  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
> Поделитесь плз. опытом. Вопрос в том, что SQL 2005,
> установленный на W2k prof работает на 20-40 медленне, чем
> SQL2000. База маленькая. 90% запросов на вставку, удаление,
> обновление. Всё только в хранимых процедурах. Каких ему
> мозгов( или мне ) ещё в конце концов добавить...
> Где собака зарылась?

Привет, парни.
Вот что происходит. Наиболее “значимым” параметром оказывается минимальный размер памяти, выделяемый серверу. Увеличение его до 64 M даёт повышение производительности на 5-10%. Если увеличить размер памяти ещё до 128 M, то эффекта уже практически нет. Остальные параметры поддержка AWE, минимальный размер памяти на запрос, тип провайдера клиента - практически не оказывают влияния.

База была «перенесена», путём восстановления SQL2000 backup на SQL2005, sp1, т.е. без миграции с использованием DTS. Перед началом тестирования база прочекана (dbcc checkdb) – ошибок нет. Затем перед каждым тестом (это по реальному положению дел базы в продакшн) выполнялась очистка временных таблиц, dbcc shrinkfile( log ) и затем dbcc updatestatus. Перегенерация индексов (rebuild) так же ничего не дало. Возможно проблема в том, на W2k SQL2005 в принципе жить не может быстрее?
Тут я, дурень, вообще ошибся...Как сказал мой шеф, AWE - вообще не нужен здесь. 27.04.06 05:13  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Как часто в базе происходят изменения и добавления данных? [upd] 26.04.06 11:21  
Автор: Den <Denis> Статус: The Elderman
Отредактировано 26.04.06 11:23  Количество правок: 1
<"чистая" ссылка>
Во всех ли таблицах используются кластерные индексы?
Используются ли кластерные индексы в таблицах с частым добавлением и изменением данных?
Какие значения параметров БД, регулирующих заполенение страниц?
Иными словами - это база ближе к OLTP или OLAP?

З.Ы. Сколько всего оперативки на железе, где крутится MSSQL2005?
Ближе к OLTP. Клиенты не выполняют прямо никаких SQL... 27.04.06 05:12  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
> Во всех ли таблицах используются кластерные индексы?
> Используются ли кластерные индексы в таблицах с частым
> добавлением и изменением данных?
> Какие значения параметров БД, регулирующих заполенение
> страниц?
> Иными словами - это база ближе к OLTP или OLAP?
>
> З.Ы. Сколько всего оперативки на железе, где крутится
> MSSQL2005?
Ближе к OLTP. Клиенты не выполняют прямо никаких SQL запросов. Их дело - вызвать процедуры на сервере. Запросы не возвращают рекордсеты пользователем. Внутри только добавление, удаление и вставка данных. Структура базы простая, как и запросы в хранимых процедурах. В общем, это как бы лог всех операций системы, который почти в реал тайм пишет сивкел сервер. Кроме этого, один из серверорв системы (другой бокс) пишет лог выполненых процедур, типа EXECUTE Proc1 par1, par2 ...
Для тестирования я беру этот лог и "выполняю" одну за другой процедуры (тестовое приложение). Это достаточно близко к тому, что происходит в рабочее время. В секунду сервер должен выполнять 200-1000 хранимых процедур.

Окружение такое,

W2k Version 5.0.2195 Service Pack 4 Build 2195
System Manufacturer Dell Inc.
System Model Precision WorkStation 370
Processor x86 Family 15 Model 4 Stepping 1 GenuineIntel ~2992 Mhz
BIOS Version Phoenix ROM BIOS PLUS Version 1.10 A04
Total Physical Memory 522,332 KB
Available Physical Memory 9,852 KB
Total Virtual Memory 2,309,548 KB
Available Virtual Memory 1,245,904 KB
Page File Space 1,787,216 KB
Page File C:\pagefile.sys
Page File E:\pagefile.sys

При установке SQL2005 выдал предупреждение, что мол ресурсы - сакс. Сегодня вообще всё креш.
Короче, поставил W2003 + 1G оперативки 2CPU Dell. К концу недели получу результаты. Доложу, обсудим.

Спасибо за мнение.
Проверь, используется ли кластерный индекс. По большому... 02.05.06 14:52  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
> Ближе к OLTP. Клиенты не выполняют прямо никаких SQL
> запросов. Их дело - вызвать процедуры на сервере. Запросы
> не возвращают рекордсеты пользователем. Внутри только
> добавление, удаление и вставка данных. Структура базы
> простая, как и запросы в хранимых процедурах. В общем, это
> как бы лог всех операций системы, который почти в реал тайм
> пишет сивкел сервер. Кроме этого, один из серверорв системы
> (другой бокс) пишет лог выполненых процедур, типа EXECUTE
> Proc1 par1, par2 ...

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

> Окружение такое,
>
> W2k Version 5.0.2195 Service Pack 4 Build 2195
> System Manufacturer Dell Inc.
> System Model Precision WorkStation 370
> Processor x86 Family 15 Model 4 Stepping 1 GenuineIntel
> ~2992 Mhz
> BIOS Version Phoenix ROM BIOS PLUS Version 1.10 A04
> Total Physical Memory 522,332 KB
> Available Physical Memory 9,852 KB
> Total Virtual Memory 2,309,548 KB
> Available Virtual Memory 1,245,904 KB
> Page File Space 1,787,216 KB
> Page File C:\pagefile.sys
> Page File E:\pagefile.sys
>
> При установке SQL2005 выдал предупреждение, что мол ресурсы
> - сакс. Сегодня вообще всё креш.

Действительно, ресурсы были сакс...

> Короче, поставил W2003 + 1G оперативки 2CPU Dell. К концу
> недели получу результаты. Доложу, обсудим.
> Спасибо за мнение.
Скорее всего ваша догадка верная. 04.05.06 05:32  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Перенёс базу и данные "с нуля" на SQL 2005. Заработало. Теперь 2005 процентов на ~30% шустрее MySQL (последний на ~40 процентов быстрее SQL 2000 для той же базы и задачи). Скорее всего, дело было в испорченых индексах... Хотя до конца не разобрался.
Профайлер всё равно показывает огромное число чтений в сравнении с числом операций запии. Но работает очень быстро в сравнении и SQL2000 или MySQL (на виндовз)

Спасибо.
Есть конечно... 03.05.06 04:59  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
> Проверь, используется ли кластерный индекс. По большому
> счету, для таких задач, использование кластерного индекса
> необязательно, а может даже нежелательно, но если очень
> хочется его использовать, то лучше сделать этот индекс к
> столбцу фиксирующему время операции.

Profiler показывает показывает критичные процедуры, которые надо править, а там и таблицы видно, где индексы надо смотреть и кривые запросы т.д. Это всё будут наши респонсибл спецы делать, если решат переезжать на 2005. Но всё это не отвечает на вопрос - почему то, что работало в SQL 2000 относительно шустро, перестало вдруг работать шустро. Есть что-то ещё там косяковое напрочь.

ПС. Ещё я перепробовал разные провайдеры и вариации коннекшн стринг ... толку нет, что и сдедовало ожидать. Нормальный миграйшн базы с 2000 на 2005 пока не делал (при помощи TDS). База 2005 была тупо восстановлена из бекапа 2000. Кроме того, пока не снял параметр обеспечения обратной совместимости с 2000. Попробую - расскажу. Думаю в этом дело.

Спасибо.
(1/2) В 2005 сиквеле появилась возможность компилировать хранимые процедуры. И если бизнес логика требует мощной считалки - компиляция может дать сильный прирост производительности. Поставьте счетчики производ на ключевые параметры сиквел сервера. 25.04.06 10:35  
Автор: Garick <Yuriy> Статус: Elderman
<"чистая" ссылка>
Вообще-то хранимые процедуры и вьюшки всегда компилились автоматом во всех версиях MS SQL 25.04.06 14:26  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Вроде бы начиная с семёрки процедуры как раз не... 25.04.06 16:31  
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
<"чистая" ссылка>
Вроде бы начиная с семёрки процедуры как раз не прекомпилируются, а хранятся в виде SQL. При первом вызове компилируются, план сохраняется в кэше, а потом уже происходит переиспользование плана выполнения (если нужно).
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach