Алгоритмы хранения данных и ведения журнала SQL Server 7.0, SQL Server 2000 и SQL Server 2005 повышают надежность данных

Переводы статьи Переводы статьи
Код статьи: 230785 - Vizualiza?i produsele pentru care se aplic? acest articol.
Развернуть все | Свернуть все

В этой статье

Аннотация

SQL Server 7.0, SQL Server 2000 и SQL Server 2005 реструктуризации и переработать алгоритмы ведения журналов и данных с предыдущими версиями Microsoft SQL Server для повышения надежности данных и целостность.

Дополнительные сведения о базовых понятий ядра SQL Server 7.0 и SQL Server 2000, см "ARIES (алгоритм для восстановления и семантика изоляции Exploiting): метод восстановления транзакции Supporting Fine-гранулярности блокировка и частичный откат упреждающее ведение журнала с помощью", ACM транзакций в базе данных системы. Этот документ был написан с Chunder Mohan.

Этот документ предназначен для технологии SQL Server 7.0, SQL Server 2000 и SQL Server 2005 для увеличения надежности данных и целостность применительно к сбоям.

Рекомендуется ознакомиться со следующей статьи базы знаний Майкрософт, для дальнейшего уточнения некоторых кэширования и изучения режима сбоя:
86903 Описание кэширование контроллеры дисков в SQL Server
46091 С помощью контроллера жесткого диска, кэширование с SQL Server
234656 С помощью кэширования диска с SQL Server

Дополнительная информация

Прежде чем начать подробное обсуждение, некоторые термины, используемые в этой статье определены в следующем разделе.
Свернуть эту таблицуРазвернуть эту таблицу
ТерминОпределение
Резервным питанием от батареиБатареи отдельно и локализованные средство резервного копирования непосредственно доступны и управляется механизм кэширования во избежание потери данных.
Примечание Это не является источником бесперебойного питания (ИБП). ИБП не гарантирует любые операции записи и могут быть отключены от кэширования устройства.
Кэш-памятиПромежуточное хранение механизм оптимизации физических операций ввода-вывода и улучшения производительности.
«Грязные» страницыСтраница, содержащая изменения данных, еще не были записаны на диск в постоянном хранилище. Для получения дополнительных сведений, относящихся к «грязная» страница буферов в документации SQL Server Books Online.
СбойВсе, что может привести к неожиданным сбоя процесса SQL Server. Примеры включают: питания, сбоя в работе, перезагрузки компьютера, ошибок памяти, других проблем с оборудованием, поврежденных секторов, перебои в работе диска, сбои операционной системы и т. д.
ОчиститьФорсирование кэш буфера в сохраняемое хранилище.
ЗащелкаОбъект синхронизации, используемый для защиты физической целостности ресурса.
Энергонезависимое хранениеЛюбой носитель, доступный через сбои системы.
Закрепленные страницыСтраница, которая остается в данных в кэше и нельзя очистить в постоянном хранилище, пока все связанные записи защищены в постоянном хранилище месте.
Стабильность храненияТак же, как энергонезависимой памяти.
Временного храненияЛюбой носитель, будет не через сбоев остаются без изменений.
SQL Server 2005, SQL Server 2000, SQL Server 7.0, более ранних версиях SQL Server и многие популярные базы данных продуктов на рынке сегодня протокол упреждающее ведение журнала Упреждающей записью.

Упреждающее ведение журнала Упреждающей записью протокола

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

ARIES документ определяет понятия WAL как:
Протокол понятия WAL утверждает, что записи журнала, представляющий изменения некоторые данные должны уже представлять в постоянном хранилище до разрешения измененные данные для замены предыдущей версии данных в ПЗУ. Т.е., система не может записать обновленные страницы Энергонезависимое хранение версию страницы, пока хотя бы части отмены записи журнала, описывающие обновления страницы были записаны в сохраняемое хранилище.
Для получения дополнительных сведений о упреждающее ведение журнала в документации SQL Server Books Online.

SQL Server и понятия WAL

SQL Server 2005, SQL Server 2000, SQL Server 7.0 и более ранних выпусках SQL Server использовать протокол понятия WAL. Чтобы обеспечить правильное committal транзакции, в постоянном хранилище должны быть защищены все записи журнала, связанные с транзакцией.

