Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#205<< #206 |
СОДЕРЖАНИЕ СОВЕТЫ Как сделать Backup базы на сетевой диск
Автор: Андрей Натальченко, Академия АйТи Основная проблема размещения файла Backup-a базы данных заключается в том, что средствами Enterprise Manager (EM) невозможно создать устройство резервного копирования при построении через мастер (или так, руками) или при выполнении через EM Backup Database. В этом случае EM видит ТОЛЬКО физически подключенные жёсткие диски и совсем не видит UNC пути. Обойти эту проблему можно путём создания удалённого устройства резервного копирования: 1. Сначала надо закрыть EM , если он был открыт. 2. Выполнить скрипт
USE master
Где
Nw1 - название удалённого устройства. М.б. названо любым именем Возможно, если не расшаривать заранее папку, пройдёт и такой вариант: EXEC sp_addumpdevice 'disk', 'Nw1', '\\London\C$\Backup\Nw1.bak' Запустить EM и выполнять Backup, указывая в качестве удалённого устройства резервного копирования установленное с помощью скрипта имя удалённого устройства. В нашем примере это Nw1. 3. Выполнять Backup в обычном режиме Вы можете выполнить резервное копирование через несколько сетевых интерфейсных плат. Выполняя резервное копирование данных на несколько устройств через несколько сегментов локальной сети, Вы можете обходить проблемы пропускной способности сети, которые могут ограничивать производительность. В случае резервного копирования данных на несколько компьютерных систем просто укажите имена этих систем. В случае резервного копирования данных на одну систему через два сегмента локальной системы Вы можете указать IP-адрес в UNC-адресе, как это показано ниже: EXEC sp_addumpdevice 'disk', 'Nw1', '\\100.100.100.1\C$\Backup\Nw1.bak' EXEC sp_addumpdevice 'disk', 'Nw2', '\\100.100.200.1\C$\Backup\Nw2.bak' Создав эти устройства резервного копирования, Вы можете копировать на них данные с помощью Enterprise Manager или операторов T-SQL.
SQL Server: соглашения при программировании баз данных, советы и лучшие методики (окончание)
По материалам статьи Vyas Kondreddi:
SQL Server Database Coding Conventions, Best Practices and Programming Guidelines
- Имейте в виду следующие проблемы, когда используете IDENTITY для генерирования первичных ключей. IDENTITY является очень специфической особенностью SQL Server, и у Вас могут быть проблемы при портировании Ваших приложений на другие системы управления базами данных. Столбцы с IDENTITY имеют и другие проблемы. Например, в некоторых случаях столбцы IDENTITY могут выйти за допустимые пределы в зависимости от выбранного типа данных; числа не могут быть автоматически использованы заново после удаления строк; столбцы с IDENTITY и репликация не всегда хорошо работают вместе. Поэтому используйте алгоритм для генерации первичных ключей в приложении или хранимой процедуре вставки. При использовании собственной генерации первичных ключей также возможны проблемы, такие, как одновременное создание одного и того же ключа или переполнение значений. Поэтому выберите из двух вариантов тот, который Вам больше подходит. - Минимизируйте использование NULL, т.к. это часто приводит к проблемам в приложениях, если только эти приложения специально не убирают NULL или не выводят NULL в какой-либо другой форме. Любое выражение, используемое с NULL, дает результат NULL. Функции ISNULL и COALESCE могут помочь в обработке значений NULL. Ниже показан пример, иллюстрирующий проблему: Взгляните на таблицу Customers, которая хранит имена клиентов, и в которой второе (middle) имя клиента может быть NULL.
CREATE TABLE Customers Сейчас добавьте клиента с именем Тони Блэр без указания второго имени:
INSERT INTO Customers Следующая команда SELECT возвращает NULL вместо имени клиента: SELECT FirstName + ' ' + MiddleName + ' ' + LastName FROM Customers Чтобы избежать этой проблемы, используйте функцию ISNULL, как показано ниже: SELECT FirstName + ' ' + ISNULL(MiddleName + ' ','') + LastName FROM Customers - Используйте типы данных Unicode, такие, как NCHAR, NVARCHAR или NTEXT, если Ваша база данных предназначена для хранения не только обычных английских символов, но и для других символов, использующихся в мире. Используйте эти типы данных только тогда, когда они абсолютно необходимы, т.к. они занимают в 2 раза больше места, чем типы данных, отличные от Unicode. - Всегда используйте список столбцов в Ваших командах INSERT. Это помогает избежать проблем, когда меняется структура таблицы (например, когда добавляется или удаляется столбец). Ниже приведен пример, иллюстрирующий проблему. Возьмем следующую таблицу:
CREATE TABLE EuropeanCountries Следующая команда INSERT без указания списка столбцов отлично работает:
INSERT INTO EuropeanCountries Добавим новый столбец в эту таблицу:
ALTER TABLE EuropeanCountries Выполним команду INSERT, показанную выше. Вы получите ошибку SQL Server:
Server: Msg 213, Level 16, State 4, Line 1 Этой проблемы можно избежать, указав в команде INSERT список столбцов, как показано ниже:
INSERT INTO EuropeanCountries - Выполняйте все проверки ссылочной целостности и верности данных, используя ограничения (внешние ключи и проверки доменной целостности), вместо использования триггеров, т.к. это быстрее. Ограничьте использование триггеров только для задач аудита, специальных задач и проверок, которые не могут быть выполнены с использованием ограничений. Ограничения также сохраняют Ваше время, т.к. Вам не надо писать код для этих проверок, позволяя системе управления базами данных делать все это за Вас. - Всегда обращайтесь к таблицам в одном и том же порядке во всех Ваших хранимых процедурах и триггерах. Это помогает избежать мертвых блокировок (deadlocks). Также существуют следующие способы избежать мертвых блокировок: Делайте Ваши транзакции максимально короткими. Затрагивайте как можно меньше данных во время транзакций. Никогда не ждите ввода данных пользователем посреди транзакции. Не используйте хинты блокировки данных на высоком уровне или ограничивающие уровни изоляции данных, если только они не являются абсолютно необходимыми. Сделайте в Ваших приложениях обработку мертвых блокировок, чтобы эти приложения могли повторить транзакцию в случае, если выполнение предыдущей транзакции прервалось из-за ошибки 1205. В приложениях немедленно обрабатывайте все результаты, возвращаемые SQL Server, чтобы снять все блокировки с обработанных записей. - Выведите такие задачи, как манипуляции со строками, сложения строк, подсчет количества записей, изменения регистра, изменения типов, и т.д., в приложения, если эти операции потребляют больше ресурсов ЦП на сервере баз данных. Также старайтесь делать первичную проверку данных в приложениях во время ввода данных. Это уменьшает сетевой трафик. Если Вашей системе предстоит работать с разными системами управления базами данных, то избегайте работать с битами в T-SQL, т.к. такие функции очень специфичны в каждой системе управления базами данных. Более того, использование битовых масок для хранения различных состояний определенного объекта противоречит правилам нормализации. - Всегда добавляйте параметр @Debug в Ваши хранимые процедуры. Этот параметр может быть типа BIT. Если в этот параметр передается значение 1, то выводите все промежуточные результаты и содержимое переменых, используя SELECT или PRINT, а если передается 0 - ничего не выводите. Это помогает быстро отлаживать хранимые процедуры, т.к. Вам не нужно добавлять и удалять команды PRINT/SELECT до и после возникновения проблем. - Не повторяйте вызовы функций в Ваших хранимых процедурах, триггерах, функциях и скриптах. Например, Вам может понадобиться длина строковой переменной во многих местах Вашей процедуры, но не вызывайте функцию LEN каждый раз, а вызовите функцию LEN один раз и сохраните результат в переменную для последующего использования. - Убедитесь, что Ваши хранимые процедуры всегда возвращают значение, показывающее их статус. Стандартизируйте возвращаемые хранимыми процедурами значения для успешного и неуспешного завершения работы процедуры. RETURN должен возвращать только статус выполнения, но не данные. Если Вам нужно возвратить данные, используйте параметры OUTPUT. - Если Ваша хранимая процедура всегда возвращает результат в виде однострочного набора данных, то лучше возвращайте данные, используя параметры OUTPUT вместо SELECT, т.к. ADO обрабатывает возвращаемые параметры быстрее, чем наборы данных, возвращаемые командой SELECT. - Всегда проверяйте значение глобальной переменной @@ERROR сразу после выполнения команд манипулирования данными (таких, как INSERT/UPDATE/DELETE), так, чтобы Вы могли откатить транзакцию в случае возникновения ошибки (в случае ошибки значение @@ERROR будет больше 0). Это важно, потому что по умолчанию SQL Server не откатывает все предыдущие изменения в транзакции, если какая-либо команда вызовет ошибку. Такое поведение может быть изменено с помощью выполнения SET XACT_ABORT ON. Переменная @@ROWCOUNT также играет важную роль в определении количества строк, обработанных в предыдущей команде манипулирования данными или выборки данных, на основе чего можно определить, нужно ли выполнить или откатить транзакцию. - Чтобы сделать команды SQL более читабельными, начинайте каждое выражение с новой строки и делайте отступы, когда требуется. Ниже показан пример такого подхода:
SELECT title_id, title - Хотя мы и пережили проблему 2000 года, всегда храните 4-значное значение года в датах (особенно, когда используете столбцы типов cCHAR или INT), а не 2-значное, чтобы избежать путаницы и проблем. Это не является проблемой для столбцов типа DATETIME, т.к. век хранится, даже если вы укажете 2 знака у года. Но всегда лучше указывать 4 знака даже для столбцов типа DATETIME. - Как и во всех языках программирования, не используйте команду GOTO, или используйте ее редко. Чрезмерное использование GOTO может превратить код в трудно читаемый и трудно понимаемый. - Не забывайте создавать ограничения на уникальность на Ваших альтернативных ключах. - Всегда будьте последовательны в использовании верхнего и нижнего регистров в Вашем коде. Если сервер не чувствителен к регистру, то Ваш код будет работать, но может не заработать на сервере, чувствительном к регистру, если в Вашем коде нет последовательности в использовании регистра. Например, если вы создаете таблицу (или базу данных) в SQL Server, которая имеет регистро-зависимый или двоичный порядок сортировки, то все ссылки на эту таблицу должны использовать тот же регистр, который использовался в команде CREATE TABLE. Если в команде CREATE TABLE вы назвали таблицу 'MyTable', а в команде SELECT используете 'mytable', то Вы получите ошибку 'object not found'. - Хотя в языке T-SQL нет понятия констант (как, например, в языке C), переменные могут выполнять те же функции. Использование в Ваших запросах переменных вместо конкретных значений повышает читабельность и сопровождение Вашего кода. Взгляните на следующий пример:
SELECT OrderID, OrderDate Этот же запрос может быть переписан в более читабельный вид, как показано ниже:
DECLARE @ORDER_DELIVERED, @ORDER_PENDING
SELECT OrderID, OrderDate - Не используйте порядковые номера столбцов в выражении ORDER BY. В следующем примере второй запрос является более читабельным, чем первый:
SELECT OrderID, OrderDate
SELECT OrderID, OrderDate Ну вот и все, друзья. Я буду обновлять эту статью, когда у меня будет что добавить нового. Мне будут интересны ваши отзывы на нее, так что можете посылать их на мой email. Удачного вам программирования баз данных! Статьи на русском языке
Модели баз данных
Fixing broken logins and transferring passwords Самые популярные темы недели
Новые упражнения на http://sql.ipps.ru
Где в EM и Prof. увидеть "Workstation ID" клиента?
|
#205<< #206 |
http://subscribe.ru/
E-mail: ask@subscribe.ru |
Адрес подписки |
Отписаться |
В избранное | ||