Kris's questions

Temos um Grupo de Disponibilidade Always On de dois nós configurado. Ambos os nós estão no SQL Server 2016 SP3.

O servidor principal tem dois NICs de 1 Gb. Secundário tem dois NICs de 10 Gb.

Tanto o primário quanto o secundário têm um gateway padrão configurado para todos os quatro IPs.

Queremos habilitar uma única NIC de 10 Gb no servidor principal e desabilitar o gateway padrão para um dos IPs em ambos os nós, seguindo estas etapas:

1. Desabilitar gateway padrão para um dos IPs no servidor secundário
2. Failover para secundário
3. Desabilitar gateway padrão para um dos IPs no servidor primário
4. Configurar NIC de 10 Gb no primário
5. Desative um dos NICs de 1 Gb no primário
6. Failback para primário

As etapas acima serão suficientes para realizar a tarefa?

O cluster identifica automaticamente o novo NIC e o reflete nos detalhes da rede do cluster?

Podemos executar o primário com 1Gb NIC e 10Gb NIC (desativando o gateway padrão para 1Gb NIC IP)?

Razões para fazer isso:

1. Estamos atualizando nossa rede de 1 Gb para 10 Gb, então queremos utilizar o canal de 10 Gb.
2. Estamos copiando backups do prod para o servidor DR e de lá para as fitas. Alguns de nossos bancos de dados têm cerca de 6 TB, com backups em torno de 500 GB a 800 GB. Queremos acelerar a cópia também. As placas de rede nessas caixas não são usadas.

Atualmente nosso servidor está no Microsoft SQL Server 2016 (SP3) (KB5003279) - 13.0.6300.2 (X64) 7 de agosto de 2021 01:20:37 Copyright (c) Microsoft Corporation Enterprise Edition (64 bits) no Windows Server 2016 Standard 10.0 ( Compilação 14393: ). Esta é uma réplica secundária do AG somente leitura. Instalamos o SP3 em réplicas primárias e secundárias. No entanto, recentemente, o segundo nó afirma isso na atualização do Windows

As atualizações estão disponíveis: SQL Server 2016 Service Pack 2 (KB4052908)

Se os service packs são cumulativos, por que o servidor diz isso. Alguma ideia? Obrigado.

Recebemos uma montagem de fornecedor externo como

CREATE ASSEMBLY MYCALC_DLL
AUTHORIZATION dbo
FROM 0x42A728....<300,000 binary values> 
WITH PERMISSION_SET = UNSAFE
GO

E esta DLL é chamada de um SP.

Não gostaríamos de definir TRUSTWORTHY ON para o banco de dados carregar esse assembly no banco de dados do SQL Server e estávamos explorando opções. Encontrei esses links https://nielsberglund.com/2017/07/01/sqlclr-and-certificates/
https://sqlquantumleap.com/2017/08/09/sqlclr-vs-sql-server-2017-part- 2-clr-strict-security-solution-1/
https://sqlquantumleap.com/2017/08/16/sqlclr-vs-sql-server-2017-part-3-clr-strict-security-solution-2/

No entanto, esses links usam ferramentas como MAKECERT (substituído por new-selfsignedcertificate), pvk2pfx.exe e signtool.exe não existem em nossos servidores win2016.

A DLL também seria chamada com essa abordagem

Habilite TRUSTWORTHY no DB -> Instale o assembly no DB AS WITH PERMISSION_SET = UNSAFE-> Desabilite TRUSTWORTHY no DB

Suponho que seja uma pergunta estúpida, no entanto, estou carregando o assembly como UNSAFE, então qual é o ponto de desativar o TRUSTWORTHY? Me corrija...

Gostaríamos de usar certificados. Como prosseguir? E esses DB's serão configurados em breve para AlwaysOn, haveria alguma complicação? Obrigado

Agora o desenvolvedor deu esses arquivos

----- Funcionou assim. Este é o método correto?------