Чтобы прояснить это, рассмотрим следующий пример, конкретные (для этого примера предположим, что отсутствует индекс с особой страница является страницей 150).
BEGIN TRANSACTION
   INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
				
Теперь разбейте деятельность на действия упрощенную ведения журнала:
Свернуть эту таблицуРазвернуть эту таблицу
ИнструкцияВыполненные действия
НАЧАЛО ТРАНЗАКЦИИЗаписи возникли области кэш журнала необязательно для очистки в постоянном хранилище, так как SQL Server не выполнил все физические изменения.
INSERT INTO tblTest1. Данные страницы 150 загружаются в кэш данных SQL Server, если уже есть.

2. На странице заблокирована, закрепить, и помечены как изменившиеся, и получить соответствующую блокировку.

3. Записи журнала вставки создан и добавлен в кэш журнала.

4. Новая строка добавляется к странице данных.

5. Блокировка освобождается.

6. Записи журнала, связанные с транзакцией, или страница не обязательно сбрасываются на этом этапе, так как все изменения сохраняются в энергозависимой памяти.
ЗАФИКСИРОВАТЬ ТРАНЗАКЦИЮ1. Запись журнала фиксации формируется и записи журнала, связанные с транзакцией, должны быть записаны в сохраняемое хранилище. Транзакция считается не фиксируется до записи журнала правильно назначаются в постоянном хранилище.

2. Данные страницы 150 остается в кэше данных SQL Server и не очищается немедленно в постоянном хранилище. При записи журнала будут должным образом безопасного восстановления можно повторять операции, при необходимости.

3. Транзакций блокировки снимаются.
Нельзя путать с блокировкой и ведение журнала. Хотя важно, блокировки и ведения журнала, отдельные проблемы при работе с понятия WAL. В приведенном выше примере SQL Server 7.0, SQL Server 2000 и SQL Server 2005 обычно содержат кратковременной блокировки страниц 150 раз необходимые для выполнения изменений физического вставки на странице, не в течение всего времени транзакции. Тип соответствующей блокировки устанавливается для защиты строк, диапазон, страницы или таблицы по мере необходимости. Ссылки на разделы документации по SQL Server блокировки более подробные сведения о типах блокировки.

Глядя на примере более подробно, может возникнуть вопрос, что происходит, когда выполнение процессов отложенной записи или контрольной точки. SQL Server 7.0, SQL Server 2000 и SQL Server 2005 выдавать все соответствующие сбросов в сохраняемое хранилище для записей журнала транзакций, связанный со страницей «грязный» и закрепленные. Это обеспечивает протокол понятия WAL страницы данных никогда не могут быть написаны в сохраняемое хранилище, пока не были сброшены записи связанного журнала транзакций.

SQL Server и стабильность хранилищ

SQL Server 7.0, SQL Server 2000 и SQL Server 2005 улучшить операции страницы журналов и данных, включая знание размеров сектора диска (обычно 512 байт).

Чтобы сохранить свойства транзакции ACID, SQL Server необходимо учитывать точки сбоя. При сбое многие спецификации диска гарантируют только ограниченный объем операций записи секторов. Большинство спецификаций гарантировать завершение записи одного сектора, при возникновении сбоя.

SQL Server 7.0, SQL Server 2000 и SQL Server 2005 с помощью страниц размером 8 КБ данных и журнала (если сброшен) на углы, кратные размеру сектора. (Большинство дисков используйте 512 байт размер по умолчанию сектора). В случае возникновения сбоя SQL Server может счета для операции записи больше, чем какой-либо сектор путем применения журнала четности и приемы, прерванная запись.

Обнаружение разорванных страниц

Следующий раздел поступает из SQL Server 7.0 Books Online описанием обнаружение разорванных страниц:
Этот параметр позволяет SQL Server для обнаружения незавершенных операций ввода-вывода, вызванные сбоями питания или другими перерывами в работе системы. При значении true приводит к небольшой нужно зеркально отразить для каждого 512-байтового сектора на странице базы данных 8-килобайтовой (КБ), каждый раз, когда страница записывается на диск. Если немного в неправильном состоянии при нахождении страницы в более поздних читается сервером SQL Server, затем страницы был записан неверно; Обнаружен разрыв страницы. Разрывы страницы обычно определяются во время восстановления, поскольку любой страницы, который был записан неверно, скорее всего, восстановления для чтения.

