Simulando – Desastre e Recuperação de Bancos de Dados – Microsoft SQL Server 2008 R2 e 2012 – Parte Final.

Galera, bom dia.

Tudo bem?

Como prometido estou retornando com mais um post da série referente à Simulação de Desastre e Recuperação de Banco de Dados no Microsoft SQL Server 2008, R2 e 2012.

Neste post final da série, vou destacar como podemos quebrar a estrutura física e lógica do Arquivo de Logs, existente no nosso Banco de Dados MyDatabaseDesastre.

Você vai aprender e entender como podemos realizar este tipo de procedimento, identificando como as informações ficam armazenadas dentro do Transact – Log, ilustrando como é possível forçar o processo de rompimento desta estrutura, bem como, quais os procedimentos devemos realizar para contornarmos este problema.

Vale ressaltar que este tipo de procedimento poderá apresentar riscos de perda de dados, sendo assim, recomenda-se a criação de uma ambiente de teste, utilizando como material de apoio os posts anteriores.

 

Para começar, vamos relembrar um pouco da estrutura do nosso banco de dados chamado MyDatabaseDesastre, sendo este, composto por uma tabela chamada Clientes, conforme apresenta a Figura 1 apresentada abaixo:Figura1

Figura 1 – Estrutura do Banco de Dados MyDatabaseDesastre.

Espero que você tenha se lembrado do nosso simples ambiente, podemos então continuar nossa simulação.

 

Preparando nosso ambiente de Recuperação

Como o objetivo deste post é demonstrar como podemos recuperar nosso banco de dados que apresenta seu arquivo de log danificado, vamos colocar em prática algumas técnicas para contingência do nosso ambiente, como elementos que permitam realizar a recuperação. Para isso, vamos fazer uso do recurso de Backup de Log, recurso que eu acredito que você já tenha ouviu falar, mas vou fazer uma breve descrição sobre o mesmo.

Você pode estar se perguntando por que vamos fazer um backup se estamos fazendo uma simulação. Pelo simples motivo que Backup é sempre uma boa prática e em qualquer cenário podemos sempre ter algum tipo de imprevisto ou surpresas.

 

Backup de Transact Log

O backup de log é composto pela parte do log de transações que estava ativa no momento da execução do comando Backup, ou seja, esta parte representa uma área utilizada pelo SQL Server para armazenar a seqüência de processamentos que ele realizou.

Para se trabalhar com este tipo de backup, nosso banco de dados deve estar configurado para o modelo de recuperação completa ou Bulk-Logged. Somente estes dois modelos de recuperação armazenam esta seqüência de processamento realizado sobre o banco de dados.

 

Aplicando o Backup de Transact Log

Como destacado anteriormente, vamos fazer uso da técnica de Backup do Transact Log para o nosso Banco de Dados MyDatabaseDesastre, para que possamos ter a capacidade de realizar este tipo de backup, devemos deixar nosso banco de dados configurado com o Modelo de Recuperação Completo ou Bulk-Logged, conforme destacado anteriormente neste post, como também nos outros posts desta série.

 

Para isso, vamos utilizar o bloco de Código 1, declarado abaixo:

– Código 1 – Realizando – Backup Completo e Backup de Log –

– Realizando Backup Database –

BACKUP DATABASE MyDatabaseDesastre

TO DISK = ‘C:\Bancos\MyDatabaseDesastre\Backup-Database-MyDatabaseDesastre.bak’

With Init,

Description = ‘Backup Database Full – MyDatabaseDesastre’,

Stats=10

Go

 

 

 

– Realizando Backup Transaction Log – -

BACKUP Log MyDatabaseDesastre

TO DISK = ‘C:\Bancos\MyDatabaseDesastre\Backup-Log-MyDatabaseDesastre.bak’

With Init,

Description = ‘Backup Log – MyDatabaseDesastre’,

Stats=10

Go

Legal, legal, nossos Backups, tanto o Completo como o de Log foram realizados, vale ressaltar que todo e qualquer Backup de Log só pode ser realizado a partir do momento em que identifica a realização anterior de um Backup Full, pois o log irá conter as diferenças entre o último backup full em relação ao momento em que o log esta sendo backupeado. A Figura 2 apresentada abaixo, ilustra o resultado do processo de backup.

