СОВЕТЫ

Основы выбора оптимального размера базы данных
По материалам статьи Брайан Найт (Brian Knight) на sqlservercentral.com: " The Basics of Sizing a SQL Server Database"
Перевод Serhiy Snisarenko

Выбор оптимального размера базы данных является непростой задачей, которую должны решать администраторы, аналитики или разработчики. Анализ базы данных занимает много времени, прежде чем правильное решение будет найдено. В данной статье рассказывается, как следить за размером базы данных после ее создания и содержится несколько советов по выбору оптимального размера базы данных до ее создания.
Итак, какое оборудование необходимо приобрести для вашей базы данных? От вашего ответа зависит будет ли это SAN или достаточно несколько RAID 1 дисков. К счастью, существует несколько продуктов, которые достаточно точно определяют размер базы данных до ее создания. Например, вы можете использовать ERwin (продукт компании CA) для определения размера вашей базы данных через X месяцев. Вы также можете заполнить базу произвольными данными используя продукты, сходные с Datatect 1.6. Те, кто чувствует в себе смелость, могут выполнить вычисления самостоятельно, но будте внимательны с индексами. Когда большинство людей рассчитывают размер баз данных без помощи специальных продуктов, они забывают учитывать место, необходимое для индексов, вторичных ключей и констрейнтов.
Легче всего вычислить размер базы данных с помощью программ моделирования баз данных, таких как ERwin. ERwin, как и большинство программ моделирования баз данных, имеет панель размера БД, которая позволяет вам указать множество параметров при создании таблицы. В ERwin вы можете указать:

- начальное количество строк
- количество ежемесячно добавляющихся строк
- будет ли столбец содержать NULL

Сочетание этих трех факторов может дать специализированному продукту возможность сгенерировать достоверные отчеты о размере базы данных через некоторое время. Эти отчеты могут быть выполнены в HTML формате, и их даже можно просматривать с помощью обьектов. Большинство программ моделирования баз данных учитывают индексы, вторичные ключи и констрейны. Единственная вещь, которую не учитывает Erwin, это индексированные представления, которые могут занимать существенное место, если они основываются на больших таблицах.
Когда вы имеете общее представление о том, какого размера будет ваша база данных, вы можете проверить вашу теорию с помощью такого продукта, как Datatect 1.6(www.datatect.com). Datatect позволяет вам создать реалистичные произвольные данные для заполнения вашей БД. При этом также учитывается, что загружаемые данные имеют вторичные ключи. После того, как автор статьи перепробовал все другие генераторы данных, он склонен находить, что Datatect 1.6 оказался самым удобным средством для загрузки значительного обьема произвольных данных в его БД. Автор статьи считает, что другие генераторы данных работают неустойчиво и могут легко нарушить работу CPU.
Итак, почему желательно заполнять БД тестовыми данными? Несколько месяцев назад автор использовал ERwin для проектирования базы данных нового продукта, размер которой через 6 месяцев эксплуатации должен был составлять 50 Гб. Разработчики продукта использовали для тестовую БД, содержавшую всего несколько сотен простых записей и не могли понять особенностей реализации для баз такого размера. После заполненния БД с использованием Datatect они получили возможность найти дефекты в приложении, которые могли бы привести к краху сервера через 6 месяцев, когда БД уже будет в промышленной эксплуатации.
С помощью Datatect я заполнил 10 Гб таблицу реалистичными, тестовыми данными за 12 часов. Та же задача с помощью подобного продукта другой, более крупной фирмы, заняла больше 8 дней. Перед загрузкой данных убедитесь, что вы убрали все кластерные индексы. В противном случае время загрузки значительно возрастет. Как только вы имеете тестовую БД вы можете использовать такие программы, как WinRunner, которые позволяют измерить производительность, что бы увидеть, как приложение работает с таким большим количеством записей.
Заключительный совет: следите и изучайте (смотри и учись!). Вы можете пользоваться этим советом, когда хотите достаточно точно определить размер БД и затем воспользоваться полученными прогнозами при установке сервера. Когда автор устанавливает сервер, он создаёт таблицу на каждом сервере, в которой ведёт статистику роста БД. Каждую неделю фиксируется информация о размере каждой БД и копируется в электронную таблицу. Используя данные из электронной таблицы можно построить график для прогнозирования размера БД через год.
Ниже приводится пример хранимой процедуры, с помощью которой вы можете получать необходимые статистические данные:
http://www.sqlservercentral.com/columnists/bknight/usp_database.sql

