DEVOPS – Restauração de DR de Banco de Dados – Team Foundation Server – Coleção de Projetos ou Banco de Dados TFS_Collection

Introdução

Esse passo a passo tem como objetivo explicar como restaurar os dados quando uma coleção de projetos é comprometida. Importante salientar que todas as coleções de projetos serão restauradas do ponto de backup que você utilizar.

Passos

Abra o Team Foundation Administration Console

clip_image002 Continuar lendo

Azure – Problemas de Sincronismo com o Azure AD

Cenário

Você possui um AD local em sua empresa e tem o sincronismo com o Azure Active Directory com o DirSync. Sua estrutura apresenta problemas com o seu AD local e os usuários não conseguem mais acessar suas contas de e-mail, portal do Azure e similares pois o Azure tenta validar a conta de usuário com seu AD que foi perdido.

Solução

Para resolver essa situação, siga os passos abaixo:

Continuar lendo

TF246017: Team Foundation Server could not connect to the database.

Introdução

Ao abrir o Team Foundation Server Administration Console você se depara com o seguinte erro: TF246017: Team Foundation Server could not connect to the database.

image

Continuar lendo

SharePoint – Mount-SPContentDatabase : The attach operation cannot continue because another object in this farm already contains the same ID

Introdução

Ao tentar restaurar um banco de dados de conteúdo WSS_Content usando o PowerShell com o comando Mount-SPContentDatabase ocorre o seguinte erro: Mount-SPContentDatabase : The attach operation cannot continue because another object in this farm already contains the same ID

image

Solução

Insira no final do comando a opção -AssignNewDatabaseId ficando o comando da seguinte forma:

Exemplo: Mount-SPContentDatabase -Name WSS_Content_SP2010 -DatabaseServer SERVSPENER\SHAREPOINT -WebApplication http://servspener/ -AssignNewDatabaseId e rode novamente o comando.

image

SQL Server – System.Data.SqlClient.SqlError: The backup set holds a backup of a database other than the existing ‘WSS_Content_SP2010’ database. (Microsoft.SqlServer.SmoExtended)

Introdução

Esse artigo tem como finalidade apoiar ao restaurar um backup de um banco de dados no SQL Server para um outro banco de dados em branco e o seguinte erro ocorre.

System.Data.SqlClient.SqlError: The backup set holds a backup of a database other than the existing ‘WSS_Content_SP2010’ database. (Microsoft.SqlServer.SmoExtended)

Continuar lendo

Windows – Habilitar WinRM

Introdução

Esse artigo tem como finalidade explicar como habilitar o uso do WinRM no seu Windows Server.

Passos

Abra o prompt de comando do Windows PowerShell como administrador

Em seguida digite o comando Configure-SMRemoting.exe –enable ou Configure-SMRemoting.ps1

image

Continuar lendo

DevOps – Dicas para um HA e DR Efetivo com o Microsoft SQL Server – Desenvolvimento

Como sabemos, o Microsoft SQL Server 2014 e agora o Microsoft SQL Server 2016 possuem diversas features como:

– Aumento do desempenho em querys;

– Maior gerenciamento de memória e processador;

– Melhoras no AlwaysOn, garantindo maior disponibilidade;

– Melhor gerenciamento de memória;

– E muitas outras features.

Maiores informações podem ser vistas no link: https://msdn.microsoft.com/en-us/library/bb500435.aspx

Mesmo assim, temos que ter alguns cuidados ao desenvolvermos nossas aplicações que utilizam esse sistema de banco de dados pois, além de determinadas features estarem apenas nas edições mais avançadas que consequentemente custam mais, muitas das features não conseguirão realizar “milagres” em sua aplicação, e mesmo que consiga, sua aplicação terá um custo elevado e menos atrativo ao cliente final, pois demanda de um investimento pesado em software, hardware e gerenciamento.

Por exemplo:

Um banco de sua aplicação extremamente fragmentado, não irá ficar mais rápido com aumento de IOPS em seu ambiente;

Um banco de dados com tamanho elevado exige maior plano de DR (Disaster Recovery) e consequentemente necessidade de locais redundantes para ativações de replicação, necessitando de uma maior infraestrutura com link, IOPS e memória.

Também exige mais recursos para um HÁ (High Available) efetivo devido ao tempo de recuperação do banco de dados no momento de um HA via Cluster Failover;

Um banco de dados com tamanho elevado pode ocasionar lentidão no processamento e consulta de dados do Banco de Dados, sendo necessário constantes manutenções de limpeza, alterações no código da aplicação, entre outras situações;

Dificuldade em sua aplicação trabalhar em ambientes compartilhados ou em nuvem, devido a quantidade de dados e forma de processamento, dificultando a implantação em clientes (on-premise) e em Cloud (Azure e AWS), desde de manutenção e gerenciamento, até preços, etc.;

Sendo assim, segue algumas dicas para análise e considerações que auxiliará o time de Infraestrutura na gestão de DR e HA, oportunizando um RTO (Recovery Time Objective) bem alinhado com seus clientes e parceiros de negócio.

Separar Banco de Dados de Processamento/Configuração/Armazenamento

– Vantagens:

· Priorizar os bancos de processamento em instâncias que possuam mais velocidade, memória e disco;

· Planos de backup diferenciados, entre os bancos de dados, por exemplo banco de processamento, pois seus dados são mais voláteis e descartáveis;

· Recuperação de desastre mais rápida, pois a restauração dos dados torna-se mais rápida, diminuindo o tempo de inatividade do cliente;

Manter dados voláteis nos Bancos de Processamento, com rotinas de limpeza ou manutenção

– Vantagens:

· Manter o banco de dados limpo, com tamanho reduzido, facilitando o backup e a recuperação de desastres

Separar Dados Anuais/Semestrais do Banco de Dados de Armazenamento em File Groups independentes

– Vantagens:

· Backups menores, devido a separação dos backups em File Groups;

· Separação dos File Groups em áreas nobres conforme os mais usados (por exemplo, consultas feitas no ano corrente, o File Group referente ao ano, pode ficar em uma unidade mais “premium”);

Outras práticas

Além das práticas recomendadas acima, que apoiará o time de Infraestrutura nos itens de DR (Disaster Recovery) e HA (High Available) dando condições de gerenciamento efetivo dos bancos e instâncias, gestão de backups eficientes e garantia maior de proteção de dados, há outras práticas que pontuo rapidamente, que merece ser inserido em outro post.

· Construção de consultas eficientes, evitando consumo excessivo de memória, disco e processador. Essas consultas podem ser avaliadas através do Database Engine Tuning Advisor

clip_image002

· Gerenciamento efetivo dos filtros de consulta dos clientes, parametrizando por exemplos os intervalos de períodos de consultas, forma de construção dessas consultas evitando-se trazer um volume de dados consideráveis e querys “caras” para o Microsoft SQL Server. Você pode avaliar as consultas no Monitor de Atividades.

clip_image004

· Mensagens amigáveis ao usuário, evitando-se replicação consultas via navegador;

· Rotinas de criação de índices, organização de dados;

· Proteção no banco de dados de armazenamento de documentos, evitando querys (dados apagados ou alterados) que possam comprometer os dados armazenados, pois dependendo da situação um backup pode não proteger;

E muitas outras práticas que estarei abordando de forma macro no próximo post.

No próximo post, darei pequenas dicas ao time de Operações para ter um HA e DR efetivo.

Até a próxima!

Alan Carlos