Backup-2

 

Figura 2 – Informações apresentadas pelo SQL Server após a conclusão dos processos de backup.

 

Simulando – Quebra – Transact Log

Como forma de ilustrar algumas maneiras para se realizar este rompimento de um arquivo de log, desenvolvi dois cenários, sendo eles:

  • Cenário 1 – Realizando a quebra da integridade física do Transact Log – Simulando uma possível queda de Energia.

 

  • Cenário 2 – Realizando a quebra da integridade física do Transact Log – Manualmente.

 

 

Cenário 1 – Realizando a quebra da integridade física do Transact Log – Simulando uma possível queda de Energia.

 

Neste momento, já temos nosso ambiente de retaguarda preparado em caso de alguma falha no processo de simulação. Nosso próximo passo será justamente fazer o que queremos, quebra nosso arquivo de log.

Para isso, vamos utilizar o Bloco de Código 2, observe que estaremos adicionando uma nova tabela, em seguida através de uma CTE, criando uma ordenação numérica de valores e inserindo nesta tabela, conforme a seqüência apresentada a seguir:

 

– Código 2 – Realizando – Criando a Tabela Numeracao –

CREATE TABLE Numeracao

(

NumerodaLinha Int Primary Key Clustered,

ProximaLinha INT

)

WITH (DATA_COMPRESSION = PAGE);

Go

 

Observações:

  1. 1.      Note que estou fazendo uso da opção Data_Compression no nível de página, com objetivo de minimizar o impacto no uso de disco e memória por parte do SQL Server durante o processo de manipulação dos dados.

 

  1. 2.      Vamos para o próximo passo, inserir um volume de dados na Tabela Numeração, através do Bloco de Código 3, em paralelo a execução do deste bloco de código, será necessário seguir os passos do Bloco de Código 4, para que seja possível simular realmente a quebra do log.

 

– Código 3 – Inserindo  – Massa de Dados – Numeracao –

;WITH Dados AS

(

SELECT TOP (1000000)

rn = ROW_NUMBER() OVER (ORDER BY SO1.[object_id])

FROM sys.all_objects AS SO1 CROSS JOIN sys.all_objects AS SO2

ORDER BY SO2.[object_id]

)

 

INSERT dbo.Numeracao(NumerodaLinha, ProximaLinha)

SELECT rn, ROW_NUMBER() OVER (ORDER BY NEWID()) + 1000000

FROM MassadeDados;

Go

 

CheckPoint

Go

 

Observação: Um detalhe importante neste bloco de código está na declaração e uso do comando Ckeckpoint, existe no SQL Server, como mecanismo para garantir a escrita obrigatória dos dados em nossos arquivos de dados e por conseqüência, registrar esta transação em nosso Arquivo de Log.

O Bloco de Código 4 é o mais simples, porém o mais importante, que consiste justamente na quebra da escrita de dados no log, através do comando Shutdown. Ao utilizar o comando Shutdown, estaremos forçando a realização de um desligamento forçado, o que normalmente acontece quando temos alguma falha física ou quedas de energia.

 

Não se esqueça que este bloco de código deve ser executado em paralelo ao processamento do Bloco de Código 3.

 

Para isso, vamos executar os seguintes passos:

– Código 4 – Utilizando o comando Shutdown –

  1. Abra uma nova conexão dentro da sua instância SQL Server;
  2.  Execute o comando “SHUTDOWN WITH NOWAIT”.

 

Neste momento, nosso servidor SQL Server encontra-se fora do ar, nosso banco de dados, teve sua escrita e acesso interrompidos de forma brusca.

Vamos então, reinicializar o serviço do Servidor e verificar qual é status do nosso banco de dados neste momento. Vou deixar que você escolha a forma que você tem mais familiaridade para manipular os serviços do Windows.

Um detalhe importante é manter o Management Studio aberto para que possamos conseguir ver em tempo real o Status do nosso banco de dados, conforme ilustra a Figura 3, apresentada em seguida:

Backup-3

 

