Category Archives: 6236

Reduzindo o tamanho do arquivo de logs do SharePoint via Query Analyzer

Esta postagem na verdade é um complemento para esta outra: Arquivo de Logs do SharePoint gigantesco

Aqui mostro uma forma alternativa de chegar na mesma solução (usando o Query Analyzer), o que torna o processo bem mais curto.

Execute cada um dos comandos a seguir, de forma sequencial e individual (Os comandos estão em negrito e o nome da base de dados em itálico. Adicionalmente, após cada comando, coloco a explicação do que ele faz):

USE WSS_Content_5b2a339ee78749d0b48100e45cd22a0c;

Conecta à base de dados que desejo reduzir de tamanho

ALTER DATABASE WSS_Content_5b2a339ee78749d0b48100e45cd22a0c SET RECOVERY SIMPLE;

Configura o modelo de recuperação para SIMPLE

CHECKPOINT;

Comanda um CHECKPOINT para eliminar todas as transações inativas

DBCC SHRINKFILE (WSS_Content_5b2a339ee78749d0b48100e45cd22a0c_LOG, 5);

Comprime o arquivo do log de transações para um tamanho aceitável

ALTER DATABASE WSS_Content_5b2a339ee78749d0b48100e45cd22a0c SET RECOVERY FULL;

Configura o modelo de recuperação de volta para FULL

 

Pronto, é só isso! Apenas quatro comandos, para fazer o mesmo do outro post!

Arquivo de Logs do SharePoint gigantesco

Quem trabalha com SharePoint, com um enfoque de infraestrutura, não apenas de usuário, já deve ter encontrado base de dados do SharePoint onde o arquivo de dados do SQL Server (.mdf) possui um tamanho de alguns poucos MBs ou GBs, mas o arquivo de logs associado (.ldf) possui muitas vezes o tamanho do arquivo de dados, chegando muitas vezes a consumir quase todo o HD da máquina.

A caso mais gritante que encontrei foi numa máquina de cliente um arquivo de dados (.mdf) de 5 GB e um arquivo de logs (.ldf) de 112 GB! A solução empregada nesta máquina será a demonstrada aqui neste post!

image

O mais interessante é que este arquivo de logs crescerá até consumir o seu HD inteiro, caso não seja configurado um limite para ele. Quando isso ocorrer os usuários não poderão inserir, atualizar, nem excluir seus registros!

Isto ocorre porque cada alteração (atualização) realizada no seu SharePoint é tratada como uma modificação pelo SQL Server (o que é correto) e portanto escrita no arquivo de logs, para somente depois ser escrita no arquivo de dados. Como o disco estará cheio, não será possível escrever no arquivo de logs, desta forma o SQL Server nem chegará a tentar escrever no arquivo de dados e portanto o seu SharePoint passará a ser apenas para visualização, uma vez que nada poderá ser alterado. Tornando-se inútil em pouco tempo.

Há como evitar isso? Claro, é uma configuração no SQL Server, porém como nem todo usuário de SharePoint entende de SQL Server isso pode se tornar um “elefante branco”. Vou abordar esta configuração em outro post, aqui focarei apenas em como reduzir o tamanho de um arquivo de logs que já esteja gigante.

