Tag Archives: historico

Query últimos Backups – SQL Server Pt. 2

OnlyWhatMatters

Como dito no último post, irei mostrar uma simples query que retornará onde os Backups foram salvos e o tamanho dos mesmos.

A query irá retornar os seguintes campos:

Database_Name: o nome do database.
Physical_Device_Name: o local e nome do arquivo do backup realizado. Caso o Backup tenha sido salvo em uma fita, o resultado será parecido como esse: {7878439E-5007-4EB3-96AC-447AEE19EBE6}1
Size: o tamanho do backup em MB.
Backup_Start_Date: horário de início do backup.
Backup_Finish_Date: horário de término do backup.
Seconds_Duration: o tempo, em segundos, da realização do backup.
Backup_Type: tipo do Backup.
Server_Name: nome do servidor onde foi realizado o backup.

Nessa query estou utilizando um parâmetro de dias x backup_start_date para listar os backups.

Links úteis:
BackupSet
BackupMediaFamily

Ver o post original

Criando o SLD (Slowly Changing Dimension) manualmente para ganho de performance ou para BIDS 2005

Continuando o post sobre transferencia de dados pela ferramenta SSIS (SQL Server Integration Service), neste irei comentar não só sobre a carga de dados evitando erro de primary Key, mas sim, atualizar os outros campos caso tenha ocorrido alguma alguma alteração.
Por exemplo, neste post eu explico sobre apenas evitar erro de PK, portanto, imaginem o seguinte cenario:

Tabela Lojas Servidor OLTP:
1 56 Nome fantasia1 Responsavel 1 Cidade 1
2 78 Nome fantasia2 Responsavel 2 Cidade 2

E na tabela Lojas do Servidor OLAP, temos:
1 56 Nome fantasia1 Responsavel 1 Cidade 1

Se seguirmos apenas o primeiro post, veremos que a segunda linha sera sim transferida, e a primeira não, evitando assim o erro de Primary Key, porem, e caso a primeira linha do servidor OLTP fosse:
1 56 Novo Nome fantasia1 Responsavel 1 Cidade 1

Essa alteração não seria feita no servidor OLAP, mantendo assim para a primeira linha o nome fantasia “Nome fantasia 1”.

Enfim, essa é uma tarefa muitas vezes necessario aonde percebo que muitas pessoas possuem muitas duvidas.

No SQL Server 2008 temos a opção de utilizar um componente chamado Slowly Changing Dimension, porem não é a toa que ele possui este nome, esse componente é extremamente facil e simples de se configurar, alem de fazer todas essas alterações que eu descrevi acima alem de algumas variações de opções como manter historico ou atualizar, o problema é que ele é muito lento, para tabelas dimensões por exemplo, aonde este ambiente é vivido diariamente, a utilização deste trara facilidade na criação do ETL, porem dores de cabeça em sua execução, claro que essa queda de performance só sera sentida efetivamente com grande numero de dados.

A melhor opção seria criar manualmente este componente, abaixo esta descrito passo a passo de como realizar essa tarefa, para que no exemplo acima, a linha 1 seja atualizada e a linha 2 seja inserida.

Explicação do meu Cenario:
– Estou utilizando como Data Source um Excel, aonde a alteração de dados para confirmação do processo fica mais facil.
– O Dados extraido do excel vem como NVARCHAR, no caso minha tabela destino ja esta como NVARCHAR, porem o campo do numero da loja esta como int na tabela, sendo necessario colocar um “Data Conversion” após a extração do excel.
– Estou utilizando o BIDS 2005, talvez no 2008 as telas sejam um pouco diferente, alem do look up contem a opção de “Row not Match”, utilize-a se estiver no 2008, fica um pacote mais limpo e facil de ser entendido do que configurando a saida de erro do Look Up para linhas que não baterem.

Visão geral dentro do “Data Flow Task”

Explicação de cada Task:

EXCEL LOJAS: Aqui temos um simples Data Source com excel, não texistem grandes detalhes, apenas criação da conexão com o arquivo e selecionado todas as colunas, como meu excel não possui nome das colunas no arquivo, estou colocando um alias para cada coluna do excel, conforme foto abaixo:

Conversão chave de negocio: Aqui temos, como descrito acima, uma simples conversão devido a captura de dados do excel.

Bate Chave de Negocio (Numero_LOJA): Conforme descrito aqui esta apenas batendo as PKs, que neste caso tambem é a chave de negocio, para ver se ja
existe ou não, as possibilidades de saida são 2:
1. Não existe, inserção simples (Seta vermelha)
2. Existe, atualiza outros campos (Seta verde)

Os prints deste objeto estão no outro post.

OLE DB Command: Aqui esta a novidade deste post, como explicação deste objeto do Integration Service, é possivel dizer que este, ira realizar um comando SQL para cada linha que entrou nele, sim, a explicação é meio abstrata, talvez com o exemplo abaixo, conforme ordem de execução e não sequencial de abas, fique mais claro.

1. Connection manager
Aqui voce apenas ira especificar qual a conexão aonde o comando TSQL sera executado, no meu exemplo, na base de dados aonde esta a tabela Loja.

2. Input and Output Properties
Voce deve obviamente configurar entradas e saidas para este componente, ou melhor dizendo, uma coluna de entrada (Que veio dos objetos previos) para uma variavel de utilização local. Lembrando tambem que o nome de cada variavel local deve ser Param_, sendo de 0 a N.

Em OLE DB Command Input -> External Columns, iremos configurar essas variaveis, conforme imagem abaixo, existem 2 configurações que voce deve prestar atenção:
– Nome, conforme descrito acima: Param_0, Param_1, Param_2, Param_3.
– Data Type, deve ser o mesmo do tipo de dados da coluna que esta entrando no componente.

3.Column Mapping
Aqui voce ira mapear cada “variavel” local que voce criou o Step 2 para uma entrada, veja que aqui temos todas as opções, assim como o numero da loja sendo NVARCHAR (Direto do EXCEL) e o como INT, convertido previamente. Em meu exemplo, ficou desta maneira:

4.Component Properties
Por fim, a ultima aba de configuração, e o script SQL a ser executado, aqui voce devera primeira configurar a opção “Validate External meta Data” para true, para verificação das colunas de entrada, o default timeout, voce pode até configurar, mas não creio que seja tão usual assim, 0 representa sem timeout, o default code page tambem não é necessario alteração, deixando-o como 1252.
Em SQL Command, iremos colocar nosso comando SQL Server a ser executado para cada linha, no meu exemplo esta:

UPDATE Loja
SET Nome_Fantasia = ?,
Responsavel = ?,
Cidade = ?
WHERE Numero_Loja = ?


Ou seja, na base espeficada pela conexão na primeira aba deste componente, ira atualizar a tabela loja, aonda o Numero_loja seja igual ao Param_3, que é o

ultimo configurado, e no caso, nossa unica chave de negocio, os 3 primeiros “?” representam reespectivamente as “variaveis” locais Param_0, Param_1 e Param_2, que foram mapeadas no step 3 deste componente.

Considerações finais

Como puderam observar, é um trabalho não muito simples, e talvez até para niveis mais avançados em Integration Service, mas o ganho de performance faz todo o trabalho valer a pena.
No exemplo acima, foi feita a configuração dos componentes de forma a simular o Slowly Changing Dimension quando o mesmo for configurado para não manter historico e nem deixar dados fixos, caso sua intenção seja a realização dessas configurações, porem de forma manual e mais performatica, basta colocar regras como IF em seu comando SQL, é possivel executar procedures tambem apenas informando os dados, mas lembre-se que essa ação sera feita por linha, caso sua procedure seja muito grande e tenha muitas instruções, todo o motivo dessa alteração, ganho de performance, pode se perder.

Espero que este post possa ajudar muitas pessoas a realizarem tunnings em seus ETL de BI uma vez que normalmente trabalha-se com uma grande quantidade de dados.