Figura 3 – Status do Banco de Dados MyDatabaseDesastre.

 

Perfeito, conseguimos forçar a quebra do arquivo de log, conforme apresenta a Figura 3 acima.

 

E agora o precisamos fazer para resolver isso?

Em situações normais não precisamos fazer nada, conforme destaco abaixo.

 

Importante:

  1. Você vai perceber que o serviço de Banco de Dados do SQL Server será interrompido imediatamente e isso vai forçar que todo processo de escrita de dados no log será perdida.
  2. 2.      O SQL Server para o serviço com o arquivo de dados atualizado pela transação que ficou em aberto, mantendo no arquivo de log o registro desta transação incompleta.
  3. 3.      Em uma situação normal, o SQL Server resolveria o problema ao iniciar o serviço do mecanismo de banco de dados, executando de forma automática um ROLLBACK da transação que ficou em aberto, utilizando as informações do Arquivo de Log.

 

Este tipo de cenário é muito comum de se deparar, mas em alguns casos nem tudo é perfeito, pode acontecer que o SQL Server não consiga reverter as transações, sendo assim, nosso banco será mantido com o Status de In Recovery.

Justamente nesta a situação que nosso backup é de extrema importância e poderá nos ajudar, através do processo de restauração do banco de dados, fazendo uso do Backup Full e Backup de Log. Caso realmente seja necessário fazer a restauração, execute o Bloco de Código 5.

 

– Código 5 – Restaurando o Backup Completo e Backup de Log –

– Recuperando o Banco de Dados por Completo – Backup Database –

Use master

Go

 

Restore Database MyDatabaseDesastre READ_WRITE_FILEGROUPS

From Disk = ‘C:\Bancos\MyDatabaseDesastre\Backup-Database-MyDatabaseDesastre.bak’

With File=1,

Replace,

NoRecovery

Go

 

–Restaurando do Log e liberando o Banco de Dados

Use master

Go

 

Restore Log MyDatabaseDesastre

From Disk = ‘C:\Bancos\MyDatabaseDesastre\Backup-Log-MyDatabaseDesastre.bak’

With Recovery

Go

 

– Acessando o Banco de Dados – MyDatabaseDesastre –

USE MyDatabaseDesastre

Go

 

Ao concluir a execução deste bloco de código, indica que tudo ocorreu normalmente você conseguiu realizar acesso ao banco de dados MyDatabaseDesastre, isso mostra que nosso ambiente esta corrigido e liberado para uso.

 

Mas este não é o nosso cenário, o que queremos realmente e quebrar esta estrutura, e realizarmos a recuperação de forma manual, desta forma, vamos continuar nossa caminhada, agora trabalhando com o Cenário 2.

 

Cenário 2 – Realizando a quebra da integridade física do Transact Log – Manualmente.

Este é um cenário bastante simples no que se diz respeito a quebra do Arquivo de Log. O que realmente vamos levar um pouco mais de tempo será no processo de recuperação do log de forma manual. Então, vamos seguir os seguintes passos:

  1. Para o serviço do Mecanismo de Banco de Dados do seu SQL Server;

 

  1. Localize a pasta em que seu banco de dados esta armazenado, no nosso caso será em: C:\Banco\MyDatabaseDesastre;

 

  1. Selecione o arquivo de log: MyDatabaseDesastre_Log.ldf ou MyDatabaseDesastre_1.ldf;

 

  1. Abra este arquivo diretamente no em qualquer Editor de Texto, pode ser o Notepad ou similar. No meu caso, vou utilizar o Hex Editor Neo, aplicativo que já utilizamos em outros posts desta séria.

 

  1. Realize a alteração do conteúdo deste arquivo, apagando alguns dados, ou trocando valores, salve o arquivo;

 

  1. Inicie o SQL Server;

 

  1. Tente realizar o acesso banco MyDatabaseDesastre.

Você vai observar que o serviço do SQL Server é inicializado aparentemente de forma normal, mas ao tentar acessar o Banco de Dados MyDatabaseDesastre, receberemos a seguinte mensagem de erro:

 

Msg 945, Level 14, State 2, Line 1

