BUSCANDO INFORMAÇÃO SOBRE COLLATE

Neste post demonstrarei como buscar informações sobre os tipos de collate.

Para verificar todos os collations disponíveis:

Para verificar collations específicos:

Até mais!!!

Anúncios

LISTANDO TODAS TABELAS COM SUAS DEPENDÊNCIAS

Neste post mostrarei como listar todas as tabelas e suas dependências.

Download do Script: http://sdrv.ms/12U4pXw

Script:

Retorno:

Até mais!!!

ALTERANDO OWNER DO BANCO DE DADOS

Neste post demonstrarei como alterar o owner do banco de dados.

Podemos realizar esta operação no modo gráfico ou por comando.

Alteração por comando:

1. Verificar o owner;

   Por código podemos verificar de duas formas:
   Query na sys.databases ou sp_helpdb.
   

2. Executar a store procedure sp_changedbowner para alteração;
   
3. Verificando após a alteração;
   

 

Modo gráfico:

1. Clicar com botão direito sobre o banco de dados e selecionar propriedades;
   
2. Acessar as propriedades do banco de dados;
   
3. Selecionar Files e alterar o owner;
   
   

Até mais!!!

ALTERAR COLLATION DE BANCO DE DADOS SQL SERVER

Neste post demonstrarei como alterar o collation de um banco de dados SQL Server.

Vamos aos passos:

1. Verificar o collation atual do banco de dados;
   
2. Rodar o script para alteração do collation do banco de dados;
   
3. Validar a alteração;
   
4. Agora temos que verificar as colunas que temos no formato texto para alterarmos o collation  uma a uma:
   
5. Query para geração dos scripts;
   
6. Copiar os comandos gerados, abrir um New Query e executar os scripts de alteração;
   
7. Consultando os collations após a alteração;
   

 

Pronto, collations alterados!

Obs: após finalizar recrie todos seus índices.

Até mais!!!

REPLICAÇÃO SQL SERVER – SNAPSHOT

Iniciando a série de posts referente aos modos de replicação do SQL Server. Nestes posts utilizarei a o SQL Server 2012.

Para quem está estudando para prova é interessante uma passada neste post.

Componente SQL Server necessário:

Para este post vou ilustrar o seguinte cenário:

Sou administrador dos bancos de dados SQL Server de um centro de pesquisa latino americano, a maior parte de coleta das informações são realizadas no Brasil e a parte de análise das informações são realizadas no escritório Uruguaio. O Servidor principal fica localizado no Brasil. Os pesquisadores só analisam as competências de exames realizadas no mês anterior ou inferior. Para a análise os pesquisadores executam vários relatórios. As informações coletadas no Brasil geram varias transações que concorrem com as execuções dos relatórios dos pesquisadores Uruguaios. Somente os pesquisadores Uruguaios acessam os relatórios para análise. As equipes de pesquisa estão reclamando bastante dos tempos de resposta das operações realizadas no sistema.

O escritório Uruguaio também tem licença de SQL Server disponível e em operação.

Uma boa opção para o cenário ilustrado acima é o uso da replicação SQL Server no modo Snapshot.

Vamos a configuração:

1. No SSMS, expandir Replication e clicar em New Publication.
   
2. Clicar em Next;
   
   
3. Selecionar Yes e clicar em Next;
   
4. Clicar em Next;
   
5. Selecionar o banco de dados e clicar em Next;
   
6. Selecionar Snapshot publication e clicar em Next;
   
7. Selecionar as tabelas que serão publicadas e clicar em Next;
   
8. Neste cenário não utilizaremos filtros. Clicar em Next;
   
9. Selecionar o itens conforme abaixo, clicar em Change  configurar o agendamento e clicar em Next;
   
   
10. Neste caso usarei o usuário configurado no meu SQL Server Agent. Clicar em Ok;
    
11. Clicar em Next;
    
12. Selecionar create the publication  e clicar em Next;
    
13. Informar o nome da publicação e clicar em Finish;
    
14. Aguarde o processo de configuração e clique em Close;
    