/* Procedure for 8.0 server */
create proc usp_databases
as
  set nocount on
  declare @name sysname
  declare @SQL nvarchar(600)

  /* Use temporary table to sum up database size w/o using group by */
  create table #databases (
            DATABASE_NAME sysname NOT NULL,
                size int NOT NULL)

  declare c1 cursor for
      select name from master.dbo.sysdatabases
        where has_dbaccess(name) = 1 -- Only look at databases to which we have access

  open c1
  fetch c1 into @name

  while @@fetch_status >= 0
  begin
    select @SQL = 'insert into #databases
            select N'''+ @name + ''', sum(size) from '
            + QuoteName(@name) + '.dbo.sysfiles'
        /* Insert row for each database */
        execute (@SQL)
        fetch c1 into @name
  end
  deallocate c1

  select
        DATABASE_NAME,
        DATABASE_SIZE = size*8,/* Convert from 8192 byte pages to K */
        RUN_DT=GETDATE()
  from #databases
  order by 1

GO

Правда, о fill-factor в MS SQL Server
По материалам статьи Kalen Delaney на sqlmag.com: " The Fill-Factor Truth"
Перевод Александра Гладченко

Две недокументированные команды помогут разрешить загадку fill-factor

Индексы и fill factor

Сначала, мы должны понять основы того, как организованы индексы. SQL Server организовывает индексы как Би-дерево, с одной корневой страницей, являющейся отправной точкой для построения индекса. Корневая страница может иметь указатели на две или более страницы следующего уровня индекса, и, каждая из этих страниц, может иметь указатели на множество страниц следующего уровня. Последний уровень индекса - это уровень листьев, который должен содержать все индексные ключевые значения в сортируемой последовательности. В SQL Server 2000 эта последовательность может быть или возрастающей или в порядке убывания. Более ранние версии поддерживали все индексы в порядке возрастания. В кластерном индексе, уровень листьев - хранит данные, так что SQL Server хранит данные в отсортированном порядке. В не кластерном индексе, уровень листьев содержит указатели на данные. Fill factor - значение, которое Вы можете определить при создании индекса, чтобы сообщить SQL Server, насколько заполненными Вы хотите иметь страницы индекса. Вы можете определить fill factor в инструкции CREATE INDEX или когда Вы используете инструкцию CREATE TABLE или ALTER TABLE для определения первичного ключа или уникального ограничения на таблицу, после чего SQL Server автоматически построит индекс, и установит первичные ключи и уникальные ограничения. Конечно, Вы также можете определить fill factor, используя Enterprise Manager, при создании индекса или добавлении ограничений к таблице. Если Вы не определяете явно значение fill-factor, SQL Server установит значение fill factor по умолчанию. Чтобы определить, какое было принято значение fill factor по умолчанию, Вы можете выполнить следующую команду:

Вначале, нужно установить расширенный вывод конфигурационных значений:

EXEC sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO

Затем, непосредственно смотрим значение по умолчанию 'fill factor':

EXEC sp_configure 'fill factor'
GO

В завершение, возвращаем изменённое значение назад:

EXEC sp_configure 'show advanced options', 0
GO
RECONFIGURE
GO

Если Вы не изменяли значение по умолчанию, Вы сможете увидеть в отчёте значение fill factor для параметра run_value (значение, используемое в настоящее время), установленное в "0":

Name………………minimum….maximum….config_value….run_value
---------------------------------------------------------------------------------------
fill factor (%)………0…………..100…………0………………0……….

fill factor установленный в "0" будет означать, что страницы индекса будут полностью заполнены, но в верхних уровнях индекса оставлено место для одной - двух индексных строк, которые могут быть добавлены позже. Фактически, Вы явно никогда не сможете присвоить fill factor значение "0" при создании индекса, потому что "0" является недопустимым значением для команды CREATE INDEX. Единственный способ получить fill factor равный "0" состоит в том, чтобы принять значение по умолчанию, если Вы не изменяли его до этого. Вы можете изменить значение fill factor по умолчанию, выполнив команду sp_configure и добавив второй параметр, который должен соответствовать желаемому, новому значению fill factor по умолчанию:

EXEC sp_configure 'fill factor', 80
GO
RECONFIGURE
GO

Вы должны остановить и перезапустить SQL Server для того, чтобы изменения вступили в силу. Новый fill factor будет действительно установлен, когда Вы увидите новое значение в столбце run_value.
Если Вы создаете индекс с fill factor = 80, страницы будут на 80 процентов заполнены, и верхние уровни индекса будут иметь достаточно места, оставленного в них для учёта одной или двух индексных строк.
Обратите внимание, что SQL Server не поддерживает оригинальное значение fill-factor, в момент добавления к таблице новых строк. fill factor только управляет степенью заполнения ваши страницы при первоначальном создании индекса. SQL Server хранит первоначальное значение fill factor в системной таблице sysindexes, в столбце OrigFillFactor. Если Вы выполняете команду DBCC DBREINDEX, которая перестраивает один или все индексы таблицы, определение fill factor равным "0" сообщает SQL Server, что необходимо перестроить индексы с оригинальным значением fill factor, и что индекс будет построен не обязательно со значением по умолчанию, которое Вы установили для вашего сервера.
Значение fill-factor может быть важно в среде, где выполняется очень много вставок. Уровень листьев индекса должен хранить все индексные, ключевые значения в сортируемой последовательности, так, что если кто-то будет вставлять новую строку в таблицу, индексное, ключевое значение в этой строке будет определять позицию строки в индексе (или таблице, если индекс кластерный). Например, если Вы имеете индекс по имени человека, вставка строки с именем "Marlin" потребует, чтобы SQL Server вставил новую индексную строку в ту же самую страницу с другими именами, которые начинаются на "Ma", возможно, между Margolin и Martin. Если страница, которой новая строка должна принадлежать, полностью заполнена, SQL Server разобьет её и свяжет с новой страницей в цепочку страницы. SQL Server переместит приблизительно половину строк из первоначальной, заполненной страницы в новую страницу. Мало того, что такое разделение страниц является ресурсёмкой операцией, которая может заметно сказаться на эффективности операций вставки, но вследствие того, что новая страница вероятнее всего окажется физически не непрерывной по отношению к первоначальной странице, Вы получите в результате фрагментацию индекса или таблицы.
Создание индекса с низким значением fill factor означает, что в вашей таблице зарезервировано место для последующего роста, что предотвращает разбиение страниц, откладывая, таким образом, связанные с этим проблемы. Однако, если ваши страницы заполнены только частично, чтобы хранить данные потребуется большее количество страниц и индекс может достичь весьма большого размера. Микрософт определил значение по умолчанию для fill-factor равное "0", как компромисс между наличием места для последующего роста и минимизацией размера таблицы и её индексов после создания. С fill factor = "0", уровень листьев будет заполнен, но страницы в верхних уровнях индекса, которые могут быть подвержены разбиению, если они станут заполненными, имеют некоторый резерв места для последующего роста.
В версиях SQL Server до 6.5, значение fill-factor = "100" подразумевало, что не только уровень листьев индекса, но и все уровни были бы полностью заполнены. Вообще, это значение используется только для таблиц, которые являются read-only (только для чтения). В SQL Server 6.5, Микрософт добавил новую опцию к команде CREATE INDEX. Если Вы также включаете опцию WITH PAD_Index, безотносительно значения fill-factor, Вы предпишете серверу устанавливать значение fill-factor всем уровням индекса, а не только уровню листьев. Так, создание индекса со значением fill-factor = "0" и включение опции PAD_Index, будет иметь тот же самый эффект, как использование значения fill-factor = "100". Но что будет, если fill factor = "100" с обычным значением PAD_Index?
Обратите внимание, что Вы можете определить значение fill-factor при определении первичного ключа или уникального ограничения на таблицу, потому что SQL Server автоматически строит индекс, чтобы поддержать эти ограничения. Однако, Вы не можете определить опцию PAD_Index одновременно с ограничением. Вы можете использовать её только в инструкции CREATE INDEX.

Загадка