Database ‘MyDatabaseDesastre’ cannot be opened due to inaccessible files or insufficient memory or disk space.  See the SQL Server errorlog for details.

 

Ao pesquisarmos nos Logs do Serviço (Management Studio – Object Explorer – Management – SQL Server Logs) veremos as mensagens, conforme ilustra a Figura 4:

Backup-4

 

Figura 4 – Mensagem de falha na ativação do arquivo de log, armazenada nos logs de inicialização do SQL Server.

 

Pois bem, nosso banco de dados esta com seu arquivo de log corrompido, é muito importante ressaltar que em nenhum momento quebramos a integridade do arquivo de dados, sendo assim, nossos dados estão totalmente íntegros.

 

Mas qual é Status que este Banco de Dados esta apresentando neste momento para o SQL Server?

Para responder esta e qualquer outra questão, vamos utilizar o Bloco de Código 6:

 

– Código 6 – Consultando o Status e demais informações do Banco de Dados –

 

SELECT DATABASEPROPERTYEX(‘MyDatabaseDesastre’, ‘Status’) As Status,

DATABASEPROPERTYEX(‘MyDatabaseDesastre’, ‘Recovery’) As ‘Modelo de Recuperação’,

DATABASEPROPERTYEX(‘MyDatabaseDesastre’, ‘UserAccess’) As ‘Forma de Acesso’,

DATABASEPROPERTYEX(‘MyDatabaseDesastre’, ‘Version’) As ‘Versão’

 

Após executar este bloco de código, o SQL Server retornará as informações apresentadas na Figura 5:

Backup-5

 

Figura 5 – Status do Banco de Dados – MyDatabaseDesastre.

 

Observe que nosso banco de dados esta apresentando neste momento o Status de SUSPECT(Suspeito), isso indica para o SQL Server que o mesmo, esta neste momento conectado de forma lógica ao SQL Server, mas sua estrutura não esta totalmente confiável para ser utilizada e em muitos casos não é possível realizar o acesso.

 

Agora temos que começar a pensar como poderemos resolver este problema, temos algumas possíveis alternativas, dentre elas, destaco:

  1. 1.      Realizarmos o processo de Detach e Attach;
  2. 2.      Realizarmos o processo de Detach e Attach forçando a reconstrução do Log;
  3. 3.      Realizar o processo de Detach e Attach sem utilizar o arquivo de Log;
  4. 4.      Recuperando a Estrutura Física e Lógica do Banco de Dados – MyDatabaseDesastre; e
  5. 5.      Restaurar o Backup Completo e Backup de Log. (Esta alternativa já foi apresentada anteriormente).

 

Muito bom, já conhecemos algumas possíveis formas para tentarmos recuperar nosso ambiente, vou apresentar cada uma delas, você vai poder acompanhar e identificar qual realmente será uma possível solução.

 

Alternativa 1 – Realizando o Detach e Attach:

Antes de realizar o processo de Detach, é importante informar que somente Bancos de Dados com Status de On-Line, Off-Line ou Emergency podem ser desanexados, neste caso, nosso banco de dados esta apresentando o Status de Suspect, vamos ter que realizar a alteração do seu Status em seguida fazer o Detach. Para isso, utilizaremos o Bloco de Código 7:

 

– Código 7 – Alterando o Status do Banco de Dados e realizando o Detach –

Alter Database MyDatabaseDesastre

Set Emergency

Go

 

EXEC SP_Detach_db ‘MyDatabaseDesastre’
Go

 

Nosso próximo passo é realizar o processo de Attach(Anexo) desta banco de dados novamente em nossa Instância, sendo assim, utilizaremos o Bloco de Código 8:

 

– Código 8 – Realizando o Attach –

EXEC sp_attach_db @dbname = ‘MyDatabaseDesastre’,

@filename1 = ‘C:\Bancos\MyDatabaseDesastre\MyDatabaseDesastre.mdf’,

@filename2 = ‘C:\Bancos\MyDatabaseDesastre\MyDatabaseDesastre_1.ldf’

 

Ao tentarmos executar este bloco de código, o SQL Server nos apresenta rapidamente a seguinte mensagem de erro:

 

