Я пытаюсь стандартизировать все базы данных на одном сопоставлении - Latin1_General_CI_AS (стандартное сопоставление). У меня есть базы данных в SQL_Latin1_General_CP1_CI_AS.
Я знаю, что могу использовать ALTER DATABASE для изменения параметров сортировки базы данных, но это влияет только на новые объекты. Насколько я понимаю, единственный способ изменить существующие столбцы - это выполнить ALTER COLUMN для каждого столбца в каждой таблице - и мне нужно будет отбросить и воссоздать все индексы, чтобы сделать даже это.
Думаю, это будет выглядеть примерно так:
DROP INDEX indexname ON tablename
GO
ALTER TABLE tablename ALTER COLUMN columname varchar(50) COLLATE Latin1_General_CI_AS NULL
GO
CREATE CLUSTERED INDEX indexname ON tablename (columname ASC)
и повторите для каждого столбца varchar, char, text, nvarchar, nchar и ntext во всей базе данных. Это было бы огромный SQL-скрипт.
Есть ли более простой способ сделать это или кто-нибудь может предложить способ автоматизации создания сценария SQL для этого?
MS КБ 325335 есть варианты того, как это сделать для всей базы данных и всех столбцов.
В принципе:
Возможно, потребуется некоторая настройка, но я добился успеха с помощью утилиты «SQL Server 2000 Collation Changer»: http://www.codeproject.com/KB/database/ChangeCollation.aspx
К сожалению, в SQL Server это непростая задача.
Вы можете использовать инструмент сценариев, например Redgate SQL Compare, для существующих объектов базы данных (таблиц, хранимых процедур, представлений и т. Д.). Если у вас нет лицензии, вы можете использовать бесплатную пробную версию. После того, как вы создали новую базу данных с правильным сопоставлением и перестроили объекты из сценария, вы можете запустить SSIS для передачи данных из одной базы данных в другую. Если у вас много данных, используйте массовую вставку T-SQL.
Чтобы иметь правильную сортировку для будущих баз данных на этом сервере, вы можете изменить сортировку по умолчанию на сервере. В следующей статье MSDN объясняется, какие изменения происходят с использованием предложений COLLATE команд ALTER DATABASE и ALTER TABLE:
Вы можете изменить параметры сортировки любых новых объектов, которые создаются в пользовательской базе данных, с помощью предложения COLLATE в ИЗМЕНИТЬ БАЗУ ДАННЫХ заявление. Этот оператор не изменяет порядок сортировки столбцов в существующих пользовательских таблицах. Их можно изменить с помощью предложения COLLATE в ИЗМЕНИТЬ ТАБЛИЦУ.
Когда вы меняете параметры сортировки базы данных, вы меняете следующее:
- Параметры сортировки по умолчанию для базы данных. Это новое сопоставление по умолчанию применяется ко всем столбцам, пользовательским типам данных, переменным и параметрам, которые впоследствии создаются в базе данных. Он также используется при сопоставлении идентификаторов объектов, указанных в операторах SQL, с объектами, определенными в базе данных.
- Любые столбцы char, varchar, text, nchar, nvarchar или ntext в системных таблицах заменяются на новые параметры сортировки.
- Все существующие параметры char, varchar, text, nchar, nvarchar или ntext и скалярные возвращаемые значения для хранимых процедур и пользовательских функций изменяются на новое сопоставление.
- Системные типы данных char, varchar, text, nchar, nvarchar или ntext, а также все определяемые пользователем типы данных, основанные на этих системных типах данных, изменяются на новые параметры сортировки по умолчанию.
Обычно это не рекомендуется делать с живым сервером. В последний раз, когда я смотрел, это официально не поддерживалось Microsoft. Чтобы сделать это на практике, вы должны создать новый экземпляр с правильным сопоставлением и перенести в него базу данных.
Восстановление базы данных на сервере с другим параметром сортировки по умолчанию вызывает массу удовольствия, поскольку tempdb будет иметь параметры сортировки нового сервера, поэтому это также не рекомендуется.
Попробуйте эту утилиту, что для исходной базы данных будут созданы все сценарии, необходимые для применения в целевой базе данных, чтобы параметры сортировки были безопасно изменены.
Вы можете использовать представления Infomation_Schema для достаточно простой генерации скрипта, но я не уверен, что это лучший способ решить вашу проблему. Повторное создание всех индексов на большом БД может занять огромное количество времени / места в журнале и т. Д. Я бы пошел с миграцией (не восстановлением) в новый экземпляр.