Conheça a maratona Microsoft Open Source + Azure

Registre-se para uma ou mais das 5 especializações oferecidas nos Treinamentos de Open Source + Azure

 

Maiores detalhes de cada curso:

www.microsoftdiplomados.com/brasil

DELETE, TRUNCATE e DROP TABLE Suas Semelhanças e Diferenças ..

Hoje gostaríamos de compartilhar sobre uma dúvida clássica de desenvolvedores e alguns DBA’s que estão começando a se aprofundar. E então, qual a diferença entre Delete, Truncate Table e Drop Table? 

Quando e qual as melhores situações que devemos usar cada um destes comandos ?

Para melhor exemplificar essas diferenças, ilustramos com a tabela abaixo:

/* Apagando a tabela "clientes" e seus dados, sua primary key, 
   as foreign keys e índices */
  DROP TABLE dbo.CLIENTES

/* Apagando todos os dados da tabela "clientes"  
   e reduzindo a fragmentação dos índices e tabelas para 0 */
  TRUNCATE TABLE dbo.CLIENTES

/* Apagando os dados de clientes que são do estado de São Paulo. 
   Neste caso, cada linha apagada será logada e a fragmentação
   dos índices e tabelas não será alterado */
  DELETE FROM dbo.CLIENTES WHERE UF = 'SP'


Considerações finais:

• O comando DROP TABLE apaga a tabela e sua estrutura. O objeto será eliminado do banco. Esse comando não apaga apenas os dados
• Os comandos DROP TABLE e TRUNCATE TABLE não geram logs detalhados das operações. Eles apenas gravam que o comando foi executado e as páginas afetadas. Por isso, eles ocupam pouquíssimo espaço na transaction log / redo log e são executados tão rapidamente. O lado ruim disso, é que se um dia você precisar fazer um restore imediato usando o log do banco após alguém ter feito um TRUNCATE TABLE, isso não será possível. O comando DELETE, log cada linha que foi deletada, gerando uma quantidade de registros de log muito grande (Devido à cláusula WHERE), dependendo do tamanho da tabela. Isso permite que você possa realizar um restore imediato após alguém ter realizado um DELETE errado, mas pode estourar sua transaction log / redo log se estiver apagando uma quantidade de registros muito grande
• O comando TRUNCATE TABLE apaga TODOS os registros de uma tabela. Além disso, ele reinicia o auto incremento (se houver), reduz a fragmentação da tabela e índices para 0, quase não gera log e é executado rapidamente no banco, mesmo com tabelas muito grandes. Para rotinas onde todos os dados são apagados e gerados novamente a cada execução, é a solução mais recomendada
• Uma vez que o TRUNCATE simplesmente exclui todas as páginas e extensões de uma tabela, não seria possível validar se algum desses registros é referenciado por alguma tabela filha. O DELETE loga linha a linha e caso não haja violação de integridade referencial é possível utilizá-lo mesmo em tabelas referenciadas. A opção CASCADE é capaz de propagar as atualizações para o DELETE, mas não para o TRUNCATE uma vez que esse comando não mantém a relação de linhas afetadas e não é portanto capaz de propagar seus efeitos
• No Oracle Database, existe uma trigger que é disparada no evento “AFTER TRUNCATE ON Database”, que pode ser utilizada após algum comando de TRUNCATE, para logar qual o usuário que executou o comando, por exemplo. Mas não existe trigger específica para antes da execução do comando. Isso pode ser criado utilizando uma trigger que é disparada no evento “BEFORE DDL ON Database”, mas não é uma solução “oficial”
• As views indexadas materializam dados de uma tabela ou de várias tabelas combinadas. Se o TRUNCATE fosse executado em uma tabela participante, a view indexada simplesmente ficaria inválida, pois os comandos de exclusão individuais não seriam logados e uma falha não permitiria que o banco se recuperasse (não haveria tracking das alterações) para refazer o índice da view
• Por se tratarem de operações diferentes (DML x DDL), os privilégios exigidos para execução do comando DELETE é diferente dos necessários para DROP TABLE e TRUNCATE TABLE
• Os comandos DROP TABLE e TRUNCATE são praticamente idênticos em todas as comparações. A única diferença entre ambos, é que o DROP TABLE apaga os objetos e metadados do banco, enquanto o TRUNCATE TABLE apenas deixa a tabela vazia (sem registros)