Хотя страниц базы данных SQL Server, 8 КБ, диски операции ввода-вывода с помощью 512-байтового сектора. Таким образом записывается 16 секторов на каждой странице базы данных. Разрыв страницы может возникнуть, если системе не удается (например, из-за сбоя питания) между операционная система записывает первые 512-байтового сектора на диске и завершением операции ввода-вывода 8 КБ. Если первый сектор страницы базы данных успешно записаны перед сбоем, страница базы данных на диске появится обновления, несмотря на то, что он не может успешно.

Использование кэша контроллера диска с питаемым от аккумулятора можно гарантировать, что данные успешно записаны на диск или не все записи. В этом случае не не набор разрыва страницы обнаружения true, для его не требуется.
Примечание Обнаружение разорванных страниц не включена по умолчанию в SQL Server 7.0. См. процедуры sp_dboption инструкции для включения обнаружения в системе.

Журнал четности

Проверка четности журнала очень похожа на обнаружение разорванных страниц. Каждого 512-байтового сектора содержатся биты четности. Эти биты четности всегда записываются с записью журнала и оцениваются при получении записи журнала. Заставляя журнала записывается на границе 512 байт, SQL Server 7.0, SQL Server 2000 и SQL Server 2005 можно обеспечить полностью запись операций committal секторах физического диска.

Эти изменения обеспечивают согласованность данных даже по сравнению с предыдущими версиями SQL Server.

В версиях сервера SQL Server 7.0

Ранние версии SQL Server 7.0 не предоставил журнал четности или средства обнаружения разрыва бит. На самом деле эти версии можно написать одну и ту же страницу журнала несколько раз до записи журнала заполнения страницы журнала 2 КБ. Это может привести к транзакции, которые успешно завершена. Если страница журнала придается во время сбоя, сектора с зафиксированных транзакций может не получить переписать должным образом.

Воздействие на производительность

Все версии SQL Server откройте файлы журналов и данных, с помощью Win32 Функция CreateFile функция. В dwFlagsAndAttributes включает в себя элемент FILE_FLAG_WRITE_THROUGH параметр при открытии приложением SQL Server.
FILE_FLAG_WRITE_THROUGH
Указывает, что система записи через любой промежуточный кэш и перейти непосредственно на диск. Система может кэшировать операции записи, но не удается сбросить пассивно их.

Параметр FILE_FLAG_WRITE_THROUGH гарантирует, что при записи операции возвращает успешного завершения правильного хранения данных в постоянном хранилище. Это выравнивание с протоколом понятия WAL, гарантируя данные.
Во многих дисках (SCSI и IDE) имеется встроенный кэш объемом 512 КБ, 1 МБ или больше. Однако кэша дисков обычно используют конденсатор и не решение резервным питанием от батареи. Такие механизмы кэширования не гарантирует запись во питания цикла или сходных точек сбоя. Они гарантируют только выполнение операций записи секторов. В частности это почему было проведено прерванная запись и обнаружения четности журнала в SQL Server 7.0, SQL Server 2000 и SQL Server 2005. Как дисков продолжают увеличиваться в размере, кэша и могут передавать большие объемы данных при сбое.

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

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

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

Упорядочение сектора

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

Кэш может содержать несколько журналов и запросы на запись данных в то же время. Понятия WAL протокол и реализация протокола понятия WAL SQL Server требуется очистка журнала записывает в сохраняемое хранилище до выдачи записать страницу. Однако использование кэша может возвращать из запроса записи журнала успех без данных, записываемых на фактический диск (т.е. записываются в сохраняемое хранилище). Это может привести к выдаче запроса записи страницы данных SQL Server.

С участием кэш записи данных по-прежнему считается в энергозависимой памяти. Однако из интерфейса Win32 API WriteFile вызов, точно так же, как SQL Server видит действия успешного возврата кода была получена. SQL Server или процесса с помощью WriteFile Вызов API можно вывести только данные правильно получил в постоянном хранилище.

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

При оценке факторов оптимизации производительности для сервера базы данных, существует много факторов, которые необходимо учитывать. Самая главная цель этих вопросов является «Моя система позволяет ли допустимые возможности FILE_FLAG_WRITE_THROUGH?»

Примечание Любой кэш-памяти при использовании необходима полностью поддерживают решение с резервным питанием от батареи. Все другие механизмы кэширования вызывают сомнения, повреждение данных и потерю данных. SQL Server прилагает все усилия для обеспечения понятия WAL, позволяя FILE_FLAG_WRITE_THROUGH.

