Adrian S's questions

Estamos prestes a iniciar um projeto para migrar um grande DWH para novos servidores físicos em um novo data center. A especificação de servidor atual é SQL Server Enterprise 2016 SP2 em execução no Windows 2012 R2. Os novos servidores serão MSSQL 2019 Enterprise rodando no Windows 2019.

O armazenamento SAN para os servidores atuais e novos é uma matriz de armazenamento totalmente flash. No ambiente atual, além de separar dados e arquivos de log em diferentes unidades lógicas, diferentes bancos de dados (somente arquivos de dados) também são divididos em diferentes unidades lógicas.

• SSD local - TempDb
• Unidade lógica 1 - arquivos de log
• Unidade Lógica 2 - arquivos de dados para bancos de dados de teste
• Unidade lógica 3 - arquivos de dados para bancos de dados voltados para o usuário
• Unidade Lógica 4 - arquivos de dados para bancos de dados de suporte (ReportServer, banco de dados MDS)

Como parte da migração do servidor, estou pensando em combinar todos os arquivos de dados em uma única unidade lógica.

• SSD local - TempDb
• Unidade lógica 1 - arquivos de log
• Unidade Lógica 2 - arquivos de dados

Além do gerenciamento de arquivos de banco de dados, há algum benefício de desempenho para manter os arquivos de dados divididos em diferentes unidades lógicas? Várias unidades lógicas oferecem melhor IO, mesmo que, em última análise, seja a mesma matriz de armazenamento físico?

Eu tenho um grupo de disponibilidade de várias sub-redes do SQL Server 2016 de dois nós. Estou tentando configurar a replicação transnacional do AG para uma instância autônoma para relatórios, que também atua como um distribuidor remoto. Precisamos apenas de um pequeno subconjunto das tabelas, portanto, adicionar a instância autônoma como uma terceira réplica não é uma opção.

Eu segui o Guia da Microsoft para configurar isso. Já rodei o EXEC sys.sp_redirect_publishere quando executo EXEC sys.sp_validate_replica_hosts_as_publishersele retorna o listener AG. Mas quando fazemos failover do AG, a replicação para de funcionar com o seguinte relatório de erros no monitor de replicação

Mensagens de erro: Não é possível consultar o servidor redirecionado 'AGL' para o editor original 'PUB1' e o banco de dados do editor 'AlwaysOnTest' para determinar o nome do servidor remoto; Erro 7303, mensagem de erro 'Erro 7303, nível 16, estado 1, mensagem: não é possível inicializar o objeto de fonte de dados do provedor OLE DB "SQLNCLI11" para o servidor vinculado "[B66E8E27-E422-41DB-BBBC-254D450468D7]".'. (Fonte: MSSQL_REPL, número do erro: MSSQL_REPL21879) Obtenha ajuda: http://help/MSSQL_REPL21879 Erros foram registrados ao validar o editor redirecionado. (Fonte: MSSQL_REPL, número do erro: MSSQL_REPL22037) Obtenha ajuda: http://help/MSSQL_REPL22037

Algumas coisas que eu verifiquei e tentei

1. Os servidores vinculados verificados para o assinante existem em todos os hosts de réplica secundários.
2. Alterou o modo de segurança para autenticação SQL usando sp_changedistpublisher com base nisso.

Quando o AG sofre failover, se eu executar novamente no distribuidor EXEC sys.sp_validate_replica_hosts_as_publishers, ele retorna

Não é possível consultar sys.availability_replicas no grupo de disponibilidade primário associado ao nome de rede virtual 'AGL' para os nomes de servidor das réplicas de membros: erro = 7303, mensagem de erro = erro 7303, nível 16, estado 1, mensagem: não é possível inicializar os dados objeto de origem do provedor OLE DB "SQLNCLI11" para o servidor vinculado "[7A7DA613-BFDA-4C51-B62C-9C7CD94E769E]"..',

Estou preso o que tentar a seguir .... ajuda por favor!!!