Conheça o Microsoft Data Migration Assistant (DMA)

Microsoft disponibilizou para download o Microsoft SQL Server Migration Assistant. Disponível para MySQL, Sybase, Oracle Database, IBM DB2 e Access, o Microsoft SQL Server Migration Assistant é uma ferramenta gratuita que simplifica o processo de migração destes produtos para o SQL Server, Azure SQL e principalmente upgrade entre versões do próprio SQL Server.

A ferramenta automatiza todos os aspectos da migração e inclui o suporte para migração do MySQL 4.1 e posteriores, Sybase ASE 11.9 e posteriores, Oracle Database 9.07.3 e posteriores, e Access 97 e posteriores para todas as edições do SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, SQL Server 2014, 2016 e para o Azure SQL.

No caso do IBM DB2, ele suporta a migração das versões 9.0 e 10.0 no z/OS e das versões 9.8 e 10.1 no Linux/Unix/Windows para o SQL Server 2012, SQL Server 2014,2016 e Azure SQL.

O Microsoft SQL Server Migration Assistant é compatível com o Windows 10 , Windows 7, Windows 8, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 e Windows Server 2012 R2. Ele também requer o .NET Framework 4.0 ou posterior. 

BAIXE O MICROSOFT SQL SERVER MIGRATION ASSISTANT

Microsoft® Data Migration Assistant v3.0

https://www.microsoft.com/en-us/download/details.aspx?id=53595

– Download da versão 6.0.1 para MySQL
– Download da versão 6.0.1 para Sybase
– Download da versão 6.0.1 para Oracle Database
– Download da versão 6.0.1 para Access
– Download da versão 6.0.1 para IBM DB2

As páginas de download também listam alguns requisitos específicos, como MySQL Connector/ODBC v5.1 e Sybase OLEDB/ADO.Net/ODBC provider.

SQL Server runing on #Linux today ...

SQL Server runing on #Linux today ...

Na manha de hoje iniciamos pela primeira vez uma instancia SQL Server
restaurando um Database gerado no Windows ..
conectado com aplicação ..

100% funcional ..

Em breve trago maiores informações e novidades !!!!

Sinceramente não acreditei que viveria para ver este momento microsoft rs ..
a abertura das plataformas e fim do monopólio \o/

SQL Server: Modelos de recuperação de dados.

Dentre as rotinas do SQL Server as operações de backup e restauração ocorrem no contexto do modelo de recuperação do banco de dados pré-definido. Os modelos de recuperação são projetados para controlar a manutenção dos log's de transações. Um modelo de recuperação é uma propriedade de banco de dados que controla como as transações são registradas, se o log de transações exige (e permite) backup e que tipos de operações de restauração estarão disponíveis. Existem três modelos de recuperação: simples, completo e bulk-logged. Geralmente, um banco de dados usa o modelo de recuperação completa ou o modelo de recuperação simples. É possível alternar para outro modelo de recuperação do banco de dados a qualquer momento. 
(Em Database > Propreties > Options > Recovery model:)

Modelos De Recuperação (detalhes):

Simple (simples)

Não suporta backups de log automaticamente requer disponibilidade de espaços menores, eliminando essencialmente a necessidade de gerenciar o espaço de log de transações. O que pode ser um ponto critico para sua aplicação as alterações desde o backup mais recente estão desprotegidas. No caso de um desastre, essas alterações são perdidas até a data do ultimo backup. Este modo não suporta as opçoes de AlwaysOn ou espelhamento de banco de dados, e recuperações pontuais.

*
É ideal para ambientes de desenvolvimento, testes ou mesmo bases OLAP, onde não é necessário fica fazendo backup para voltar a um determinado registro de tempo.

Full (completo)

Necessariamente requer o backups dos logs em intervalos de tempos. Nenhum trabalho é perdido devido a um arquivo de dados perdidos ou danificado. Pode executar uma recuperação pontual (por exemplo, antes de um erro de aplicativo ou usuário). Garantido a integridade dos dados ate o ultimo log pontual gerado.

