Como reservar recursos do sistema para bancos de dados específicos do SQL Server 2005?

Question

É possível especificar uma quantidade mínima / máxima de recursos do sistema (E / S de Disco, Memória, ciclos de CPU / s) disponíveis para cada instância de banco de dados dentro de um servidor SQL Server 2005?

Isso seria o análogo das configurações de QoS para os SQL Servers.

    

Answer 1

Não. Todos eles usam o processo sqlservr.exe, que é a Instância do SQL Server.

Se você precisar gerenciar recursos no nível de banco de dados, precisará de uma instância separada

Geralmente, descobri que vários bancos de dados na mesma instância geralmente se equilibram. Cada banco de dados tem seu próprio padrão de uso, padrão de carregamento, número de usuários, etc., e o SQL Server gerencia o buffer pool, os caches de plano, a memória, etc., com base nessa carga muito bem.

Se você tem um banco de dados com algum código ruim ou recursos de porcos, sugiro que seja seu próprio hardware ou, pelo menos, instâncias.

    

Answer 2

Ricardo - sua pergunta é um pouco enganosa. Existem duas maneiras de lê-lo.

Se você quer dizer bancos de dados dentro de uma instância do SQL Server , você não pode fazer isso com o SQL Server 2005. O SQL Server 2008 introduziu o Administrador de Recursos, que atinge o que você procura, mas não completamente. Pode controlar a memória e a CPU, mas não o disco IO.

Se você quer dizer diferentes instâncias do SQL Server no mesmo computador , então você pode fazê-lo. Cada instância tem suas próprias configurações mínimas e máximas de memória. No SQL Server Management Studio, clique com o botão direito do mouse no nome da instância no Pesquisador de Objetos e clique em Propriedades. A partir daí, você pode definir as memórias mínimas e máximas que cada instância levará. Você também pode definir máscaras de afinidade de CPU, o que permitirá escolher as CPUs que uma instância pode usar. Se você tivesse um servidor quad-core de 2 soquetes (8 no total), poderia atribuir uma instância a dois núcleos específicos e outra a seis núcleos. Infelizmente, se uma das instâncias estiver inativa, a outra instância não poderá tirar proveito desses núcleos ociosos.

Segregar o disco IO entre instâncias fica ainda mais complicado. Você pode usar multipathing de armazenamento para separar o tráfego entre as instâncias, se estiver disposto a dedicar muito tempo ao design e ao pathing de armazenamento. Você pode atribuir dados de uma instância e arquivos de log a uma matriz específica e, em seguida, configurar somente caminhos para essa matriz por meio de adaptadores de barramento de host (HBAs) específicos. Se isso não fizer sentido para você, envolva seu administrador de armazenamento e, se você não tiver um administrador de SAN, será mais trabalho (e dinheiro) do que você deseja resolver.

    

Answer 3

Com instâncias nomeadas do SQL Server (ou seja, mais de um processo sqlservr.exe), você pode restringir a CPU usando a afinidade do processador para vincular o agendador do SQL Server a uma instância específica da CPU. Há também uma configuração de memória máxima do servidor que também é especificada por instância do SQL Server.

Não creio que exista uma configuração para todo o servidor que possa ser definida com discos, mas pelo menos você pode criar LUNs separados para seus bancos de dados residirem em & particionar a carga dessa maneira.

No SQL Server 2008, há o governador de recursos , que permite definir regras muito sofisticadas para cargas de trabalho e a quantidade de recursos que eles podem consumir que pode ser por banco de dados. Talvez uma atualização esteja em ordem?

    

Answer 4

Você pode fazer um pouco disso usando VMs em vez de instâncias. Coloque uma instância separada em cada VM, pois os hipervisores tendem a ter melhores ferramentas para gerenciar recursos.

O Resource Governor é um bom começo, mas é uma limitação grosseira até agora. É um bom começo, como Brent mencionou, mas não cobre I / O. Dados os algoritmos de leitura antecipada, não sei ao certo como você tornaria isso fácil para alguém gerenciar.