Temos lidado com um enorme crescimento de disco no SQL Server da Informatica. Após a carga, o banco de dados cresce para 2,4 TB. Depois que o banco de dados encolhe, ele vai para 1,05 TB. O que provavelmente poderia fazer com que isso acontecesse? Quais configurações podemos verificar no Informatica e/ou SQL Server para nossa próxima execução para solucionar isso ou fazer uma suposição/verificação?
EDITAR:
Há duas maneiras de mover dados usando um mapeamento Informatica. Usando SQL Overrides (executando SQL direto) usando o tipo SQL Transformation ou usando os fluxos de dados integrados com a funcionalidade pronta para uso da Informatica. Neste caso, estamos usando fluxos de dados. Quando os fluxos de dados são usados, o SQL direto ainda é usado, mas a Informatica cria o código SQL nos bastidores. Estamos carregando em incrementos de registro de 1.000.000. Achei que talvez a Informatica pudesse estar dizendo ao SQL Server para alocar espaço em disco à medida que carrega, mas não tenho certeza de quais comandos procurar se isso acontecesse.
Verifique alguns dos seguintes:
-Espaço livre de DB em prod antes do backup. Você pode ter muito espaço livre no prod pré-reservado. Costumava ser uma prática recomendada antes da introdução do IFI . Você ainda vai querer pré-alocar.
-Tamanho do log de transações pós-recuperação, mas pré-encolhimento executando
DBCC SQLPERF (LOGSPACE)as duas vezes. Talvez o log de transações não tenha transações abertas após a restauração e agora você está verificando/reduzindo-o. Isso significa que você pode não estar fazendo backups de prod tlog e seu modelo de recuperação éFULL.- Liste os tamanhos de todas as suas tabelas em ordem de tamanho após a recuperação e, em seguida, após a redução e, em seguida, compare.
Eu tinha os números incorretos. A redução foi feita e o tamanho era de 0,3 TB. Portanto, o SQL Server tinha 6 vezes o armazenamento alocado, não 2 vezes o armazenamento alocado. Resolvi isso criando uma definição de destino (importando o esquema da tabela na Informatica) depois de remover os índices da tabela de destino. O SQL Server estava alocando o espaço em disco, mesmo com os índices desabilitados. Provavelmente porque a Informatica mandou. Portanto, agora a Informatica apenas carrega os dados e nem se importa se há índices, embora existam. Em vez de desativá-los antes do ETL e habilitá-los depois do ETL, agora apenas descartamos os índices no pré ETL e os criamos depois do ETL.