Начинаясь с SQL Server 7.0, автор часто встречал такой вопрос: "Каково реальное различие между fill factor = "0" и fill factor = "100"?". Хотя SQL Server 2000 и 7.0 Books Online (BOL) сообщают, что fill factor = "100" означает, что все уровни индекса будут заполнены, много людей, очевидно, не думают, что это правда. Для исследования такого различия, автор использовал две недокументированные команды DBCC: DBCC IND и DBCC PAGE. Эти команды не перечислены в BOL, и Микрософт официально не поддерживает их, хотя статьи Микрософт иногда упоминают DBCC PAGE. Чтобы использовать эти недокументированные команды, Вы должны сначала установить флаг трассировки 3604, чтобы разрешить вывод недокументированных команд DBCC на экран клиента. DBCC IND, который требует три параметра, сообщает какие страницы принадлежат индексу. Первые два параметра: имя базы данных и имя таблицы; третий параметр устанавливает, какие результаты Вы хотите видеть в отчёте. Значение = "1", для третьего параметра степени подробность выводимой информации, говорит о том, что будут возвращены данные обо всех уровнях всех индексов в таблице. Код в Листинге №1 (см. в конце данной статьи) создает таблицу в 1000 строк в базе данных Pubs и генерирует последовательно увеличивающиеся целочисленные значения от 1 до 1000. Автор использует числовые значения, потому что они очень просто генерируются. Однако, он хранит их как символьные строки, потому что команда DBCC PAGE отображает символьные строки более ясно чем числовые значения, что удобно, если использовать команду DBCC PAGE для отображения полного содержания страниц.
После генерации 1000 строк, сценарий использует значение по умолчанию fill factor = 0, чтобы создать уникальный, кластерный индекс, затем используется DBCC IND, чтобы сгенерировать список всех страниц, которые принадлежат таблице и её индексам. DBCC IND возвращает 12-столбцов отчёта, но автору необходимы были только четыре из них:

- PagePID - идентификатор страниц, это значение будет использоваться во второй команде DBCC.
- IndexID - значение равное "0" устанавливается для страниц данных, "1" для страниц в верхних уровнях кластерного индекса, а большее чем "1" для не кластерных индексов.
- PageType - значение равное "1" устанавливается для страниц данных, "2" для индексных страниц, а "10" для страницы Index Allocation Map (IAM).
- IndexLevel - уровень индекса, на котором страница создана. Если IndexID равен "0", значит, IndexLevel также равен "0". Самое высокое значение IndexLevel у любого IndexID - для корневых страниц, причём, только одна страница будет иметь это максимальное значение IndexLevel.

Команда DBCC IND в сценарии Листинга №1 возвращает номера страниц для четырех страниц с PageType = 2; из них, три имеют IndexLevel = 0, а одна имеет IndexLevel = 1. Кроме того, если Вы работаете с базой данных, которая размещается более чем в одном файле, Вам будет также интересен столбец PageFID, который идентифицирует файл, содержащий страницу.

Примечание автора перевода: Если Вы используете для проверки приводимых в статье примеров кода вариант движка MSDE или у Вас не установлена база данных pubs, Вы можете отдельно установить её методом прикрепления из стандартного дистрибутива. Для MS SQL Server 2000 выглядеть это будет так: из дистрибутива, каталог …x86\DATA, скопируйте в нужное Вам расположение файлы pubs.mdf и pubs_log.ldf; снимите у этих файлов атрибут - только для чтения; в программе Enterprise Manager, посредством опции Databases\All Tasks\Attach Database прикрепите указанные файлы, откорректировав (если это необходимо) пути к их местоположению. После этого, вы получите сообщение об успешном прикреплении базы pubs и можете с ней работать.

Даже притом, что уровень листьев кластерного индекса хранит непосредственно данные, результат работы команды DBCC IND не рассматривает страницы данных как индексные страницы. Однако, эти будут именно те страницы данных, к которым относится значение fill factor, потому что они относятся к уровню листьев кластерного индекса. Вы можете идентифицировать эти страницы данных по следующей комбинации значений: PageType = 1, IndexID = 0, IndexLevel = 0.

Разгадка