15. Após a configuraçã a publicação estará apresentada da seguinte forma;
    

Podemos observar que ainda não temos nada configurado na instância do escritório Uruguaio.

Próxima etapa será a configuração do Subscription.

1. Selecionar Local Subscriptions e clicar em New Subscriptions;
   
2. Clicar em Next;
   
3. Clicar em Next;
   
4. Clicar em Next;
   
5. Selecionar
   
6. Conectar nas isntancia do escritorio Uruguaio;
   
7. Selecionar a instância Uruguai e clicar em New Database;
   
8. Informar o nome do banco de dados e clica em Ok;
   
9. Clicar em Next;
   
10. Clique no botâo mostrado a baixo;
    
11. Neste cenário utilizarei o usuário configurado no SQL Server Agent;
    
12. Clicar em Next;
    
13. Selecionar conforme mostrado abaixo e clicar em Next;
    
14. Selecionar conforma abaixo e clicar em Next;
    
15. Selecionar Create the subscription(s) e clicar em Next;
    
16. Antes de finalizar a configuração vamos ver como está a instancia do escritório Uruguaio;
    O banco de dados foi criado mas as tabelas ainda não foram replicadas.
    
17. Clicar em Finish;
    
18. Aguardar o processo de configuração e clicar em Next;
    
19. Jobs Criados;
    
20. Após a replicação podemos ver o banco de dados criado e com os dados replicados;
    
21. Vou mostar um pouco do Replication Monitor;
    
22. Replication Monitor;
    
    

Replicação configurada. Basta alterar o pontamentos dos relatórios para o banco de dados Snapshot e os problemas de desempenho fica solucionado para ambos escritórios.

Para mais infomações sobre replicação SQL Sever acessar o link abaixo.

http://technet.microsoft.com/pt-br/library/ms151832.aspx

Até mais!!!

REPARANDO BANCO DE DADOS COM TABELA CORROMPIDA

Neste post vou demonstrar como reparar um banco de dados com tabela corrompida.

1 – Primeiramente executaremos o comando DBCC CHECKDB (‘BizTalkDTADb’) WITH ALL_ERRORMSGS.

DBCC results for ‘BizTalkDTADb’.
Service Broker Msg 9675, State 1: Message Types analyzed: 14.
Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
Service Broker Msg 9667, State 1: Services analyzed: 3.
Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.
DBCC results for ‘sys.sysrscols’.
There are 1573 rows in 19 pages for object “sys.sysrscols”.
DBCC results for ‘sys.sysrowsets’.
There are 261 rows in 4 pages for object “sys.sysrowsets”.

…

There are 3 rows in 1 pages for object “dta_ServiceState”.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 469576711, index ID 1, partition ID 72057595638775808, alloc unit ID 72057595657977856 (type In-row data). Page (1:735693) is missing a reference from previous page (1:780581). Possible chain linkage problem.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 469576711, index ID 1, partition ID 72057595638775808, alloc unit ID 72057595657977856 (type In-row data). Page (1:735987) is missing a reference from previous page (1:797797). Possible chain linkage problem.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 469576711, index ID 1, partition ID 72057595638775808, alloc unit ID 72057595657977856 (type In-row data), page (1:737741). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 133129 and -6.
Msg 8928, Level 16, State 1, Line 1
Object ID 469576711, index ID 1, partition ID 72057595638775808, alloc unit ID 72057595657977856 (type In-row data): Page (1:737741) could not be processed. See other errors for details.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 469576711, index ID 1, partition ID 72057595638775808, alloc unit ID 72057595657977856 (type In-row data), page (1:738831). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 133129 and -6.
Msg 8928, Level 16, State 1, Line 1
Object ID 469576711, index ID 1, partition ID 72057595638775808, alloc unit ID 72057595657977856 (type In-row data): Page (1:738831) could not be processed. See other errors for details.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 469576711, index ID 1, partition ID 72057595638775808, alloc unit ID 72057595657977856 (type In-row data), page (1:740654). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 133129 and -4.
Msg 8928, Level 16, State 1, Line 1
Object ID 469576711, index ID 1, partition ID 72057595638775808, alloc unit ID 72057595657977856 (type In-row data): Page (1:740654) could not be processed. See other errors for details.
Msg 8976, Level 16, State 1, Line 1
Table error: Object ID 469576711, index ID 1, partition ID 72057595638775808, alloc unit ID 72057595657977856 (type In-row data). Page (1:738831) was not seen in the scan although its parent (1:779016) and previous (1:847346) refer to it. Check any previous errors.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 469576711, index ID 1, partition ID 72057595638775808, alloc unit ID 72057595657977856 (type In-row data). Page (1:739486) is missing a reference from previous page (1:865528). Possible chain linkage problem.
Msg 8978, Level 16, State 1, Line 1
Table error: Object ID 469576711, index ID 1, partition ID 72057595638775808, alloc unit ID 72057595657977856 (type In-row data). Page (1:745241) is missing a reference from previous page (1:830415). Possible chain linkage problem.
Msg 8976, Level 16, State 1, Line 1
Table error: Object ID 469576711, index ID 1, partition ID 72057595638775808, alloc unit ID 72057595657977856 (type In-row data). Page (1:745626) was not seen in the scan although its parent (1:734204) and previous (1:745625) refer to it. Check any previous errors.
Msg 8976, Level 16, State 1, Line 1