Тестирование были показаны во многих конфигурациях дисков могут содержать кэширование записи без правильного батареи резервного копирования. Диски SCSI, IDE и EIDE в полном объеме записи кэша.

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

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

Запись кэша размещения

Запись кэша наложение похож на упорядочение сектора. Следующее определение был взят непосредственно из ведущих веб-узла производителя дисковода IDE:
Обычно этот режим активен. Запишите режим кэша принимает основное записи данных в буфер пока полный буфер или перемещения узла.

Начинается данная задача записи диска для хранения данных узла на диск. Запись команд по-прежнему приниматься и передавать данные в буфер пока полный стек команды записи или заполнен буфер данных. Диск может упорядочить записи команд для оптимизации пропускной способности диска.

Автоматическое перераспределение записи (AWR)

Другой распространенный метод используется для защиты данных является обнаружение поврежденных секторов во время обработки данных. Следующее объяснение поставляется с того же ведущих IDE диск изготовителя веб-узла:
Эта функция является частью кэширование записи и снижает риск потери данных во время операций отложенной записи. Если ошибка диска в процессе записи диска, останавливается задач диска и подозрительные сектор перераспределяется пула альтернативный секторов, расположенный в конце диска. После перераспределения задач записи диска продолжается до его завершения.
Это может быть очень мощным средством, если резервного питания от батареи для кэш-памяти, позволяя соответствующие изменения при перезагрузке. Предпочтительным для обнаружения ошибок на диске, но безопасность данных протокола понятия WAL снова потребуется это сделать реального времени, а не в отложенной манере. В пределах параметров понятия WAL AWR методика не может учитывать ситуации, когда записи журнала происходит сбой из-за ошибку сектора, но диск заполнен. Компонент database engine немедленно необходимо знать о сбое, так может быть должным образом прервана, администратор может получать оповещения и соответствующие действия, предпринимаемые для защиты данных и исправления ситуации сбоя носителя.

Безопасность данных

Существуют некоторые меры предосторожности, администратор базы данных следует предпринять для обеспечения безопасности данных.
  • Это всегда хорошая идея, чтобы стратегию резервного копирования достаточно для восстановления после серьезного сбоя. Подходят предусматривающего хранение данных и другие меры безопасности.
  • Проверка операции восстановления базы данных в дополнительной или тестовой базы данных на частое.
  • Убедитесь, что все устройства кэширования можно обрабатывать все ситуации сбоя (электроэнергии, поврежденных секторов, поврежденных дисков, сбоя в работе системы, зависание, Копилка питания и т.д.).
  • Убедитесь, что устройство кэширования:
    • Встроены резервной батареи.
    • Можно повторный выпуск записывает питание.
    • Можно полностью отключить при необходимости.
    • Обработка поврежденных секторов, преобразование в реальном времени.
  • Включение torn page detection; он имеет незначительное влияние на производительность.
  • Настройка дисков RAID, возможность горячей замены поврежденного жесткого диска, если это возможно.
  • С помощью новых контроллеры с кэшированием, позволяющие добавлять больше места на диске без перезагрузки операционной системы. Это может быть идеальным решением.

Проверка дисков

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

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

Корпорация Майкрософт произвела тестирование нескольких дисков SCSI и IDE с помощью SQLIOStress Служебная программа. Эта программа имитирует большой асинхронное чтение и запись действий смоделированных данных устройства и устройства протоколирования. Статистика производительности теста показывает среднее количество операций записи в секунду от 50 до 70 для дисков с отключенным кэшированием записи и RPM между 5,200 и 7,200.

Для получения дополнительных сведений и сведений о SQLIOStress программы, обратитесь к следующей статье Microsoft Knowledge Base:
231619 Использование программы SQLIOStress для нагрузочного дисковой подсистемы, такие как SQL Server
Многие производители ПК (например, Compaq, Dell, шлюз, HP и т. д.) заказ дисков с отключенным кэшем записи. Однако тестирование показывает, что не всегда возможно обращение так всегда полностью протестировать.

Данные устройства

В ситуациях, но все без ведения журнала SQL Server потребует только те записи были записаны на диск. При выполнении операций с использованием страниц данных необходимо также сбросить в постоянном хранилище; Нет отдельных записей для повторного создания действия в случае возникновения сбоя.

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

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