<Esta é a primeira vez que trabalho com VS>

1. Baixado Visual Studio Community Edition 2019
2. Do conjunto de arquivos acima, abriu o arquivo de projeto
3. Construir projeto CALC
4. Ele criou um arquivo .dll
5. Nas propriedades do projeto, a aba de assinatura criou um novo arquivo de chave de nome forte **Não marquei a caixa de seleção "Proteger meu arquivo de chave com senha" E escolheu sha256RSA como algoritmo de assinatura Salve o projeto e Build, cria um .snk Arquivo
6. Copie o arquivo DLL e snk para a caixa SQL Server
7. Execute o script abaixo

USE [Master]
GO

CREATE ASYMMETRIC KEY CLR_SP_Key
FROM EXECUTABLE FILE = 'H:\CLR_SP\CALC.dll'
GO

CREATE LOGIN CLR_SP_Login FROM ASYMMETRIC KEY CLR_SP_Key
GO

GRANT UNSAFE ASSEMBLY TO CLR_SP_Login
GO

USE [target_database]
GO
CREATE USER CLR_SP_Login FOR LOGIN CLR_SP_Login
GO

CREATE ASSEMBLY DBCALC_DLL FROM 'H:\CLR_SP\CALC.dll'
WITH PERMISSION_SET=UNSAFE
GO
CREATE function dbo.Proc_CLR_SP
(
@name as nvarchar(200) ,
@name2 as nvarchar(200)
)
RETURNS nvarchar(200)
AS EXTERNAL NAME DBCALC_DLL

Já estamos tendo uma instância do SQL Server Enterprise Edition em execução em um servidor físico. Agora para configurar grupos de disponibilidade AlwaysOn

1. Podemos configurar os serviços WSFC (Windows Server Failover Cluster) em uma instância existente do SQL Server?
2. Ou desinstalar o SQL Server, instalar o WSFC e depois instalar o SQL novamente? (isso pode não ser a melhor coisa, pois eles estão segurando enormes DBs.)

Como estamos planejando um cluster de 3 nós (todos são máquinas físicas e atualmente executando instâncias SQL), como seguir em frente? Quais opções selecionar na mídia de instalação para prosseguir com a configuração dos Grupos de Disponibilidade AlwaysOn. Obrigado

Temos 2 VLDB's - 6TB (db primário, pouco tráfego OLTP) e 4TB (db de arquivo). Os dados serão movidos/arquivados (excluir do primário e inserir no arquivo) diariamente de 5 tabelas grandes. Atualmente este servidor está em 2016 Standard Edition e possui 2 VLDB's e 1 db pequeno. Estamos planejando uma estratégia de HADR, considerando a edição padrão, só consigo pensar em envio de log (às vezes, o backup de log varia de 2 a 5 gb) ou FCI. Se atualizarmos para a edição Enterprise, podemos usar o AlwaysOn AG. Minha dúvida é qual a melhor estratégia para esses 2 VLDB's. E considerando que mais recursos estão sendo adicionados no futuro para o banco de dados primário, então o tamanho aumentará e se tornará um sistema OLTP mais alto.

Em nosso ambiente, os usuários receberam permissões de leitura/gravação/ddladmin no banco de dados tempdb (dev/qa/prod). Essas permissões serão perdidas quando o SQL Services for reiniciado, pois o tempdb é sempre recriado. Uma solução que está atualmente em vigor é - reaplicar os scripts de permissões de um trabalho do SQL Agent, sempre que o SQLAgent for iniciado. Isso não é preciso, pois os usuários/permissões serão modificados ao longo do tempo. Outro pensamento é fazer um backup diário (com uma política de retenção de 15 dias) das permissões tempdb e usar o mesmo trabalho para escolher o arquivo mais recente para reaplicar as permissões quando o SQL for reiniciado. Esta é uma solução precisa para o problema.

Obrigado!!