nateirvin's questions

Temos um servidor SQL Server 2016 (v13 SP3) Enterprise Edition hospedado em um cluster de failover do Windows/grupo de disponibilidade SQL com dois nós (primário e secundário). Os dois nós estão sendo executados em instâncias AWS EC2 executando o Windows Server 2012 R2 de 64 bits (NT 6.3).

No início desta semana, o servidor começou a responder com este erro:

Could not allocate space for object 'dbo.Batches'.'pk_Batches_BatchID' in database 'XXX' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

No início, isso parecia bastante simples: percebemos que tínhamos sido descuidados e permitido que os dados e/ou arquivos de log ficassem muito grandes. Os arquivos estavam definitivamente cheios, sem nenhum espaço não alocado neles. Achamos que só precisávamos aumentar a unidade do Windows (NTFS) (apoiada pelo AWS EBS nos bastidores). O banco de dados 'XXX' possui um arquivo de log e dois arquivos de dados - os arquivos de dados são configurados para crescimento ilimitado (embora apenas 64 MB por vez) e o banco de dados possui apenas o grupo de arquivos 'PRIMARY' padrão, nenhum outro grupo de arquivos envolvido. Os arquivos de dados estão na unidade ‘D:’.

Mas a unidade ‘D:’ tem mais de 400 GB livres, então por que os arquivos de dados não estão crescendo?

Passamos muito tempo analisando o cluster do Windows e os grupos de disponibilidade do SQL, pois também víamos muitos erros sobre o status do AG indo para "Recuperando" e a função de cluster não sendo aplicada/sincronizada corretamente. Algumas alterações permitiram que o nó primário voltasse a funcionar por alguns minutos, mas depois travava novamente. (Por causa disso, nossa capacidade de inspecionar o próprio banco de dados 'XXX' era limitada.) Verificamos se o EBS estava tendo algum tipo de problema ou interrupção, mas não encontramos erros.

Percebemos que os servidores estão antigos e desatualizados. Percebemos que alguns diriam que usar/confiar no crescimento automático é uma má prática. Mas esta questão não é sobre práticas recomendadas - é como colocar esse servidor de produção atualmente inativo de volta em funcionamento?

Eu tenho dois servidores, SERVER-01 e SERVER-00 (não são seus nomes reais). SERVER-00 é uma instância do SQL Server 2005 Standard, SERVER-01 é uma instância do SQL Server 2014 Standard. Eu tenho essa consulta que é executada em um SQL Agent Job todas as noites no SERVER-00:

truncate table DataWarehouse.dbo.documents
set identity_insert DataWarehouse.dbo.documents ON

INSERT INTO [DataWarehouse].[dbo].[documents]
    (
     [documentID]          
    ,[poNumber]
    ,[soldTo]
    ,[shipTo]
    )
SELECT 
     [documentID]
    ,[poNumber]
    ,[soldTo]
    ,[shipTo]      
FROM [server-01].[DataWarehouse].[dbo].[documents]

set identity_insert DataWarehouse.dbo.documents OFF

(A consulta real inclui mais colunas, eu a cortei para facilitar a leitura.)

No SERVER-01, documentsé uma view. No SERVER-00, documentsé uma tabela. Nesta consulta [server-01]há uma conexão de servidor vinculada no SERVER-00 (usa as credenciais de um sysadmin para se conectar ao SERVER-01).

Apenas cerca de metade das linhas estão sendo inseridas documentsno SERVER-00. Não há mensagens de erro ou avisos sendo registrados pelo trabalho - ele sempre é bem-sucedido. Como diabos isso pode estar acontecendo?

Estou tentando configurar a replicação - esta é a primeira vez que faço isso, então provavelmente estou cometendo algum erro de novato aqui. No momento, estou apenas trabalhando no ambiente de desenvolvimento. Eu tenho seguido o exemplo dado neste tutorial do MSDN .

Configurei a instância para ser seu próprio distribuidor e, em seguida, vou criar uma publicação (que inclui todas, exceto algumas tabelas e todas, exceto uma exibição). A publicação cria muito bem, mas depois, todas as tabelas e colunas foram definidas como "não para replicação"! Portanto, é claro que, quando vou para o status do agente de instantâneo, vejo o erro "Valor explícito deve ser especificado para a coluna de identidade na tabela quando IDENTITY_INSERT está definido como ON ou quando um usuário de replicação está inserindo em uma coluna de identidade NOT FOR REPLICATION".