Neste modelo de recuperação completa, depois de restaurar o backup de dados completo você deve restaurar todos os backups de log (transações subsequentes) para recuperar o banco de dados. Permitindo restaurar um banco de dados a um ponto de recuperação específico dentro de um destes backups de log. O ponto de recuperação pode ser uma data e hora específica, uma transação marcada ou um LSN (número de sequência de log).

*Quando o banco de dados está com o recovery model full ou Bulk-logged, todas as transações processadas pelo SQL Server são registradas no log de transação (arquivos .ldf), e cada instrução executada recebe um número de seqüência (LSN).

Backup Diferencial

Um backup diferencial tem como base no backup de dados completo anterior e mais recente. Um backup diferencial captura apenas os dados que foram alterados desde o backup completo. O backup completo no qual um backup diferencial se baseia é conhecido como a base do diferencial. Os backups completos, com exceção dos backups somente cópia, podem servir como base para uma série de backups diferenciais, inclusive backups de banco de dados, backups parciais e backups de arquivo. O backup de base para um backup diferencial de arquivo pode ser contido dentro de um backup completo, um backup de arquivo ou um backup parcial. 

A criação de um backup diferencial pode ser muito rápida se comparada à criação de um backup completo. Um backup diferencial registra apenas os dados que mudaram desde o backup completo. No entanto, antes de restaurar um backup diferencial, é necessário restaurar sua base. Portanto, a restauração de um backup diferencial precisará, necessariamente, de mais etapas e mais tempo do que a restauração.

*

Backups de banco de dados de diferencial são especialmente úteis se um subconjunto de um banco de dados é modificado mais frequentemente do que o restante do banco de dados. O uso de backups diferenciais reduz o número de backups de log caso necessário uma restauração.

Bulk-logged

Um complemento do modelo de recuperação Full-completol permite operações de cópia em massa de alto desempenho. Reduz o uso de espaços de log usando o mínimo de registro em log para a maioria das operações em massa. O modelo de recuperação bulk-logged é um modelo de recuperação com finalidade especial que só deve ser usado raramente para melhorar o desempenho de determinadas operações em massa de larga escala, como por exemplo importações de dados em grandes volumes de dados. Não ficam registradas Operações pontuais como SELECT INTO, BCP, BULK INSERT,CREATE INDEX e operações com os tipos de dados texto e ntext. Muito da descrição do backup no modelo full (completo) também se aplica ao modelo de recuperação bulk-logged. 

Comparado ao modelo de recuperação completa, que faz log completo de todas as transações, o modelo de recuperação bulk-logged faz o log de operações em massa de forma mínima, embora faça o log completo de outras transações. O modelo de recuperação bulk-logged protege o sistema contra falha de mídia e, para operações em massa, fornece o melhor desempenho usando o mínimo de espaço em log. Entretanto, o modelo de recuperação bulk-logged aumenta o risco de perda de dados nessas operações de cópia em massa, porque operações com log em massa impedem a recaptura de alterações em uma base transação por transação. Se um backup de log contiver operações bulk-logged, você não poderá executar uma restauração pontual no backup de log em determinado ponto; só poderemos restaurar todo o backup de log. 

Obs: Ao restaurar um banco de dados, particularmente com o modelo de recuperação completa ou o modelo de recuperação bulk-logged, você deve usar e respeitar o numero de sequencia dos backups de log gerados LSN. Que é uma sequência unica de restauração, por uma ou mais etapas da restauração (sequencia) Exemplo Backup full 8:00 am, restaure o primeiro log 8:10, restaure o segundo log 8:20 e sequencialmente é impossível pular qualquer um destes backups de log / sequencia.

SQL Server 2016: Mas quanto custa? Preços e licenciamentos ..

Nas palavras da própria Microsoft  abre aspas rs "O licenciamento do novo SQL Server 2016 torna a escolha da edição certa simples e econômica. Ao contrário de outros grandes fornecedores, não é preciso pagar complementos caros para executar seus aplicativos mais exigentes, pois todos os recursos e funcionalidades já estão integrados." fecha aspas rs ...

Em detalhes na tabela abaixo:
Preços do SQL Server