Msg 5172, Level 16, State 15, Line 1

The header for file ‘C:\Bancos\MyDatabaseDesastre\MyDatabaseDesastre_1.ldf’ is not a valid database file header. The FILE SIZE property is incorrect.

 

 

Isso mostra que nossa alternativa de número 1 esta descartada e não vai nos ajudar, pois nosso arquivo de log esta corrompido e o processo de Attach que estamos utilizando ainda faz uso deste mesmo arquivo.

 

Alternativa 2 – Realizando o Detach e Attach forçando a reconstrução do Log:

Não vou novamente descreve cada passo, vou diretamente apresentar o que podemos fazer, através do Bloco de Código 9:

 

– Código 9 – Alterando o Status do Banco de Dados e realizando o Detach –

Alter Database MyDatabaseDesastre

Set Emergency

Go

 

EXEC SP_Detach_db ‘MyDatabaseDesastre’
Go

 

– Criando o Banco de Dados e forçando a reconstrução do Log –

CREATE DATABASE MyDatabaseDesastre

ON

(NAME = MyDatabaseDesastre,

FILENAME = ‘C:\Bancos\MyDatabaseDesastre\MyDatabaseDesastre.mdf’)

FOR ATTACH_REBUILD_LOG

Mais uma vez não obtivemos sucesso no processo de recuperação de nosso banco de dados, mesmo forçando o processo de Attach com a reconstrução do arquivo de Log, conforme apresenta a mensagem de erro abaixo:

File activation failure. The physical file name “C:\Bancos\MyDatabaseDesastre\MyDatabaseDesastre_log.LDF” may be incorrect.

The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure.

Msg 1813, Level 16, State 2, Line 1

Could not open new database ‘MyDatabaseDesastre’. CREATE DATABASE is aborted.

Msg 829, Level 21, State 1, Line 1

Database ID 7, Page (2:0) is marked RestorePending, which may indicate disk corruption. To recover from this state, perform a restore.

 

Da mesma forma que a alternativa 1 não resolveu o nosso problema esta alternativa também não a solução, vamos então para a Alternativa 3.

 

Alternativa 3 – Realizando o Detach e Attach sem utilizar o arquivo de Log:

Nesta alternativa estaremos realizando novamente o processo de Attach(Anexo) do banco de dados, mas descartando totalmente o uso do arquivo de log existente, sendo assim, o SQL Server tentar criar um novo arquivo de log.

Vale ressaltar que a System Stored Procedure SP_ATTACH_SINGLE_FILE_DB, introduzida a partir do Microsoft SQL Server 2005 e posteriormente substituída no Microsoft SQL Server 2008 pelo comando Create Database For Attach_Rebuild_Log, tem a capacidade de realizar o processo de Attach Database, somente para Bancos de Dados que possuem um único arquivo de dados.

Para demonstrar a forma de uso e tentarmos mais uma vez recuperar nosso banco de dados execute o Bloco de Código 10:

 

– Código 10 – Alterando o Status do Banco de Dados e realizando o Detach –

Alter Database MyDatabaseDesastre

Set Emergency

Go

 

EXEC SP_Detach_db ‘MyDatabaseDesastre’
Go

 

– Utilizando a System Stored Procedure – SP_Attach_Single_File_DB –

 

Exec sp_attach_single_file_db ‘MyDatabaseName’,

@physname = ‘C:\Bancos\MyDatabaseDesastre\MyDatabaseDesastre.mdf’

 

Após a execução de mais esta alternativa, para nossa surpresa não conseguimos realizar a recuperação do Banco de Dados, conforme apresenta a mensagem de erro abaixo:

 

File activation failure. The physical file name “C:\Bancos\MyDatabaseDesastre\MyDatabaseDesastre_1.ldf” may be incorrect.

The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure.

Msg 1813, Level 16, State 2, Line 1

Could not open new database ‘MyDatabaseName’. CREATE DATABASE is aborted.

Msg 824, Level 24, State 2, Line 1