Na primeira vez que isso aconteceu, percebi que tinha feito algo estúpido, então reverti selecionando "Desativar publicação e distribuição" e fiz algumas pesquisas. Antes de começar a habilitar e configurar a replicação, todas as tabelas são colunas com "não para replicação" definido como "falso", que é o que eu esperaria. Refiz a configuração do editor e distribuidor, o que não mudou nada nas configurações da tabela/coluna. Mas então eu criei a publicação e todos eles foram modificados. Eu desfiz novamente, o que reverteu todos eles de volta para 'para replicação', então gerei, mas não executei um script de publicação (com a GUI do SQL Server Management Studio), e executei cada comando um de cada vez, verificando o estado do "não para replicação" ao longo do caminho. Isto'sp_addarticle

Cada artigo está sendo adicionado com a opção @identityrangemanagementoption = N'manual'e @schema_option = 0x000000000803509F, que se traduz nas opções 0x1, 0x2, 0x4, 0x8, 0x10, 0x80, 0x1000, 0x4000, 0x10000, 0x20000 e 0x8000000 (consulte este artigo do MSDN para saber o que significam).

O ambiente é o SQL Server 2012 - dev é a edição Developer e o ambiente de produção eventual é a edição Standard. Estou usando este script para verificar o estado da configuração "não para replicação":

SELECT 
    tables.name AS table_name,
    columns.name AS column_name,
    COLUMNPROPERTY(columns.object_id, columns.name, 'IsIdNotForRepl') AS IsIdNotForRepl
FROM sys.tables
    JOIN sys.columns
        ON tables.object_id = columns.object_id
ORDER BY 3 DESC, 1, 2

Por que a criação de uma publicação de replicação excluiria ativamente os objetos de assunto da replicação e como altero esse comportamento?

Temos várias tabelas em nosso banco de dados que possuem VARCHAR(MAX)colunas onde a VARCHAR(500)(ou algo muito menor que max) será suficiente. Naturalmente, quero limpá-los e reduzir os tamanhos para níveis mais razoáveis. O 'como' fazer isso eu entendo: minha pergunta é o que a alteração dessas colunas fará nas páginas e existentes no disco? (Há muitas informações por aí sobre o que acontece quando você aumenta uma coluna, mas é difícil encontrar informações sobre o que acontece quando você diminui uma.)

Algumas das tabelas têm uma contagem de linhas muito pequena, então não estou preocupado com o custo da alteração, mas algumas são muito grandes e estou preocupado com a possibilidade de serem reorganizadas e causar muito bloqueio/tempo de inatividade. Em termos práticos, quero apenas uma maneira de estimar uma janela de manutenção. Em geral, gostaria de entender melhor como o mecanismo de banco de dados se comporta neste caso.

Desde já, obrigado!

EDITAR:

Estou examinando 20 tabelas, embora apenas metade delas tenha contagens de linhas superiores a 1.000. O maior tem quase um milhão de linhas. O pior infrator é uma tabela com 350.000 linhas e quatro VARCHAR(MAX)colunas que podem ser reduzidas ao VARCHAR(500)nível.

Sou novo em DW/BI e essa parece ser uma pergunta bastante básica, mas não consigo encontrar uma boa resposta.

Eu tenho uma tabela de fatos que teria mais de uma data associada a ela, então pensei que teria várias chaves de data para a mesma tabela de dimensões, por exemplo, SubmittedDateKey, ClosedDateKey. Obviamente, o SQL Server pode fazer isso - minha reserva é que, quando projetei um esquema de prova de conceito dessa maneira, as ferramentas do cliente (ou seja, Tableau, Excel) pareciam ficar confusas sobre como mapear os relacionamentos. (Também encontrei esta postagem no fórum dizendo que o Analytic Workspace Manager da Oracle proíbe explicitamente isso, o que obviamente não implica nada sobre o meu mundo da Microsoft, mas sugere que é um não-não geral.)

Existe uma prática recomendada em DW/BI sobre isso? Em vez de ter uma tabela de dimensões conectada a cada uma dessas chaves, devo ter várias tabelas de dimensões idênticas, por exemplo, SubmittedDateDimension, ClosedDateDimension?

Obrigado!