• *Os clientes que precisam de um data warehouse MPP (processamento paralelo em massa) agora têm acesso a um PDW (data warehouse paralelo) por meio das licenças básicas Enterprise Edition com Software Assurance. O PDW faz parte do Microsoft Analytics Platform System (APS).
• **As edições vendidas no modelo de licenciamento por núcleo são vendidas como pacotes de 2 núcleos.
• ***O preço representa o preço de varejo estimado Open NL (No Level). Para obter seu preço específico, contate o revendedor da Microsoft.
• ****As CALs (licenças de acesso para cliente) custam US$ 209/licença e são obrigatórias para cada usuário ou dispositivo que acessa um servidor no modelo de licenciamento Servidor + CAL. Consulte os direitos de uso do produto para saber detalhes.

Mais detalhes e informações no catalogo oficial de licenciamento microsoft

disponivel em: SQL_Server_2016_Licensing_Guide_EN_US.pdf

Conheça o Google BigQuery

O Google apresentou seu serviço de análise de Big Data, o BigQuery. 
(Solução voltada para análise interativa de grandes conjuntos de dados).

O Google lançou seu serviço de Big Data, o BigQuery, desde meados de 2012, pois é, 

Se a novidade promete agradar? Me parece que não muito, com a promessa de analisar os terabytes de dados com apenas um clique. O serviço, baseado em nuvem, combina o armazenamento de dados NoSQL com os recursos de pesquisa em linguagem SQL

Solução é voltada para análise interativa de grandes conjuntos de dados. O Google afirmou que o BigQuery não é uma base de dados isolada, sendo contratado com a solução de hospedagem em nuvem, o serviço Google Cloud SQL baseado em MySQL.

Como sistemas NoSQL, o BigQuery não usa esquemas fixos; o Google disse que os dados normalmente são adicionados usando um pequeno número de grandes dimensões, que serão arquivos de tabelas Append Only (gravados apenas em modo incrementais e não podem ser removidos e renomeados. Além disso, novos links não são criados para estes arquivos). O serviço suporta consultas ad-hoc, relatórios, exploração de dados, ou até mesmo aplicativos baseados na Web que funcionam com esses conjuntos de terabytes de dados. Os usuários interagem com o serviço através de uma ferramenta , o navegador BigQuery, uma ferramenta de linha de comando, ou através de chamadas para uma API baseada em RestT usando Java, Python, ou outras línguas.

Publicidade

A principal utilização do serviço é provável que seja a análise de dados de publicidade da propria plataforma Google, que já reside em cloud da companhia. "Quando um anunciante quer entender o ROI [retorno sobre investimento] ou a eficácia de uma campanha de palavra-chave em execução em todo o mundo, tem um grande problema de Big Data", afirmou Ju-Kay Kwek, gerente de produto da equipe Cloud Platform, durante a preview público do BigQuery.

Os clientes do Google Adwords normalmente extraem dados do serviço com API do AdWords, a fim de construir no bancos de dados locais para análise posterior. Mas esses bancos de dados muitas vezes se tornam de difícil controle, exigindo sharding (ou uma partição horizontal em um motor de banco de dados ou de pesquisa) um retrabalho complexo, já que as etapas de indexação são organizadas de tal forma que "os clientes às vezes perdem a noção das questões que eles queriam perguntar por causa do tempo que o dado fica indisponível ", disse Kwek.

Os clientes também poderão fazer upload de seus próprios dados no BigQuery, e o Google contará com uma variedade de recursos para desenvolvedores externos. Usuários beta do serviço assumiram desafios como a segmentação adWeb e e-commerce. O fornecedor de inteligência de negócios o francês We Are Cloud testou o BigQuery como uma alta escala de armazenamento de dados, para sua própria consulta, análise e visualização de dados de capacidades. A empresa diz que a tecnologia irá libertar seus clientes da árdua tarefa de gerenciar uma grande plataforma local, para consultas rápida e análise de dezenas de terabytes de dados.

Atrair grandes clientes de dados certamente reforça o negócio de armazenamento online do Google, que só tem um grande motivo para conseguir isso, por meio do Google Drive. O armazenamento de dados no serviço BigQuery custa media US$ 0,12 por gigabyte por mês para até dois terabytes, com custos decrescentes acima desse volume. A análise BigQuery  custa US$ 0,35 por gigabyte de dados processados.

Confirmando o que sempre pensamos: BigData não é para todos, nem para todas as aplicações.

Maiores informações:
https://cloud.google.com/bigquery