Добрый день!

Юзаю базу SQLEXPRESS, на диске она занимает 10Мб. Процесс sqlserv.exe занимает в памяти 800Мб. Это нормальная ситуация?

С уважением, Юрий.

Нормальная, если у тебя 1 гб

> Занимает в памяти 800Мб

в виртуальной - нормально

оцените хар-ки

sp_configure 'show advanced options',0
RECONFIGURE
go
sp_configure
go
sp_configure 'show advanced options',1
RECONFIGURE
go
sp_configure

обратить внимание на параметр
max server memory (MB)
если мин сделать = мах. Будет фиксировано. Если бд маленькие - стоит сделать БД х 3, но не менее 200-300 мб

При запуске процесс занимает около 70М. Дальше к базе подключаются два клиента. Один апдейтит таблицу 3-4 раза в секунду, другой ее переоткрывает. Процесс пухнет на 200-300 кб в секунду. Такое ощущение, что он все эти апдейты где то хранит, а вместе с ними еще какую-то инфу, так как на такой объем данных не приходит в базу.

Max server memory = 2Гб.  То есть можно его просто ограничить? Скажется ли это ограничение на быстродействии базы?

С уважением.

Тип восстановления надо посмотреть в св-вах БД.
Полный нафиг не нужен обычно. Там есть полный, частичный и простой. Простой вполне обычно хватает
Лог, который.

Шринкнуть ТемпДБ еще можно


> Max server memory = 2Гб.  То есть можно его просто ограничить?
>  Скажется ли это ограничение на быстродействии базы?

можно.
А скажется ли.. Надо смотреть в каждом конкретном случае.
Проще эксперимент поставить да посмотреть, будет или нет. Будет - можно назад вернуть.

> Max server memory = 2Гб
Ну так чего беспокоитесь.

> занимает 10Мб. Процесс sqlserv.exe занимает в памяти 800Мб.
>  Это нормальная ситуация?


Динамическое распределение памяти. По мне, это равно как собака на сене - и самому не нужно и других помучаю (другие-то приложения подтормаживают от таких потребностей sql-сервера, порой весьма ощутимо; а если в приложении разработчик по неосторожности реализовал проверку доступной памяти, то такое "неудачное" приложение может отказаться работать параллельно с sql-сервером от MS). Однако, если использовать MS SQLServer по назначению, на серверах с мощным железом, с большими базами (>>>> 10МБ), то такой подход очень даже оправдан.

Добрый день!

Поставил ограничение = 512 Мб, теперь тормозит где-то на уровне 545 Мб и дальше лезит по чуть-чуть.

Сенк за помощь!

Еще вопрос по производительности сервера. Как ее самую можно увеличить, если идет много UPDATEов, кроме индексирования таблицы?

с уважением.

> yurikon  (20.07.2011 12:56:07)  [7]

Убрать ограничение

> кроме индексирования таблицы?
индексирование/индексы то как раз нужно убрать если -
> идет много UPDATEов

индексы они для селектов полезны, а для апдейтов вредны (кроме кластерного со значением на возрастание, этому пофиг)... нужно подбирать компромисс.

смотря какие поля апдейтятся, смотря какая структура, смотря какие индексы уже есть и смотря какие из них можно выкинуть.
>> индексы они для селектов полезны, а для апдейтов вредны

Так что с логом там у Вас?
много апдейтов -> растет лог отката. Надо его периодически прибивать или не давать расти изначально.

> SQLEXPRESS   (20.07.11 16:31) [10]

> Так что с логом там у Вас?
> много апдейтов -> растет лог отката. Надо его периодически
> прибивать или не давать расти изначально.

Ни то ни другое невозможно.

> Ни то ни другое невозможно.

да ладно?
1. DBCC SHRINKFILE(trans_log, newsize)
2. в настройках БД, не давать становится trans_log более size

Приветствую!

2 SQLEXPRESS
Лог не растет, если вы имеете ввиду файл "имя базы_log". В настройках базы там стоит 2М, и такой размер и есть. Если Вы про другой файл - подскажите, где его глянуть.

Провел ряд экспериментов. Получил следующие результаты. Есть таблица 20 строк и 20 полей, они апдейтятся клиентом несколько раз в секунду. В таблице я сначала поставил триггер на апдейт и первичный ключ. Среднее время рефреша такой таблицы 4.5 миллисек. Потом убрал триггер - стало 3 миллисек. Потом убил индекс - вышло совсем отлично - 1.7 миллисек.

Так что оставил триггеры только для тех таблиц, которые редко обновляются, чтобы не рефрешить их попусту.

С уважением.

> SQLEXPRESS  (20.07.2011 17:01:12)  [12]

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

> yurikon  (20.07.2011 18:09:13)  [13]

2М это начальный размер. Сверху лог никак не ограничен, столько сколько
нужно для работы.

> 1. Это лог не прибивает, а только сжимает, прибитие лога
> - это уничтожение
> базы
> 2. Имеем в итоге испорченую базу. Ты хоть понимаешь для
> чего нужен лог, как
> это работает

1. согласен, не так сказал.
в случае чрезмерного раздутия (700 метров, например и более)
ужать до 1 - это считай, что прибить
2. да, конечно.
я про возможность ограничить и тут


> Сверху лог никак не ограничен, столько сколько
> нужно для работы.

да ладно, не нужно ему слишком много.
Вернее, он хапает пока может. А потом это все грузом лежит.


>  Есть таблица 20 строк и 20 полей, они апдейтятся клиентом
> несколько раз в секунду.

тут вообще не о чем говорить. Все в минимум можно ставить.
Если это не киношки :), что вряд ли, т.к. несколько раз в секунду апдейтятся

> SQLEXPRESS  (20.07.2011 20:41:16)  [16]

Прибить это удалить лог файл.

Размер лога сверху ничем не ограничен. В настройках ничего подобного твоему
утверждению "не давать становится trans_log более size", поскольку это
равносильно смерти базы. Я на всякий случай проверил все настройки - нет
этого. И быть этого не может.

Вы меня пугаете..
а это что тогда?
http://ifolder.ru/24798239

совсем система испортилась, захочешь помотреть - непосмотришь
тут лучше
http://zalil.ru/31447039

> тут лучше
http://imageshack.us/