Далее, для ответа на наш вопрос, выберем одну из страниц индекса и используем её, как параметр в команде DBCC PAGE. В SQL Server 2000 и 7.0 эта команда использует четыре параметры. Первый - это имя базы данных или идентификатор базы данных; второй - это номер файла; а третий - это номер страницы, полученный из отчёта DBCC IND. Четвертый параметр - это желательный формат отчёта. Например, значение четвёртого параметра, равное "0" устанавливает то, что Вы хотите видеть только колонтитул. Ниже представлена команда, которую выполнял автор статьи:

DBCC PAGE (pubs, 1, 285, 0)

Примечание автора перевода: третий параметр выбирайте из реальных результатов отчёта работы команды: DBCC IND(pubs, ff1, -1), полученного в вашем варианте установки базы pubs. Значение "285" может оказаться за рамками вашего распределения страниц.

Значение в колонтитуле, которое нам должно быть интересно, называется m_slotCnt. Оно сообщает число строк на заданной странице. Когда автор выполнил сценарий в Листинге №1 и затем использовал DBCC PAGE, чтобы посмотреть на одну из страниц данных, он увидел, что число строк на странице было равно 20-ти. Когда он аналогично выполнил DBCC PAGE для одной из индексных страниц на более низком уровне, чем корень, он увидел, что число строк там было равно 19-ти. Это было результат, который автор ожидал увидеть, т.е. страницы данных были заполнены строками, содержащими 390 байтов данных, плюс приблизительно 10 байт сверху, а значит, только 20 строк возможно разместить на одной странице, и страницы данных максимально заполнены. Строки индексов имеют тот же самый размер, потому что индекс строится на основе столбца случайных чисел (390), но вместо 20 индексных строк на странице, мы имеем только 19, потому что SQL Server зарезервировал место для одной дополнительной индексной строки.
Используя эти два инструментальных средства, DBCC IND и DBCC PAGE, автор смог ответить на вопрос о различие между fill factor = 0 и fill factor = 100. Выполняя тот же самый сценарий, но, явно устанавливая factor = 100, автор обнаружил, что число строк в страницах данных и индексных страницах было тем же самым, что и у кластерного индекса с fill factor = 0. Автор полагает, что дал Вам достаточно информации о том, как использовать эти инструментальные средства, чтобы Вы могли убедиться в полученных им результатах самостоятельно и смогли выполнить более глубокое исследование. Вы можете также узнать, что случается, если Вы установите опцию PAD_Index, при fill factor = 100.

LISTING 1: Script to Create Table and Index, Then Generate Page List

USE pubs
GO
CREATE TABLE ff1(col1 char(390) NULL)
GO

SET NOCOUNT ON
GO
DECLARE @i int
SET @i = 1
WHILE @i < 1001 BEGIN
  INSERT INTO ff1 SELECT CONVERT(char(390), @i)
  SET @i = @i + 1
END
GO
CREATE UNIQUE CLUSTERED INDEX indx1 on ff1(col1)
GO
DBCC TRACEON (3604)
GO
DBCC IND(pubs, ff1, -1)
GO

ПОЛЕЗНОСТИ

Новости проекта SQL.RU

Закончилась моя поездка в Москву, в рамках которой были проведены несколько встреч с инициативной группой RSUG. Отчёт о результатах этих встреч будет опубликован в специально созданной для этого теме форума: Отчёт

Новые технические статьи Microsoft