Повышение производительности

Начальной вопрос, который возникает: «у меня есть диск IDE, который кэширования, но когда я отключил, моя производительность стал значительно меньше ожидаемого--почему»?

Многие из жестких дисков IDE, протестированных корпорацией Майкрософт работают на RPM интенсивность 5,200 и на скорость ВРАЩЕНИЯ 7,200 жестких дисков SCSI. При отключении записи кэширования диска IDE механические производительности может стать коэффициента.

Очень четко области решения разница в производительности: «Адреса скорость транзакций».

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

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

Тестирование показывает записи высокой активности буферов меньшего размера, чем 512 КБ или 2 МБ может привести к снижению быстродействия.
Рассмотрим следующий пример:
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))
GO

SET NOCOUNT ON
GO

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 10000
   INSERT INTO tblTest VALUES ('Test')
				
Ниже приведены примеры результатов проверки для SQL Server.
SCSI(7200 RPM) 84 секунд
SCSI(7200 RPM) 15 секунд (кэширование контроллера)

IDE(5200 RPM) 14 секунд (кэш диска включен)
IDE(5200 RPM) 160 секунд
Перенос всей серии операций вставки в одной транзакции выполняется в примерно 4 секунды во всех конфигурациях.

Причина — количество необходимых сбросов журнала. Без транзакции каждой вставки является транзакцией в и само по себе и каждый раз при записи журнала транзакций необходимо сбросить. Каждый flush — 512 байт в размер, который требует вмешательства значительные механические устройства.

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

Предупреждение Не рекомендуется увеличить область транзакции. Длительные транзакции может привести к чрезмерной и нежелательного блокирования, а также увеличение объема служебной информации. Счетчики производительности SQL Server 7.0, SQL Server 2000 и SQL Server 2005 Баз данных SQL Server: для просмотра счетчиков на основе журнала транзакций. В частности, Журнал записаны на диск/сек можно указать многих небольших транзакциях, ведущие к высокой механической дисковой активности.

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

INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 50
BEGIN
   INSERT INTO tblTest VALUES ('Test')

   if(0 = cast(@@IDENTITY as int) % 10)
   BEGIN
      PRINT 'Commit tran batch'
      COMMIT TRAN
      BEGIN TRAN
   END
END
GO

COMMIT TRAN
GO
				
SQL Server 6.x может отсутствовать же нагрузку на частые и небольших транзакций записи журнала. SQL Server 6.x перезаписывает одной и той же страницы журнала 2 КБ, а транзакции будут зафиксированы. Это может уменьшить размер журнала, значительно по сравнению с сбросов границе 512-байтового сектора в SQL Server 7.0, SQL Server 2000 и SQL Server 2005. Уменьшение размера журнала непосредственно связана с активности механические устройства. Тем не менее, как описано выше, SQL Server 6.x Алгоритм может предоставлять зафиксированных транзакций.
SQL Server требует систем для поддержки «гарантированная доставка стабильной носитель», как описано в рамках программы Microsoft SQL Server Always-On хранения решений рецензирования. FOДля получения дополнительных сведений о требованиях к входной и выходной ядро СУБД SQL Server щелкните следующий номер статьи базы знаний Майкрософт:
967576Требования К модуль ввода/вывода серверной базы данных Microsoft SQL

Свойства

Код статьи: 230785 - Последний отзыв: 4 июня 2011 г. - Revision: 5.0
Информация в данной статье относится к следующим продуктам.
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
Ключевые слова: 
kbhowto kbinfo kbmt KB230785 KbMtru
Переведено с помощью машинного перевода
ВНИМАНИЕ! Перевод данной статьи был выполнен не человеком, а с помощью программы машинного перевода, разработанной корпорацией Майкрософт. Корпорация Майкрософт предлагает вам статьи, переведенные как людьми, так и средствами машинного перевода, чтобы у вас была возможность ознакомиться со статьями базы знаний KB на родном языке. Однако машинный перевод не всегда идеален. Он может содержать смысловые, синтаксические и грамматические ошибки, подобно тому как иностранец делает ошибки, пытаясь говорить на вашем языке. Корпорация Майкрософт не несет ответственности за неточности, ошибки и возможный ущерб, причиненный в результате неправильного перевода или его использования. Корпорация Майкрософт также часто обновляет средства машинного перевода.
Эта статья на английском языке:230785

Отправить отзыв

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com