Добавление первичных ключей в производственную базу данных

Question

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

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

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

Выяснение схемы перепроектирования и плана обслуживания будет трудоемким, но не проблематичным - я делал это раньше на отдельных объектах.Но как мне реализовать эти основные изменения в базе данных на десяти (или более) производственных площадках, обеспечив при этом целостность данных и не нарушая работу приложений?

Answer 1

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

Для репликации вам понадобятся GUID. Я хотел бы сделать это, добавить идентификаторы GUID и PK в среду разработки и тестовый тестовый тест. Вы наверняка найдете много дерьма там, где люди выбрали *, а добавление столбцов вызовет пробналем или заставит вещи появляться в отчетах, которые вам не нужны. Найти и исправить все эти вещи. Обязательно запишите все изменения данных и поместите их в систему контроля версий вместе с любыми изменениями кода, которые необходимо внести в приложение. Затем запланируйте время простоя для обслуживания базы данных в течение самых низких часов использования. Пусть пользователи знают, что приложение будет недоступно раньше времени. Во время простоя заставьте приложение показывать сообщение о сбое, измените базу данных на однопользовательский режим, чтобы никто, кроме команды, делающей это изменение, не мог повлиять на базу данных, сделать полное резервное копирование, запустить сценарии, чтобы внести изменения в базу данных, запустить код для изменения приложения, тестирования, вывода базы данных из однопользовательского режима и включения приложения.

Ни при каких обстоятельствах я бы не попытался внести изменения в этот мажор, не переходя в однопользовательский режим.

Answer 2

Сначала убедитесь, что у вас есть действительные резервные копии каждой базы данных, и протестируйте и восстановите их, чтобы убедиться, что они восстанавливаются.

Подумайте об использовании планов обслуживания Ola Hallengren и планов обслуживания, если вам необходимо развернуть идентичные, согласованные, написанные по сценариюрешения для всех ваших сайтов ( сайт Олы Халленгрен )

Тогда я бы сказал, что стоит взглянуть на то, как получить некоторую базовую индексацию, начиная с таблиц с большим количеством слов.Вы можете идентифицировать их с помощью различных методов - предположим, что вы знаете, как, но просто для того, чтобы высказать несколько мыслей: обзор кода, трассировка SQL, анализ плана запроса, а затем есть сторонние инструменты, например, Idera SQLdm, Confio Ignite, Quest's Spotlight onАнализ производительности SQL Server или Foglight для SQL Server.

Думаю, это поможет вам.

Answer 3

Некоторые дополнительные идеи.

Первое, что я хотел бы проверить: одинаковы ли все экземпляры базы данных в отношении базы данных объектов ? Все ли они имеют одинаковые таблицы, столбцы (и их порядок в таблицах), обнуляемость и т. Д. И т. Д. Обязательно проверьте почти все, что перечислено в sys.objects. Как только вы узнаете, что все структуры баз данных синхронизированы, вы поймете, что любые сгенерированные вами сценарии модификации базы данных будут работать на всех экземплярах.

После того, как вы измените тестовую среду с запланированными изменениями, вы должны убедиться, что они не нарушают существующую функциональность. Можете ли вы точно подражать «… в течение всего дня от 60 до 100 клиентов» в вашей тестовой среде? Если вы не можете, тогда вы, конечно, не можете знать, что ваши изменения что-то сломают, пока они не вступят в силу. (Предположение, которого я бы избегал: просто потому, что данный экземпляр не имеет никаких дубликатов в столбцах, для которых вы хотите построить первичный ключ, не означает, что никогда нет ни одного дубликата. ..)