HunterX3's questions

Temos alguns planos de manutenção mais antigos que foram criados com o SSMS 2014 em uma instância Sql Server 2014. A conexão definida para o plano usa uma conta Sql Server com perms sysadmin. Quando você edita com o SSMS 2014, tudo funciona bem. Na minha caixa local, tenho SSMS 2016, também tenho perms de administrador de sistema. Quando edito o plano, a "Tarefa Notificar Operador" tem um indicador azul de que algo está errado

Quando tento editar a tarefa, recebo o seguinte erro:

O log de erros do sql mostra os seguintes erros:

Error: 18456, Severity: 14, State: 8.
Login failed for user 'SqlAccount'. Reason: Password did not match that for the login provided. [CLIENT: xx.x.x.x]  

O SqlAccount é aquele definido em meu "gerenciar conexões" do plano de manutenção. Existe alguma nova permissão que o SSMS 2016 precisa? Os planos criados no SSMS 2014 não são totalmente compatíveis com o editor do SSMS 2016?

Eu tenho um VLDB e descarrego o DBCC CHECKDB para outro servidor. É possível atualizar o dbi_dbccLastKnownGood no servidor VLDB para que ele passe algum script que verifique essa data como sp_Blitz?

Alguém usa o snapmanager sql do netapp? Estamos no processo de tentar decidir se é certo para nós. Conheço os recursos mais populares, mas estou tentando obter algumas histórias de experiências da vida real. Alguém pode responder o seguinte:

Que problemas você está tendo?
Como isso ajudou de maneiras que você não esperava? Você pode oferecer algum conselho a favor ou contra o uso dele? A configuração foi mais difícil do que o esperado? Como sua manutenção no SQL mudou?

Também estou interessado em saber com que rapidez eles suportam as novas versões do sql, tentarei descobrir isso no site da netapp, mas se você tiver alguma informação, seria ótimo.

Quaisquer pensamentos são apreciados.

Sei que posso usar os contadores de desempenho para rastrear a CPU do administrador de recursos e o uso de memória. É possível rastrear o uso de E/S para cada grupo de carga de trabalho? Não vi nada específico ou práticas recomendadas.

Eu tenho uma pergunta geral sobre o design de tabelas do SQL Server 2008. Atualmente, temos uma mesa com mais de 600 GB e que cresce cerca de 3 GB por dia. Esta tabela tem os indecis apropriados, mas está se tornando um grande problema ao executar consultas e apenas por causa de seu tamanho. A questão é se devo dividir a tabela em várias tabelas por ano e mês (isso se encaixaria em como outros departamentos dividem seus grandes conjuntos de dados) ou devemos aproveitar o particionamento integrado ao SQL Server. Parece que usar o particionamento exigiria menos alterações de código. Pelo que li ao particionar, você ainda consulta apenas uma tabela e o servidor lida com como obter os dados. Se seguíssemos a rota de várias tabelas, teríamos que lidar com a extração de dados de várias tabelas.