Comece acessando o banco de dados que possui o arquivo de logs gigantesco e execute os seguintes procedimentos para reduzir o tamanho dele (aqui vou mencionar os procedimentos a serem realizados no modo “visual” (GUI) do SQL Server Management Studio, em outro post coloco como fazer via Query Analyzer, para não tornar este muito extenso.

Bem, então vamos lá:

  • Expanda Databases;

image

  • Localize o banco onde deseja reduzir o arquivo de logs, dê um clique com o botão direito do mouse nele e selecione Properties;
  • Acesse a guia Options;
  • Localize a informação sobre o modelo de recuperação (Recovery Model) onde deve estar selecionado Full;
  • Clique no menu dropdown e selecione Simple para o modelo de recuperação;

image

  • Clique em OK;
  • Dê um clique com o botão direito do mouse no nome da base de dados e escolha  Tasks –> Shrink –> Files;

image

  • No menu ao lado de File type, onde estará escrito Data, selecione Log;

image

  • Você pode manter o restante da tela como está, com a opção padrão, que é a liberação do espaço não usada (Release unused space), ou pode selecionar Reorganize pages before releasing unused space e ainda escolher em  Shrink file to o tamanho que deseja deixar o arquivo. Não há necessidade para alterar a opção padrão, então vamos simplesmente clicar em OK (Fique ciente que este procedimento pode levar vários minutos!);
  • Quando estiver concluído, caso deseje, você pode executar o procedimento anterior novamente, para reduzir o tamanho do arquivo de dados também. Para tanto, basta manter a seleção padrão para File type que é Data;
  • O último passo é voltar nas propriedades da base de dados e alterar novamente o modelo de recuperação para Full.

O resultado será algo semelhante à imagem abaixo (repare que eu realizei o procedimento tanto no arquivo de dados, quanto no de logs):

image

Problema com o tamanho da base do SQL Server

Realizando a migração de um Sharepoint Services 3.0 para o SharePoint Online do Office 365 verifiquei umas situações interessantes que julguei legal postar aqui para ajudar aos amigos.

Primeiro o SharePoint estava usando o Windows Internal Database para contornar o problema da limitação de tamanho das versões Express do SQL Server. Vale destacar que na época da instalação do SharePoint se utilizava Windows Server 2003 R2 e SQL Server 2005 Express, que possuía a limitação de 4 GB para tamanho da base de dados. Para quem não está acostumado com isso, o Windows Internal Database não possui limitação de tamanho e pode ser utilizado para o SharePoint, o que na época era uma boa solução para quem não desejava gastar.

Maravilha, mas hoje isso cria um problema adicional. Por que? Simples, não é possível migrar um SharePoint Services 3.0 direto para o SharePoint Online, primeiro temos migrar ele para um SharePoint Foundation 2010 ou SharePoint Server 2010 e então dele, podemos migrar para o SharePoint Online.

Até aqui tudo bem, ocorre que quando se instala o SharePoint Server 2010, como standalone, ele instala e configura um SQL Server 2008 Express, que naturalmente possui recursos superiores aos do SQL Server 2005 Express da época em que foi instalado o SharePoint original, porém, possui a mesma limitação de tamanho dos 4 GB, o que inviabilizaria a migração, uma vez que a base já superou este tamanho.

O processo de migração consiste em aplicar todas as atualizações no SharePoint Services 3.0 e no Windows Internal Database e depois realizar um Backup da base de dados do SharePoint (que pode ser feito via linha de comando, ou através do SQL Server Management Studio Express, que eu recomendo, por tornar o processo mais visual, o que facilita para quem não tem muita prática com bancos de dados).

Como a base original estava num sistema antigo, foi utilizado para criar o backup a versão 2005 dele, como pode ser visto abaixo:

image

Esta etapa é tranquila, agora vem a hora de levar o arquivo do backup até o equipamento onde temos o SharePoint Server 2010 e realizar a restauração do backup, para a primeira atualização da base de dados, pois é aí mesmo que iniciam os problemas. O problema deles será a demora via conexão de internet, caso os equipamentos estejam em locais onde não seja possível o transporte por meios físicos. O segundo será o tamanho da base, que neste caso era de 5,2 GB!

Na hora de restaurar o backup recebemos a seguinte mensagem:

image

Agora, como contornar isso, sem precisar gastar muito? Simples, fazendo o upgrade de edição!

Será necessário desinstalar o SharePoint, instalar o SQL Server 2012 Express e depois reinstalar o SharePoint? Não, o processo é bem mais simples do que isso! Basta Usar o SQL Server Instalation Center dele:

image

Apenas tenha atenção para não acessar o SQL Server Instalation Center do SQL Server 2012, senão de nada adiantará. Você pode reparar na tela acima que o mouse está posicionado no correto e o outro está na base da mesma coluna.

Selecione a opção de Maintenance e depois clique em Edition Upgrade:

image

No Windows Server 2012 você receberá uma mensagem de erro, basta clicar em Run the program without getting help e seguir o processo.

image

São realizadas algumas validações e você precisa apenas mandar continuar, clicando em OK ou Next, conforme o caso (uma vez cada um).

Então você deve definir para qual edição deseja fazer o upgrade. Caso tenha uma chave com os 25 caracteres de uma versão superior, insira ela. Se não tiver apenas selecione Enterprise Evaluation e clique em Next.

image

Sim, sua base será considerada de avaliação, mas isso não é problema, pois muito antes de os 180 dias da avaliação expirarem sua migração estará concluída!

Agora aceite o contrato de licença e avance para a tela onde deverá selecionar a instância do SQL Server a passar pela atualização. A identificação é simples, basta ver qual delas possui Express na coluna Edition. Caso tenha mais de uma e não saiba qual delas é a correta, primeiro identifique-a pelo gerenciador do SharePoint 2010. Vale salientar que a seleção é feito pelo nome da instância, no menu acima da tabela de instâncias instaladas, onde aparece escrito SHAREPOINT.

image

Pronto, problema de tamanho resolvido e agora você pode seguir com a migração!

Movendo o Banco de Dados do WSUS 3.0

Muita gente instala o Banco de Dados do WSUS no drive de sistema, sem se dar conta de que ele pode crescer muito e algumas vezes descobrem que o espaço no drive C:\ está quase extinto.


O que podemos fazer? Mover o Banco de Dados do WSUS para outro drive, naturalmente. Como?


  1. Faça o download e insale o SQL Server Management Studio Express, se ainda não tiver ele no sistema (esta é a parte mais demorada);
    1. Versão 2005 ou se preferir a versão 2008. Neste tutorial vou utilizar a versão 2005.
  2. Abra o SQL Server Management Studio;


  1. Conecte-se à instância chamada: \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query usando o método de autenticação do Windows;


  1. Neste momento você poderá ver a instância no Object Explorer, então faça o seguinte nela: SUSDB –> Tasks –> Detach;


  1. Selecione a caixa “Drop Connections” para remover a todas as conexões ao banco de dados, depois clique em OK. Caso apareça uma mensagem de erro, simplesmente clique em OK;
  2. Movimente o banco de dados do WSUS que fica numa pasta chamada “WsusDatabase”, para o drive que deseja;
  3. De volta ao Management Studio, dê um clique direito em Databases e selecione Attach;


  1. Clique em Add e selecione o arquivo .mdf já na pasta nova;
  2. Clique OK.

Pronto. seu banco de dados já está funcionando no novo local.


 

Materiais de referência sobre SQL Server

Armazenamento de Dados


Tempdb


Monitoramento


Backup


Segurança


Alta disponibilidade


Replicação


Service Broker


Serviço de Integração


SQL Server 2008


Fonte: http://gilmaroassis.spaces.live.com/Blog/cns!A5E9C41598F2DEC8!406.entry

Login failed for user Reason: The password of the account must be changed.

Digamos que você acaba de criar uma nova conta no seu SQL Server a fim de gerenciar um banco criado para uma aplicação LOB e obtém este erro.


Sua primeira reação é tentar desmarcar as caixas de verificação referentes à expiração, mas também não consegue. Remarcá-las conduz ao mesmo erro. O que fazer? Cancelar, isso mesmo, clique em Cancel.


Selecione “New Query” e digite o seguinte:


ALTER LOGIN UserLogin WITH PASSWORD = ‘NewPassword’ UNLOCK


Naturalmente substituindo UserLogin e NewPassword pelos respectivos valores. Isto irá desbloquear a conta.

Se desejar desabilitar a política de senhas, faça o seguinte:

ALTER LOGIN UserLogin WITH CHECK_EXPIRATION = OFF

ALTER LOGIN UserLogin WITH CHECK_POLICY = OFF

SQL Server offline

Ok, esta dúvida surgiu 3 vezes só hoje, então resolvi postar.


Digamos que você esteja gerenciando o SQL Server através do SQL Server Management Studio, ou o que o valha. Então dá um clique direito em uma base de dados e seleciona “Take Offline”.


Maravilha, isto funciona perfeito, mas então clica denovo e tenta selecionar “Bring Online”. Não funcionou, certo? Nem poderia…


Para trazer o banco de volta você precisará acessar o OSQL como administrador. Para isto siga os passos abaixo:


OSQL -E


ALTER DATABASE <nome_do_banco> SET ONLINE


Pronto, só precisa fazer isto!