Arquivo da tag: Consultoria em Banco de Dados

SQL Server 2014 Developer agora é free (Visual Studio Dev Essentials)

Ferramentas, serviços de nuvem e treinamento gratuitos
Obtenha tudo o que você precisa para compilar e implantar seu aplicativo em qualquer plataforma. Com ferramentas de ponta, o poder da nuvem, treinamento e suporte, é o nosso programa gratuito para desenvolvedores mais abrangente de todos os tempos.

Visual_Studio_Dev_Essentials

A fábula dos porcos assados (Falta de bom-senso)

Fonte e Direitos – Café Point

Certa vez, aconteceu um incêndio num bosque onde havia alguns porcos, que foram assados pelo fogo. Os homens, acostumados a comer carne crua, experimentaram e acharam deliciosa a carne assada. A partir daí, toda vez que queriam comer porco assado, incendiavam um bosque…

Mas o que quero contar é o que aconteceu quando tentaram mudar o “sistema” para implantar um novo. Fazia tempo que as coisas não iam lá muito bem: às vezes os animais ficavam queimados demais ou parcialmente crus. O processo preocupava muito a todos, porque se o “sistema” falhava, as perdas ocasionadas eram muito grandes – milhões eram os que se alimentavam de carne assada e também milhões os que se ocupavam com a tarefa de assá-los. Portanto, o “sistema” simplesmente não podia falhar. Mas, curiosamente, quanto mais crescia a escala do processo, tanto mais apareciam falhas e tanto maiores eram as perdas causadas.

Continuar lendo A fábula dos porcos assados (Falta de bom-senso)

Modelagem de Banco de Dados (Exemplos)

Site: Database Answers

data_model

As linguagens de programação mais utilizadas em 2017, 2016 e 2015

The 7 Most In-Demand Programming Languages of 2019


 

2017
Podemos observar que em 2017 houve um grande crescimento no uso da Linguagem de Programação Python, na minha opinião devido ao rápido crescimento da Inteligência Artificial, Machine Learning e etc. C++ também teve um bom crescimento!

Indeed-Job-Postings

2016

programming-languages-for-2016_graph

2015

Most-In-Demand-Programming-Jobs

Azure Premium Storage… Testes com SQLIO

Blog - Fabiano Neves Amorim

Fala galera, faz tempo eim?

Bom, semana passada fiz uns testes em um cliente acho que a informação vai ser útil pra vocês.

Esse é um cliente que sofria demais com a péssima performance dos discos do Azure, todo a sua infra-estrutura de banco de dados está em VMs.

Depois de aplicar várias técnicas para minimizar o custo e melhorar a performance das operações de I/O, finalmente o storage premium ficou disponível (só pra País de primeiro mundo, adivinha se tem no Brasil?…) para compra, e conseguimos migrar tudo para o novo storage. Porém ficávamos sempre com aquela dúvida, e ai, vai melhorar mesmo? Quantos %? Qual a diferença de performance dos discos? … Para responder essas nossas dúvidas e ter certeza de que o novo storage está melhor, fiz alguns testes com SQLIO e criei alguns gráficos.

Antes de te mostrar os gráficos, deixa eu mencionar algumas técnicas que…

Ver o post original 331 mais palavras

Ajuste de desempenho de consulta – Infográfico

Site: Solarwinds

54138-Infografico-SolarWinds-Base-de-Dados

O Plano B

L&A Soluções – Consultoria em Banco de Dados SQL Server ( Suas informações em boas mãos! )

Fonte: RENATO CESAR MONTEIRO (Blog)
Acadêmico de Redes de Computadores no Unilasalle Canoas-RS, certificado em ITIL V-3 Foundations pelo EXIM.
Todos nós recordamos daquele trágico dia 11 de setembro de 2001 – o dia em que as torres gêmeas de Nova York vieram abaixo pelas mãos dos terroristas que jogaram nelas dois aviões Boeing 767 que haviam sido sequestrados. Sem dúvida uma das maiores tragédias da história moderna. A partir dali, tudo mudou nos Estados Unidos: as leis de imigração ficaram mais rígidas, o controle sobre o tráfego aéreo aumentou,foi deflagrada uma verdadeira guerra contra o terrorismo que, mui tas vezes, passou por cima dos direitos humanos. Foram ordenadas execuções sumárias, mui tas vezes sem provas criminais e contrariando as leis internacionais. Mas a partir daquele dia também mudou a história da Tecnologia da Informação.