ATUALIZAÇÃO 16/06/2020

Quando o AG sofre failover, tentei conectar-me ao ouvinte AG do distribuidor remoto. O SSMS conectou bem, mas quando tentei me conectar com o SQLCMD, ele retornou um erro. Também posso me conectar à instância de failover diretamente do distribuidor, ignorando o ouvinte.

Sqlcmd: Erro: Microsoft ODBC Driver 13 for SQL Server: Named Pipes Provider: Não foi possível abrir uma conexão com o SQL Server 2 . . Sqlcmd: Erro: Microsoft ODBC Driver 13 for SQL Server: Tempo limite de logon expirado. Sqlcmd: Erro: Microsoft ODBC Driver 13 for SQL Server: Ocorreu um erro relacionado à rede ou específico da instância ao estabelecer uma conexão com o SQL Server. Servidor não encontrado ou não acessível. Verifique se o nome da instância está correto e se o SQL Server está configurado para permitir conexões remotas. Para obter mais informações, consulte os Manuais Online do SQL Server..

Eu tenho um servidor da edição 2016 Standard com duas instâncias. O servidor tem 8 processadores lógicos e 40 GB de memória (é um servidor de teste no hyper-v, portanto a especificação não é alta!) e não possui nenhuma carga de trabalho existente para o perfil.

O conselho sobre a configuração de arquivos MAXDOP e TempDb ainda é válido em um servidor de várias instâncias?

Meus pensamentos eram dividir os recursos do servidor e aplicar a configuração com base neles.

por exemplo, cada instância teria

• 16 GB de memória MÁX.
• MAXDOP 4
• 4 arquivos TempDB

Estou tentando converter a seguinte função de segurança em nível de linha SQL em um filtro DAX em um modelo tabular

CREATE FUNCTION [Security].[fn_securitypredicate](@BrandID AS INT, @ChannelId AS INT)  
    RETURNS TABLE  
WITH SCHEMABINDING  
AS  
    RETURN 
     (SELECT 1 AS fn_securitypredicate
            WHERE (EXISTS ( SELECT 1 FROM   security.RLSStaffBrand  WHERE StaffUsername = SYSTEM_USER AND BrandId = @BrandID)  
              AND  EXISTS ( SELECT 1 FROM   security.RLSStaffChannel WHERE StaffUsername = SYSTEM_USER  AND ChannelId = @ChannelID) )

               OR (        EXISTS (SELECT 1  FROM   security.RLSStaffBrand  WHERE StaffUsername = SYSTEM_USER  AND BrandId = @BrandID)  
                   AND NOT EXISTS ( SELECT 1  FROM   security.RLSStaffChannel WHERE StaffUsername = SYSTEM_USER ) )-- this user is not restricted by Channel

                OR (NOT EXISTS ( SELECT 1  FROM   security.RLSStaffBrand WHERE StaffUsername = SYSTEM_USER)          
                    AND EXISTS ( SELECT 1  FROM   security.RLSStaffChannel 

WHERE StaffUsername = SYSTEM_USER  AND ChannelId = @ChannelID) ) 

)
    GO

Até agora eu tenho os seguintes filtros DAX, mas isso só lida com a primeira condição no código SQL. Não sei se é possível replicar o resto no DAX.

='Brand'[BrandId]=LOOKUPVALUE('RLSStaffBrand'[BrandId], 'RLSStaffBrand'[StaffUsername], USERNAME(), 'RLSStaffBrand'[BrandId], 'Brand'[BrandId])

='Channel'[ChannelId]=LOOKUPVALUE('RLSStaffChannel'[ChannelId], 'RLSStaffChannel'[StaffUsername], USERNAME(), 'RLSStaffChannel'[ChannelId], 'Channel'[ChannelId]) 

Eu tenho uma instância tabular SQL 2016 SP1 SSAS. Implantei um modelo com as seguintes propriedades

Quando tento processar o banco de dados ou uma tabela, recebo um erro "A fonte de dados contém um ImpersonationMode que não tem suporte para operações de processamento" .