…
CHECKDB found 0 allocation errors and 2370 consistency errors in table ‘Tracking_Parts1’ (object ID 2117582582).
DBCC results for ‘Tracking_Spool2’.
There are 0 rows in 0 pages for object “Tracking_Spool2”.
CHECKDB found 0 allocation errors and 2917 consistency errors in database ‘BizTalkDTADb’.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (BizTalkDTADb).
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

2 – Após a execução vamos alterar o banco de dados SINGLE_USER executando o comando ALTER DATABASE BizTalkDTADb SET SINGLE_USER WITH ROLLBACK IMMEDIATE.

3 – Executaremos o comando DBCC CheckDB (‘BizTalkDTADb’, REPAIR_ALLOW_DATA_LOSS) WITH ALL_ERRORMSGS para reparação do banco de dados.

4 – Executaremos o comando ALTER DATABASE BizTalkDTADb SET MULTI_USER para voltar a base de dados para multiusuário.

5 – Após a reparação vamos fazer uma checagem para ver se o banco de dados voltou a sua integridade.

Executar novamente o comando: DBCC CHECKDB (‘BizTalkDTADb’) WITH ALL_ERRORMSGS

Podemos observar que após os procediementos o banco de dados voltou a sua integridade.

Até mais!!!!

CRIPTOGRAFIA A NÍVEL DE BANCO DE DADOS (TDE) [2]

Neste post vou falar mais um pouco sobre criptografia de a nível de banco de dados (Criptografia de Dados Transparente – TDE).

Eu já havia feito um post (CRIPTOGRAFIA A NÍVEL DE BANCO DE DADOS) sobre criptografia  mostrando a parte de backup.

Agora vou mostrar como fica os objetos com a base de dados criptografado.

Este tipo de configuração é comum quando não se quer deixar disponível os códigos fontes.

Vamos aos passos:

• Criaremos o banco de dados;
  
• Utilizaremos SYS.CERTIFICATES para verificar os certificados contidos no banco de dados;
  
• Criaremos o certificado;
  
• Após a criação podemos validar o certificado;
  
• Fazer backup do certificado;
  
• Arquivos gerados após a realização do backup;
  
• Criaremos a chave de criptografia;
  
• Verificando o status de criptografia do banco de dados. Neste caso ainda não está criptografado;
  
• Habilitamos o modo de criptografia no banco de dados;
  
• Verificando o status do banco de dados após a alteração;
  
• Criaremos uma store procedure para exemplo;
  
• Com um usuário que só tenha permissão de leitura e execução de store procedure no banco de dados;
  
• Podemos observar que sobre o objeto consta um cadeado. Este simbolo indica que está criptografado.
  
• Se tentarmos ver o objeto a seguinte mensagem de erro será mostrada;
  

Até mais!!!