Todos sabemos que o armazenamento de informações e documentos são fundamentais para a continuidade de qualquer negócio. Os meios de armazenamento atuais incluem, quase que na maioria das empresas, backup em fitas magnéticas, em servidores remotos ou sites de backup (existem os modelos co-location, que nada mais são do que data centers independentes que oferecem hospedagem compartilhada para mais de uma organização). As boas práticas sugeridas pela ITIL (Information Technology Infrastructure Library, modelo britânico utilizado em muitas empresas, cito, por exemplo, a Gerdau e a Stefanini IT Solutions) recomendam que as mídias de backup de cada empresa sejam armazenadas em local seguro e nunca no mesmo prédio-sede. Em caso de destruição total do patrimônio físico de uma empresa (o que pode ser recuperado através de seguro) , estes arquivos poderão ser restaurados.

Naturalmente, o monitoramento destes backups através do uso de software apropriado, bem como a análise de logs e testes de restore periódicos também são recomendáveis. Acontece que muitas empresas que operavam nas torres gêmeas de NY possuíam seus backups na torre vizinha. Isso mesmo: fitas de backup, servidores de backup e links de contingência ficavam no outro prédio. Ninguém imaginava que as duas torres desabariam. Ali, caro leitor, muitas empresas vieram à falência por não terem mais o histórico de seus clientes ou simplesmente por não poderem comprovar dívidas e créditos: todo o histórico digital estava perdido!

Desde então a grande maioria dos bons profissionais de Tecnologia da Informação vêm buscando especializar-se e implementar em suas empresas as práticas de continuidade de negócio mais modernas, atualizadas a partir daquela tragédia. Isso não se restringe ao armazenamento de dados, mas tem sido levado em conta, também, o capital intelectual. Não me surpreende o fato dos dois diretores de uma famosa empresa de consultoria e treinamento aqui de Porto Alegre viajarem periodicamente em voos diferentes. Eles sabem que detém grande conhecimento sobre a sua empresa e que o falecimento de ambos seria extremamente prejudicial para a continuidade do negócio. Logo, se acontecer a queda de um dos aviões, viria a falecer somente um dos diretores… Parece loucura, mas muitas empresas adotam esta prática. Apenas não admitem publicamente. Se refletirmos um pouco chegaremos a uma conclusão semelhante no que diz respeito ao conhecimento, à patente do software. O monopólio da informação, o não compartilhamento do código pode gerar a perda irreversível de grandes ideias. Quantos grandes softwares foram descontinuados simplesmente porque o código-fonte não foi aberto e, assim, não foi dada a continuidade por parte de outros desenvolvedores?

O “plano B”, caro leitor, resume-se a uma única palavra: continuidade. Isso pode ser implementado a partir de um simples nobreak até um si te em co-location.
Cabe aos profissionais de Tecnologia, ir além e nos anteciparmos aos imprevistos

Vejam também:
Missão Crítica: conceitos básicos

Banco de dados corrompido (Análise)

Esta é uma área que gosto muito, apesar que não gostaria de passar por uma situação desta em produção… hehehe

Encontrei este Post no Blog do Erickson Ricci, segue abaixo conforme o autor escreveu (todo o mérito do matérial é do autor, que esta de parabens pelo excelente material)
Neste post farei a análise de um banco de dados corrompido. O banco de dados corrompido que irei utilizar foi disponibilizado num grupo de estudos para a certificação MCM no qual estou participando. O grupo foi iniciado pelo MVP Jason Strate ( blog | @StrateSQL ) e quem quiser mais informações pode acessar este post dele: http://www.jasonstrate.com/2011/12/sql-mcm-study-group/.

Vocês poderão baixar o banco de dados corrompido aqui.

Vamos começar a análise então. Antes de mais nada, precisamos deixar nosso banco de dados disponível em nossa instância. A maneira mais simples de fazer isto é anexar (attach) a base, seja pela interface gráfica ou via comando, desta forma:

CREATE DATABASE [CorruptDB1] ON
( FILENAME = N'C:\temp\CorruptDBs\CorruptDB1\DBFiles\CorruptDB1.mdf' ),
( FILENAME = N'C:\temp\CorruptDBs\CorruptDB1\DBFiles\CorruptDB1_log.ldf' )
FOR ATTACH;
GO

Substitua o caminho “C:\temp\CorruptDBs\…” para o local onde você escolher descompactar os arquivos.

Uma vez que o banco de dados estiver anexado, vamos rodar um DBCC CHECKDB para ver qual o estado do nosso banco.

DBCC CHECKDB(CorruptDB1)
WITH ALL_ERRORMSGS, NO_INFOMSGS

Utilizei as opções ALL_ERRORMSGS e NO_INFOMSGS para exibir como resultado somente mensagens de erro e ignorar mensagens informativas. Se desejar mais informações sobre o comando DBCC CHECKDB, clique aqui. O resultado que temos é o seguinte:

Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data),
page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12716041 and -4.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘(Object ID 99)’ (object ID 99).
CHECKDB found 1 allocation errors and 0 consistency errors in database ‘CorruptDB1′.

Há algo errado com nosso banco de dados. E agora, que ação devemos tomar?

O comando CHECKDB possui duas opções chamadas REPAIR_ALLOW_DATA_LOSS e REPAIR_REBUILD. A primeira impressão é “…ótimo, o DBCC CHECKDB vai resolver meu problema de corrupção!”.

A primeira opção “tenta” reparar o problema de corrupção e pode ocasionar perda de dados. Já a segunda opção “tenta” executar reparos que não possibilitem perda de dados. Como não queremos perder nenhum dado da base, vamos executar a segunda opção primeiro. Vou alterar o acesso do banco de dados para SINGLE_USER e vou executar estas opções.

ALTER DATABASE CorruptDB1 SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO

DBCC CHECKDB(CorruptDB1, REPAIR_REBUILD)
WITH ALL_ERRORMSGS, NO_INFOMSGS

E temos o seguinte resultado:

Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.
The repair level on the DBCC statement caused this repair to be bypassed.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘(Object ID 99)’ (object ID 99).
CHECKDB found 1 allocation errors and 0 consistency errors in database ‘CorruptDB1′.

Hummm… Nada resolvido. Ainda tivemos o erro 8939. Vamos forçar a barra e tentar o reparo com possível perda de dados.

DBCC CHECKDB(CorruptDB1, REPAIR_ALLOW_DATA_LOSS)
WITH ALL_ERRORMSGS, NO_INFOMSGS

E o resultado:

Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.
The repair level on the DBCC statement caused this repair to be bypassed.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘(Object ID 99)’ (object ID 99).
CHECKDB found 1 allocation errors and 0 consistency errors in database ‘CorruptDB1′.

Novamente, nada feito. Pelo nível de corrupção do banco de dados, o comando DBCC CHECKDB não consegue reparar este problema. Vamos ter que fazer uma análise um pouco mais profunda e por a mão na massa para resolver o problema.

Nós vamos encontrar a explicação deste erro aqui. Em linhas gerais, ele nos informa que foi realizada uma validação numa determinada página, e esta validação falhou por uma corrupção no cabeçalho (Header) da página. Interessante não?!

Analisando a mensagem completa de erro que nos foi dada, podemos observar que ela nos informa qual é a página que está com problema: “…page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. …”. Fica a dica: LEIA TODA A MENSAGEM DE ERRO!!! Achei que isto deveria ficar em destaque pois é muito comum ver as pessoas sem saber o que fazer e a mensagem de erro te dá dicas valiosas sobre o que aconteceu. Nem sempre é assim, mas na maioria das vezes é válido. Vamos dar uma olhada nesta página:

DBCC TRACEON(3604)
GO
DBCC PAGE('CorruptDB1', 1, 7, 3)

Quer saber mais sobre o Trace Flag 3604 e sobre o comando DBCC PAGE, acesse aqui e aqui.
O resultado completo que temos é o seguinte:

DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.PAGE: (1:7)BUFFER:BUF @0x000000008EFA8F40bpage = 0x000000008E17E000           bhash = 0×0000000000000000           bpageno = (1:7)
bdbid = 17                           breferences = 0                      bcputicks = 0
bsampleCount = 0                     bUse1 = 50557                        bstat = 0xc00809
blog = 0×21212159                    bnext = 0×0000000000000000PAGE HEADER:Page @0x000000008E17E000m_pageId = (1:7)                     m_headerVersion = 0                  m_type = 0
m_typeFlagBits = 0×0                 m_level = 0                          m_flagBits = 0×200
m_objId (AllocUnitId.idObj) = 99     m_indexId (AllocUnitId.idInd) = 0    Metadata: AllocUnitId = 6488064
Metadata: PartitionId = 0            Metadata: IndexId = 0                Metadata: ObjectId = 99
m_prevPage = (0:0)                   m_nextPage = (0:0)                   pminlen = 90
m_slotCnt = 2                        m_freeCnt = 6                        m_freeData = 8182
m_reservedCnt = 0                    m_lsn = (0:0:1)                      m_xactReserved = 0
m_xdesId = (0:0)                     m_ghostRecCnt = 0                    m_tornBits = 105713478Allocation StatusGAM (1:2) = ALLOCATED                SGAM (1:3) = NOT ALLOCATED           PFS (1:1) = 0×44 ALLOCATED 100_PCT_FULL
DIFF (1:6) = CHANGED                 ML (1:7) = NOT MIN_LOGGED
Msg 2514, Level 16, State 5, Line 1
A DBCC PAGE error has occurred: Invalid page type – dump style 3 not possible.

Obviamente houve erros no resultado. Mas o que chama a atenção são os pontos que destaquei em negrito. Se dermos uma olhada no Internals (um modo “carinhoso” de chamar o livro Microsoft SQL Server 2008 Internals), veremos no capítulo 3, página 147, parágrafo 2 ( :-O Não, eu não decorei isto, fui ver no livro… ^.^ ) as explicações sobre as páginas de alocação de dados, em resumo, assim:

  • Page 0 – File Header
  • Page 1 – PFS Page Free Space
  • Page 2 – GAM Global Allocation Map
  • Page 3 – SGAM Shared Global Allocation Map
  • Page 4 e Page 5 – não são utilizadas
  • Page 6 – DCM Differential Changed Map
  • Page 7 – BCM Bulk Changed Map

Isto nos leva à conclusão de que a página que temos corrompida neste banco de dados é a página BCM, Bulk Changed Map. Não vou entrar neste momento no detalhe das páginas de controle, ficando apenas por dizer que é uma das páginas de controle de alocação de dados do SQL Server.

Ótimo! Agora sabemos o que fazer. Podemos então fazer o restore desta página e tudo resolvido. Será?!
Vamos tentar.

USE MASTER;
GO

RESTORE DATABASE CorruptDB1
   PAGE = '1:7'
FROM DISK = 'C:\temp\CorruptDBs\CorruptDB1\Bak\CorruptDB1.bak'
WITH RECOVERY

Vamos utilizar o comando RESTORE para restaurar somente a nossa página corompida. O resultado que temos é:

Msg 3111, Level 16, State 1, Line 2
Page (1:7) is a control page which cannot be restored in isolation. To repair this page, the entire file must be restored.
Msg 3013, Level 16, State 1, Line 2
RESTORE DATABASE is terminating abnormally.

Ops! O SQL Server não nos permite restaurar isoladamente páginas de controle… E nos informa que para resolução do problema temos de restaurar o arquivo completo.

Solução para o problema e evitar perda de dados. Faça um backup de log (Tail Log Backups) e aplica um restore do banco de dados e depois aplique os logs na sequência, se houver, e por último aplique o último backup de log gerado (tail log). Depois de seguir estes passos, execute novamente o comando DBCC CHECKDB para ter certeza de que seu problema foi resolvido.

Esta foi a solução que encontrei para este problema de corrupção.


Veja também:

Integridade do Banco de Dados

Possible Index Corruption. Diagnosticando o problema

Corruption demo databases and scripts