Q164667 - INF: Replication Setup Over a Firewall
Q184008 - FIX: SQL Server Cluster Setup May Fail on Third-Party Disk Drives
Q217034 - PRB: Two Digit Year Display of Date Fields in SQL Enterprise Manager (SEM)
Q219264 - INF: Order of Installation for SQL Server 7.0 Clustering Setup
Q221777 - BUG: "Cannot Start Service" Error Starting OLAP Services
Q231951 - INF: Permission Needed for Administering an OLAP Server
Q238912 - INF: Understanding Microsoft Repository
Q239473 - PRB: 70rebind.exe for Windows 2000 and MDAC Upgrades on Clustered SQL Server 7.0 Servers
Q240872 - INF: How to Resolve Permission Issues When a Database is Moved Between SQL Servers
Q242391 - INF: DTS Package Development, Deployment and Performance
Q247110 - PRB: Replication Must be Removed Before Applying Service Pack
Q247641 - FIX: Trusted TCP/IP Socket Connection May Fail with Error Message 18452
Q248441 - FIX: Incorrect Results with Self Insert and Subquery
Q254321 - INF: Clustered SQL Server Do's, Don'ts and Basic Warnings
Q254369 - INF: SQL Server 7.0 Service Pack 2 Fixlist
Q257267 - Unable to Serve ASP or HTML Pages
Q258025 - PRB: Users Registered in SQL Server as Part of a Local Group on PDC/BDC Are Unable to Connect
Q272424 - INF: Object Ownership Chain Checking Across Databases Depends on Database Ownership
Q273914 - INF: Readme.txt for SQL Server 6.5 Post Service Pack 5a Update
Q274224 - FIX: Using SQL Server 2000 Merge Modules May Result in Confusing Message
Q274463 - INF: Understanding and Troubleshooting the Copy Database Wizard in SQL Server 2000
Q275583 - PRB: SELECT...FOR XML AUTO Results Are Separated into Lines of 2033 Chars with ODBC
Q279857 - BUG: Error 3910, "Transaction Context in Use by Another Session"
Q280720 - FIX: xp_sendmail Generates UNICODE CSV File Format
Q281879 - INF: How DBCC SQLPERF (Logspace) Reports Percentage Used
Q287932 - INF: TCP Ports Needed for Communication to SQL Server Through a Firewall
Q290212 - INF: List of Bugs Fixed in SQL Server 2000 Service Pack 1 (1 of 2)
Q296612 - FIX: Large Array of IN Clause Parameters Parses/Compiles Slower on SQL Server 2000
Q294872 - FIX: Update on a Table with INT and BIT Columns May Zero Out INT Columns
Q298012 - Malformed RPC Request Can Cause Service Problems
Q295305 - PRB: Creating Temp Table Inside IF and ELSE Conditions Gives Error 2714
Q295589 - PRB: Upgrading SQL Server 2000 SP1 to a Cluster Virtual Server May Result in Use of Mixed Binaries
Q298570 - BUG: Virtual SQL Server 2000 Installations May Fail if Installed to Windows 2000 Domain Controllers
Q298897 - SAMPLE: Mapsids.exe Helps Map SIDs Between User and Master Databases When Database Is Moved
Q299452 - BUG: Copy Database Wizard Exits Without Error if any of the Source Databases are in Single User Mode
Q300181 - FIX: DTS Error Message Repeated Multiple Times When You Import from a Text File
Q300488 - HOWTO: Run SQL Server Stored Procedures from an ASP Page
Q300391 - FIX: Profiler Replay Output File Does not Show Events When Looking at Properties
Q300597 - BUG: NOT FOR REPLICATION Clause Causes SQL Server CE Replication to Fail
Q301334 - PRB: Connection Timeout Occurs When Connecting to a Remote OLAP Server Using an ADO Connection
Q301456 - INF: How to Use OLAP Number Formats with Office Web Components
Q301901 - INF: TCP Ports Used by OLAP Services when Connecting Through a Firewall
Q301934 - INF: MDX: How to Determine the First or Last Member with Data
Q301936 - FIX: Merge Agent Fails with Access Violation in Replprov.dll if Publication has Horizontal Partitioning
Q302423 - BUG: Execution of RAISERROR(@@ERROR) Causes Access Violation
Q302477 - FIX: Cursor Created on Linked Server That Requests Meta-Data May Cause Handled Access Violation
Q302675 - FIX: Delete on Nonindexed Column Fails with Error 1203
Q304118 - INF: How To Perform Time Series Calculations
Q303005 - FIX: SQL Server Performance Condition Alerts do not Fire After You Install SQL Server 2000 Service Pack 1
Q304261 - INF: Support for Network Database Files
Q304372 - BUG: SQLOLEDB May Fail with Parameterized Queries
Q303229 - PRB: Transaction Log Backup Job Created with Database Maintenance Planner Fails
Q303287 - BUG: DTC Transactions May Fail When SQL Server Is Running in Lightweight Pooling Mode
Q303411 - PRB: SQL Server 1355 Warning Errors are Informational
Q303438 - PRB: Unable to See All Cubes When Connecting from Excel 2000 to Analysis Services
Q303445 - PRB: ObjectID Filter in SQL Profiler Triggers Only with Specific Events
Q303467 - BUG: Unattended Installation of Service Pack 1 Fails with No Errors
Q303722 - INF: How to Grant Access to SQL Logins on a Standby Database When "guest" User Is Disabled
Q303667 - BUG: BOL Incorrectly States That the xp_readmail @suppress_attach Option Defaults to TRUE
Q304551 - FIX: Merge Publishing with Vertical Filters Results in Nonconvergence
Q303789 - INFO: Using MSDE 2000 With SQL Server CE RDA and Replication
Q304711 - PRB: SQL Server 2000 Service Pack 1 Setup Fails with No Errors
Q305042 - FIX: UPDATE After ALTER TABLE Can Result in Unexpected Data to Added Columns
Q305387 - BUG: UpdateBatch Generates SQL Statement That Cannot Reuse SQL Server Query Plans
Q305573 - FIX: Return Code of xp_findnextmsg Changed to 1 Against an Empty Inbox
Q305711 - BUG: DBO User Does Not Display in Enterprise Manager
Q305576 - FIX: Regression: AV When xp_findnextmsg Is Invoked Against an Empty Inbox
Q105857 - PRB: @@error Not Set After Overflow or Divide-by-Zero Error
Q107561 - INF: Assignment of Empty Results Set Does Not Set Variable
Q122352 - INF: Supported Windows Versions for SQL Server
Q137899 - BUG: SQL Counters Not Available Under Integrated Security
Q142743 - INFO: Rebuilding SQL Server Registry Entries After Last Known Good
Q158736 - Creating Devices in SQL is Slow with Removable Media Installed
Q192708 - INF: Order of Installation for SQL Server 6.5 MSMQ 1.0 Clustering Setup
Q291376 - FIX: Cannot Use Dynamic SQL Statements Within OPENQUERY
Q300164 - INF: How to Set Up an Identity Column on both the Publisher and the Subscriber with Transactional Replication
Q300500 - FIX: Server Name is not Being Populated on the Client Side (UI or File) in SQL Server Profiler
Q300380 - FIX: Intense Database Backup Stress Causes BackupSync to Generate an Assertion when Releasing Memory
Q303664 - BUG: SP_PROCESSMAIL May Fail with Error 18023
Q64842 - INF: Global Variable @@error Checks for Successful Completion
Q299905 - INF: Data Types Used by Analysis Services
Q303215 - Microsoft Network Security Hotfix Checker (Hfnetchk.exe) Tool Is Available
Q304716 - FIX: Access Violation in RepODBC.dll When You Try to Connect to Repository
Q305385 - Frequently Asked Questions about the Microsoft Network Security Hotfix Checker (Hfnetchk.exe) Tool