Mas se eu alterar as informações de representação nas propriedades de conexão para usar a conta de serviço em vez do usuário atual, funcionará bem.

Também não teremos esse problema se alterarmos o Modo padrão para DirectQuery em vez de importar, mas precisamos usar Importar porque precisamos usar a função de nome de usuário DAX para segurança em nível de linha.

Sou administrador na instância do SSAS e também administrador na instância do SQL Server que é a fonte de dados. Por que não posso processar o modelo tabular SSAS como meu usuário?

Temos uma tabela particionada usando o seguinte esquema de partição e função

CREATE PARTITION FUNCTION [pf_monthly_dateid](int) AS RANGE LEFT FOR VALUES (20140100, 20140200, 20140300, 20140400, 20140500, 20140600, 20140700, 20140800, 20140900, 20141000, 20141100, 20141200, 20150100, 20150200, 20150300, 20150400, 20150500, 20150600, 20150700, 20150800, 20150900, 20151000, 20151100, 20151200, 20160100, 20160200, 20160300, 20160400, 20160500, 20160600, 20160700, 20160800, 20160900, 20161000, 20161100, 20161200, 20170100, 20170200, 20170300, 20170400, 20170500, 20170600, 20170700, 20170800, 20170900, 20171000, 20171100, 20171200, 20180100, 20180200, 20180300, 20180400, 20180500, 20180600, 20180700, 20180800, 20180900, 20181000, 20181100, 20181200)
GO

CREATE PARTITION SCHEME [ps_monthly_dateid] AS PARTITION [pf_monthly_dateid] TO ([PRIMARY], [201401], [201402], [201403], [201404], [201405], [201406], [201407], [201408], [201409], [201410], [201411], [201412], [201501], [201502], [201503], [201504], [201505], [201506], [201507], [201508], [201509], [201510], [201511], [201512], [201601], [201602], [201603], [201604], [201605], [201606], [201607], [201608], [201609], [201610], [201611], [201612], [201701], [201702], [201703], [201704], [201705], [201706], [201707], [201708], [201709], [201710], [201711], [201712], [201801], [201802], [201803], [201804], [201805], [201806], [201807], [201808], [201809], [201810], [201811], [201812])
GO

Agora precisamos carregar alguns dados históricos na tabela para 2013, então quero alterar a função e o esquema para adicionar partições mensais para isso. Mas não consigo descobrir como fazer isso usando SPLIT? Cada exemplo e tutorial que vi mostra como adicionar novas partições no final de um intervalo, não dividir uma no meio.

Alguma sugestão por favor?

Temos um banco de dados SQL 2016 que possui uma tabela de linhas de 1,9 bilhão que possui uma coluna varbinary(255) que usamos para armazenar os HashBytes de um campo nvarchar(2000) na mesma tabela.

Temos um índice não clusterizado no campo varbinary e nossos scripts de manutenção de índice executam um REORGANIZE nele a cada 2-3 dias. Mas isso leva mais de 10 horas para ser concluído.

Alguma maneira de melhorar a velocidade de manutenção do índice para campos varbinary?

Temos um ambiente AlwaysOn, que inclui uma réplica em nosso site de DR configurado com confirmação assíncrona e secundária legível = Não.

Quando estávamos executando no SQL Server 2014 SP2, conseguimos executar DBCC CHECKDB nos bancos de dados em nossa réplica de DR. Mas, desde a atualização para o SQL Server 2016, não conseguimos e nosso trabalho de integridade semanal está falhando com o erro.

'The target database is participating in an availability group and is currently not accessible for queries.
Either data movement is suspended or the availability replica is not enabled for read access. 
To allow read-only access to this and other databases in the availability group, enable read access to one or more secondary availability replicas in the group.  For more information, 
see the ALTER AVAILABILITY GROUP statement in SQL Server Books Online.

Obviamente algo mudou em 2016 para evitar isso, só não sei o quê?