SQL Server detected a logical consistency-based I/O error: unable to decrypt page due to missing DEK. It occurred during a read of page (2:0) in database ID 7 at offset 0000000000000000 in file ‘C:\Bancos\MyDatabaseDesastre\MyDatabaseDesastre_1.ldf’.  Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

 

E agora, esgotamos mais uma possível alternativa e não conseguimos recuperar o Banco de Dados MyDatabaseDesastre.

Começamos a nos deparar com algumas questões:

  1. 1.      O que esta acontecendo?
  2. 2.      Será que fizemos algo de errado?
  3. 3.      Vamos conseguir recuperar nosso ambiente de forma manual?

 

A resposta é muito simples e direta. “SIM”, vamos conseguir recuperar e estamos fazendo algo de errado “TAMBÉM”. Nosso erro esta justamente no procedimento de alterar o Status do Banco de Dados de Suspect para Emergency e depois realizar o Detach.

Como destaca Paul S. Randal em um dos seus mais fantásticos posts: “Nunca, Nunca, Never…. never detach a suspect database.” Ou seja, um banco de dados que está apresentando o seu Status de Suspect não deve ser desanexado(Dettach), pois sua estrutura não esta totalmente confiável, o que requer que alguns procedimentos sejam feitos para colocar este banco novamente em uso.

 

Este é o nosso grande erro, realizar o Detach de uma base de dados Suspect.

 

Com isso, do conjunto de cinco possíveis alternativas apresentadas em nosso cenário para tentarmos recuperar nosso ambiente, somente as alternativas de número 4 e 5 podem resolver de fato, sendo que, a alternativa de número 5 já foi apresentada anteriormente.

Vou então apresentar a alternativa de número 4 e demonstrar como os procedimentos apresentadas nesta opção, vão resolver o nosso problema.

 

Alternativa 4 – Reconstruindo a Estrutura Física e Lógica do Banco de Dados – MyDatabaseDesastre

Para esta alternativa, vamos utilizar o Bloco de Código 11:

– Código 11 – Procedimentos para recuperar a estrutura do banco de dados –

ALTER DATABASE MyDatabaseDesastre SET EMERGENCY

ALTER DATABASE MyDatabaseDesastre SET SINGLE_USER

Go

 

DBCC CHECKDB (MyDatabaseDesastre, REPAIR_ALLOW_DATA_LOSS)

WITH NO_INFOMSGS, ALL_ERRORMSGS

Go

 

ALTER DATABASE MyDatabaseDesastre SET read_write

ALTER DATABASE MyDatabaseDesastre SET multi_user

Go

Bom agora é hora de ver o que vai acontecer, vamos mandar executar, rezar e aguardar, tomará que tudo de certo.

 

Ufa, show de bola, até que enfim, conseguimos, conseguimos, nosso banco de dados, esta novamente operacional, ou seja, esta Online e acessível, conforme apresenta a Figura 6:

Backup-6

 

Figura 6 – Estrutura de Banco de Dados MyDatabaseDesastre recuperada.

 

Muito bem, ótimo, foi uma longa caminhada, mas com certeza de muito aprendizado e conhecimento. Agora você pode fazer acesso a este banco e continuar a brincar com esta estrutura.

 

Tenha sempre em mente que o bom e velho backup é a melhor solução, pois mesmo tendo recursos que o SQL Server oferece ele poderá ser o seu grande amigo, nestas horas de desespero.

 

Vou encerrar este post aqui, deve totalmente cumprida e feliz por ter conseguido. Posso dizer que este foi o maior post que já escrevi, como também, é a série que mais me trouxe prazer em compartilhar.

 

Espero que você tenha gostado deste post, como também, de toda a série dedicada exclusivamente ao Processo de Simulação e Recuperação de um Banco de Dados, seus componentes físicos e lógicos. Você acompanhou durante a série diversas maneiras, técnicas e procedimentos que estão presentes no Microsoft SQL Server.

 

Mais uma vez obrigado por sua atenção e visita, já estou pensando nos próximos temas que podemos trabalhar.

Até mais.

 

About these ads

Um comentário sobre “Simulando – Desastre e Recuperação de Bancos de Dados – Microsoft SQL Server 2008 R2 e 2012 – Parte Final.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s