Есть таблица (ниже скрипт) в которой как мне кажется он мне вовсе не нужен. Количество записей в этой таблице 29 млн. На 1 случай приходится в среднем 8 записей.

CREATE TABLE [dbo].[Медуслуги] (
[КодСлучая] [int] NOT NULL ,
[КодМедуслуги] [int] NOT NULL ,
[Количество] [real] NULL ,
[Стоимость] [money] NULL
) ON [PRIMARY]

Так вот раньше у меня в ней был и первичный ключ ID (счетчик) и индекс по полю КодСлучая.
Когда я писал один запрос в Query Anlizer запустил Index Tuning Vizard и по нему я окончательно решил что первичный ключ не нужен (показывал что используется на 0%) и посоветовал вместо индекса по полю КодСлучая сделать индекс по полям КодСлучая,КодМедуслуги,Количество,Стоимость ну я так и сделал удалил первичный ключ и создал индекс по 4 полям как он и рекомендовал. В результате запрос стал быстрее выполняться и я на этом успокоился. Но вот такой вопрос что-то у меня машина после этого стала иногда так притормаживать иногда вообще вообще как будто виснет 1-2 минуты вообще практически не реагирует. Смотрю процесс sqlserv оттяпал себе 90 метров и непонятно чем занимается. Подскажите в чем может быть дело.

Мне не хотелось бы задавать использование памяти жестко. Так как ее и так не хватает на таких объемах данных. У меня нет fk других таблиц на эту таблицу. Первичный ключ по 4 полям создать нельзя так как он не будет уникальным. И в принципе мне он вообще не нужен отнимает лишь 1 Gb места (таблица 29 млн. записей)я все-таки его ночью добавил (ID-счетчик) думаю может из-за того что я его неделю назад убрал у меня машина непонятно чем иногда занимается. И что же вы думаете опять вот за час работы винт как завелся на 5-8 минут. У меня мало опыта работы с MSSQL 2000 (как впрочем и с 7-м) поэтому cкажите пожалуйста это нормальньно или нет. Просто когда у меня стоял 7-ой ничего подобного не было, правда и объемы не такие были.
Genady конечно же в базе не одна таблица таблиц с десяток а остальные справочники и в этой таблице хранятся медуслуги. Задача такова есть Счет выставленный медучреждением. В счете от 1-999 случаев (случай - информация о пролеченном больном фамилия,имя и т.п), затем на каждый случай две таблицы одна с сопутствующими диагнозами, вторая "Медуслуги" - какие медуслуги были оказаны в том или ином случае и в этой таблице к концу года будет примерно 40 млн. записей.
Была-бы она не такая большая я бы и не расстраивался особо завел бы его и все.

Т.е. человек написал запрос, в котором какой-то индекс не использовался, и удалил этот индекс.
Завтра напишет другой запрос - и удалит еще чего-нибудь.
Primary Key в таблице нужен - например, невозможно реплицировать таблицу без PK, да и вообще должна
быть возможность как-то сослаться на конкретную запись в таблице? Ну и про ссылочную целостность тут уже сказали...

Я поэтому и спрашиваю нужен ли он первичный ключ ведь занимает места до ..я 1.7Gb, реплицировать мне ничего не надо и ссылаться на конкретную запись тоже не надо нужно лишь ссылаться на группу записей относящихся к конкретному случаю (по полю КодСлучая), удалять тоже ничего не надо записи сами каскадно удалятся при удалении некоторого Случая редактирование конкретной записи тоже не нужно нужна пока что лишь статистика по этим данным (это пока, неизвестно что через месяц может понадобиться). Меня интересует вопрос связано ли удаление первичного ключа с временами 5-10 минутными жжужаними винта возникающими примерно через час,два. А то после того как я удалил его это и началось. Я никак не пойму чем SQL Server занимается гоняя винт когда его не просят, ведь до этого не было. Может он статистики пересчитывает, но какого черта их пересчитывать как в базу пока уже неделю ничего недобавляется.

Спасибо Glory действительно опция Auto Shrink установлена была. Теперь может перестанет жужать.
С этим я согласен что добавление поля ID не сильно увеличит размер базы. Но я говорю про место занимаемое первичным ключом а не полем. Может я не прав что 1.7 Gb, но помоему так оно и есть так как Index Tuning Vizard показывает о использовании в % некоторого ключа в запросе и о его размере. Так вот там указан размер 1725480 Кб. Может я не правильно чего понял? Но размер базы примерно так и вырос.