Corrigindo Erro de Suspect Database (novo)

Corrompendo um Banco SQL (novo)

Corrupção de Dados direto das trincheiras (novo)

Ver páginas corrompidas (SQL Server)

Verificação de Página e Restore de Bases no SQL Server

Recriando as databases de sistema

Automatizando a verificação de integridade de seus bancos de dados

Como Restaurar o Master, Model e MSDB

Entendendo e Melhorando seus backups (SQL Server)

Restaurando um Database Suspect – SQL Server

Databases em modo Suspect e Pendente Recovery

Creating, detaching, re-attaching, and fixing a SUSPECT database

Backup no SQL Server

O que é Backup?
Backup
é um termo inglês que tem o significado de cópia de segurança. É frequentemente utilizado em informática para indicar a existência de cópia de um ou mais arquivos guardados em diferentes dispositivos de armazenamento. Se, por qualquer motivo, houver perda dos arquivos originais, a cópia de segurança armazenada pode ser restaurada para repor os dados perdidos. Fonte: Significados (+)

————————————————————————–

Este artigo escrito pelo Vladimir Magalhães sobre Performance de Backup é bastante interessante e resolvi compartilhar com todos, vejam…

” Quando falamos de backup, muita gente se preocupa com o lugar onde estes serão armazenados, período de retenção dos backups, tipos de backup utilizados (full, differencial, log, etc..), mas e quanto a performance?

Sim, você pode (e deve!) configurar seus backups para que sejam feitos da forma mais performática possível, pois lembre-se, estes costumam consumir muitos recursos do seu servidor enquanto são executados.” (MAIS…)

————————————————————————–

Todos os direitos são reservado aos autores dos artigos e posts, abaixo segue uma lista de links, categorizada por assunto, que redireciona ao site ou blog do respectivo autor.

Vejam também:

Estratégia de Backup

Fazer backup na nuvem ou em uma ferramenta efetiva?

Dica sobre Backups

Simulando – Desastre e Recuperação de Bancos de Dados – Microsoft SQL Server 2008 R2 e 2012 ( Parte 1 | Parte 2 | Parte 3 | Parte 4 | Final )

SP_BACKUP – Gerencie suas rotinas de modo simples, fácil e objetivo.

Como Restaurar o Master, Model e MSDB

Obtendo informações sobre Modelo de Recuperação, Contadores de Desempenho, Nível de Compatibilidade de Banco de Dados por Instância no Microsoft SQL Server 2005, 2008 e 2008 R2.

Compactação de Backup com o SQL Server 2008

Lendo Informações do Backup – SQL Server

Criação e Restauração de Backup – SQL Server 2005 ( Parte 1 | Parte 2 | Parte 3 | Parte 3.1 )

Plano de Manutenção: Automatizando Backups no SQL Server

SQL SERVER – Database in RESTORING State for Long Time

Query último Backups – SQL Server

O ultimo backup full executado com sucesso

Como recuperar um banco de dados apagado acidentalmente sem ter o backup

Script – Gerando comando de restore dinamicamente

RESTORE VERIFYONLY (Transact-SQL) – Verificar Backup

Restore Parcial no SQL Server

Realizando Backups SSMS

Realizando Backups T-SQL

Tempo restante para finalizar execução do Backup no Microsoft SQL Server 2008 e R2.

Script – Pesquisando arquivos de backups em um diretório com T-SQL

Tipos de Backup no SQL Server (Vídeo Youtube).

Fazendo Backups no SQL Server 2008 R2 (Vídeo Youtube).

Simulando – Minimal Logging – Microsoft SQL Server 2008 R2 e 2012.

Life Consultant: Restore With StandBy

SQL Server 2012 – Database Recovery Advisor

Database Recovery Advisor–SQL Server 2012 (Quick Post)

AUTOMATE SQL SERVER EXPRESS BACKUPS WITH POWERSHELL

Histórico de Backups – Pivot

Obtendo Histórico de Execução de Backups de Bancos de Dados no Microsoft SQL Server 2008, R2 ou 2012

Listando informações sobre backups do DPM

Restoring SQL Server backups made with System Center Data Protection Manager using Powershell – New Version

{ Alex Souza }