2 Gt
Вообще-то в хелпе написано так:

The Microsoft® SQL Server™ 2000 dynamic locking strategy automatically chooses the best locking granularity for queries in most cases. In cases where access patterns are well understood and consistent, limiting the locking levels available for an index can be beneficial.

For example, a database application uses a lookup table that is refreshed weekly in a batch process. The most efficient locking strategy is to turn off page and row locking and allow all concurrent readers to get a shared (S) lock on the table, reducing overhead. During the weekly batch update, the update process can take an exclusive (X) lock, and then update the entire table.

The granularity of locking used on an index can be set using the sp_indexoption system stored procedure. To display the current locking option for a given index, use the INDEXPROPERTY function. Page-level locks, row-level locks, or a combination of page-level and row-level locks can be disallowed for a given index.

И чё-то я не понял вашего удивления Так что теперь я должен каждый раз приписывать rowlock ??? и чем мне это грозит на 10 млн записях ?
Вы что пишите select для каждой записи? В любом случае согласитесь, что если Вы собрались делать нечто не совсем стандартным способом, надо как-то это серверу указать.

Да еще забавный пример там был, блокировка по диапозону индекса, типа мне не дадут вставить запись если кто-то в данный момент просматривает (залочел) этот дипазон индекса.
Наверное лучше сказать так: вставка будет произведена после того, как кто-то просмотрит тот диапазон. Не факт что это медленнее, чем создание новой версии диапазона, как это делается в Оракле или Интербейзе.