Я управляю крупномасштабным облачным продуктом, который использует SQL Server в качестве ядра базы данных. Модель разработана таким образом, что каждый клиент, использующий продукт, имеет свой собственный экземпляр MS SQL Server. Мне нужен способ запрашивать, обновлять и вставлять эти экземпляры из централизованного экземпляра SQL, который используется для управления экземплярами. Я уже определил, что создание связанных серверных объектов - это правильный путь, и именно так я справлялся с для этого случая обновления из этих баз уже. Я работаю над расширением некоторых функций, что приведет к значительному увеличению количества и частоты запросов, выполняемых из этого экземпляра централизованного администрирования.
Итак, вот мой вопрос: каково влияние того, что 100+ связанных объектов сервера постоянно открываются из одного экземпляра SQL? Есть ли вообще какое-то влияние? До этого момента моя практика со связанными серверами заключалась в том, чтобы отбрасывать их, как только я закончу.
Связанные серверы истощали ресурсы, особенно оперативную память, в 32-битные дни - надеюсь, вы ушли с тех времен. Я думаю, что предложенное вами решение сработает, и «боль» будет на стороне централизованного SQL Server.
Однако связанные серверы иногда могут быть немного проблематичными - думали ли вы об использовании сценариев powershell / vbscript / SMO для запроса этих экземпляров, а затем загружать данные в этот централизованный SQL Server?
Это повлияет на объем оперативной памяти, используемой вне SQL-сервера. По умолчанию размер этой памяти составляет 256 МБ, и она используется для загрузки внешних драйверов и сборок. Это можно изменить с помощью опции запуска -g. Я согласен с Питером выше, плюс, вместо того, чтобы централизовать данные на сервере администратора, вы учли репликация вместо связанного сервера. Мне кажется, будет сложно поддерживать, если вы используете связанные серверы.