ФОРУМ SQL.RU: САМЫЕ ПОПУЛЯРНЫЕ ТОПИКИ НЕДЕЛИ

Посоветуйте, на чём лучше писать клиенское ПО for MS SQL 2000?
Альтернатива *
Encrypt data by User defined functions SQL 2000
Как заблокировать доступ к таблице?
Репликация. Менять все и везде! А можно?
MS SQL Server и кэширующие дисковые контроллеры
Немного о SQL server ! (Backup & Restore)
Есть ли смысл создавать не ключевые и не кластерные индексы в MS SQL Server 7.0?
Где есть описание недокументированных хр процедур sql server 7.0
Запросик слабенький
Добавление нескольких значений при помощи одного INSERT'a.
Исполнение скрипта из АDODB (может и офф)
Отбор записей начиная с определенного номера, и заканчивая другим
После отключения питания упала производительность
CREATE and CHANGE STRUCTURE TABLE
А как проинсталировать SQL Mail !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
А как проверить существование временной таблицы ???
CREATE DATABASE
Как оставить только одну из нескольких повторившихся записей
Где можно найти список отличий в правах между SQL юзером и NT юзером?
Чтение файлов в T-SQL

ФОРУМ SQL.RU: ВОПРОСЫ ОСТАЛИСЬ БЕЗ ОТВЕТА

Description's Import/Export
Синхронизация таблиц Paradox и SQL Server
Вопрос по job????
Округления ()
Options ?
Глючит Enterprise Manager :(
sp_addlogin под securytyadmin без sysadmin.