Backup With Access Key Credential

Continuando a nossa série Backup Database DB TO URL = ‘Blob Storage’, falaremos hoje sobre uma das formas de realizar este backup.

Para realizarmos o backup para o Blob Storage, temos que criar uma credencial no SQL Server e para este tipo de operação, temos dois tipos de credenciais:

  • Access Key Credential;
  • Shared Access Signature.

Neste post, falaremos somente da Access Key Credential.

Independente da forma que iremos realizar nosso Backup, será necessário criar uma credencial no SQL Server.

Para realizar o backup com a Access Key Credential, temos que ter em mãos a Storage Account Name e a Key do Storage. Para identificar esta informação em seu Blob Storage, basta ir na coluna “Access Keys” que fica no canto esquerdo da parte gráfica:

CreateCredential1

CreateCredential2

Neste nosso exemplo, estamos utilizando uma storage account com o nome StgComunidadeSQLServer1 do tipo General PurposeV1(GPV1).

De posse desta informação, iremos criar a credencial na minha instância SQL Server com a seguinte Sintaxe:


CREATE CREDENTIAL BlobGP1

WITH IDENTITY = 'Storage Account Name',

SECRET = 'Key1 or Key2'

Para conferir se a credencial foi criada conforme desejado, basta realizar a consulta na seguinte DMV:


SELECT *

FROM sys.credentials

CreateCredential3

 

Após criar a credencial, realizaremos o Backup para o Blob Storage utilizando a sintaxe BACKUP DATABASE passando a URL do contêiner onde ficará meus Backups. Para identificar a URL do meu contêiner, basta realizar os seguintes passos:

BackupToURL1

Dentro da minha Storage Account “stgcomunidadesqlserver1” clicar na opção “Blobs”.

 

backuptourl2

Dentro da opção “Blob” clicar no contêiner “Backup”.

 

backuptourl3

Dentro do Contêiner “backup”, clicar em “Propriedades”.

Ps: Podemos observar que neste momento o meu contêiner está vazio não possuindo nenhum backup.

 

backuptourl4

Dentro das propriedades no contêiner, copiamos a URL para utilizar em meu comando de Backup.

Agora basta realizar o seu backup, passando a URL que acabamos de capturar no Azure, mais o nome do backup que será realizado. Na opção “With” passar a credencial que criamos com todas as informações de acesso ao Blob.


BACKUP DATABASE ComunidadeSQLServer TO URL = 'https://stgcomunidadesqlserver1.blob.core.windows.net/backup/comunidadesqlserver.bak'

WITH CREDENTIAL = 'BlobGP1', STATS = 10

Agora vamos observar o resultado do meu Backup:

backuptourl5

Indo novamente em meu contêiner “Backup” (que anteriormente estava vazio), podemos encontrar o backup realizado.

Como podemos observar, quando realizamos um backup com a opção “with credential” e passando a credencial do Blob, o backup vai como tipo “page”.

Agora que meu backup está sendo realizado corretamente, não preciso me preocupar com mais nada, correto?

Errado! Além da rotina de expurgo que temos que definir para o nosso ambiente de acordo com as regras e necessidades do negócio, temos que nos preocupar com o custo que este tanto de backup armazenado vai gerar para empresa em que trabalho.

No Azure, somos cobrados por quantidade em GB que armazenamos em nossa Storage Account. Então temos que ter uma combinação adequada de tipo de storage account + tipo de performance+ camada de acesso para termos um custo benefício ideal.

Neste meu exemplo, estou realizando o backup para a Storage Account do tipo GPV1 e ela está indo com o tipo de blob “page”. Para este tipo de blob nesta storage account, temos a seguinte precificação:

Price1

Fonte: https://azure.microsoft.com/en-us/pricing/details/storage/page-blobs/

 

Podemos observar que esse valor é para performance do tipo Standard, se fosse Premiunm seria muito mais caro.

Agora se observarmos a Storage Account do tipo “Blob” podemos perceber que os valores são bem mais em conta:

Price2

Fonte: https://azure.microsoft.com/en-us/pricing/details/storage/blobs/

 

Mesmo na camada Hot já fica mais barato. Mudando para a camada Cool, diminuiremos bastante o preço e dependendo do seu período de retenção e colocando na camada de acesso Archive, o preço por GB cairia significantemente.

Há Raiane, se é assim então, porquê não realizamos o nosso backup direto para o storage account do tipo blob?

Lembram que no post anterior foi informado que neste tipo de storage account não aceitamos blobs do tipo PAGE? Pois é… Infelizmente realizando o backup com o tipo de credencial Access Key ele vai com o tipo PAGE, não podendo realizar diretamente para o a storage account do tipo blob.

Para solucionarmos esse problema, vamos então criar uma rotina que passar esse backup que acabamos de realizar do Storage GPV1 para o Storage Blob, desta forma podemos continuar realizando o nosso backup com a access key credential e economizar uma grana com armazenamento.

Então para não me prolongar muito, no próximo post falaremos sobre Rotina de transferir Blob do tipo Page de uma Storage Account GPV1 para a Storage Account Blob  com access tier Cool.

 

Até o próximo post!

 

Anúncios

Introdução ao Blob Storage

Para entendermos algumas soluções de backup que irei apresentar aqui, precisamos entender o que é um Blob Storage. Então de forma simples, Blob Storage é uma solução da Microsoft de armazenamento de objetos para a nuvem.

Para podermos utilizar esta solução, precisamos criar uma Storage Account no Azure.

As Storages Account são divididas em conteiners e são nos conteiners que “despejamos” nossos dados, ou seja, nossos blobs.

Blob

Os blobs são divididos em três tipos:

  • Block – texto, dados binários:
    • Exemplos: .bak,  .txt, .csv …
  • Append – Igual ao Block Blob, porém otimizado para operações incrementais.
  • Page – VHD files:
    • Exemplos: vhs, .mdf, .ldf, .bak .

Obs.: Podemos observar que o .bak pareceu tanto como Block Blob como Page Blob. Este exemplo foi colocado de propósito, pois iremos explorá-lo melhor nos próximos posts.

Além disso, temos três tipos de Access Tiers (camadas de acessos) que influencia diretamente no acesso, recuperação e precificação dos seus Blobs.

  • Premium (Preview em 08/10/2018) : Oferece melhor performance para dados acessados frequentemente:
    • Não entrarei em detalhes sobre esta camada de acesso, pois os testes não foram realizados o levando em consideração e como podem ver, acabou de sair do forno.
  • Hot:
    • Menor custo nas operações de IO;
    • Maior custo de armazenamento.
  • Cool (cold):
    • Maior custo nas operações de IO;
    • Menor custo de armazenamento;
    • Para ter uma economia real, o blob deverá ficar armazenado por ao menos 30 dias.
  • Archive:
    • Menor custo de armazenamento de todos os Tiers;
    • SLA de até 15h para recuperar as informações;
    • Para ter uma economia real, o blob deverá ficar armazenado por ao meno 180 dias.

Para mais informações sobre o access tiers acessar o link da Microsoft.

2-CamadasDeAcesso

Fonte: http://blog.archive360.com/to-tier-or-not-to-tier-is-no-longer-the-question

As Storage Accounts são divididas em três tipos:

  • Blob Storage:
    • Dados não estruturados;
    • Block e append;
    • Cool e Archive.
  • General-Purpose v1(GPV1):
    • Uso geral;
    • Block, append e page.
  • General-Purpose v2(GPV2):
    • Uso geral;
    • Block, append e page,
    • Hot, cool.

A diferença entre GPV1 e GPV2 está na velocidade de acesso à informações e também na diferença de tarifação. Além de que no GPv1 não tem access tier , sendo que no GPV2 aceita o accees tier Hot, Cool e Archive facilitando a administração dos seus arquivos e também já é o recomendo para os projetos novos.

E por último temos dois tipos de camadas de performance:

  • Standard
    • HDD;
    • Mais barato.
  • Premium
    • Somente page blobs;
    • SSD;
    • Mais caro.

Esta imagem resume legal tudo que foi explicado aqui:3-ResumoBlobStorage-AccesTiers-PeformanceTiers

Fonte: https://insidemstech.com/tag/general-purpose-v2/

Então para começar, segue um breve tutorial de como criar uma storage account:

4-CriarBlob

  • Clicar em All Services;
  • Digitar “Storage Account”.

5-CriarBlob-SelecionarServico

  • Clicar em “Storage Account”;
  • Clicar em “Create”.

6-CriarBlob-PreencherInformacoes

  • Colocar o nome do seu storage account. O nome deve conter somente letras minúsculas mais números. Aqui recomendo já ter escolhido um padrão para identificar seus storages account. No meu caso escolhi colocar o prefixo “stg”;
  • Escolher o tipo de performance “Standard” ou “Premium”. Podem observar que ao clicar em Premium, a sua escolha de “Acces Tier” (identificado com o número 5 na imagem) some e aparece uma informação que somente page blob é aceito para este tipo de performance;
  • Tipo de storage account (conforme já explicado anteriormente neste post);
  • Escolher o tipo de replicação (local, geográfico ou geográfico e habilitado para leitura);
  • Escolher o access tier conforme já explicado anteriormente. Podem observar que o Archive não é uma opção aqui, pois sua configuração é específica do blob. Aqui neste caso você escolhe o access tier padrão da storage account, mas o mesmo pode ser alterado especificamente para cada blob.

7-CriarBlob-Validacao

Aqui você confirma as informações configuradas.

8-CriaBlob-Confirmacao

Prontinho! Aqui sua Storage Account já está criada.

Até o próximo post “Backup With Access Key credential  (utilização/limitações)”

BACKUP DATABASE DB TO URL = ‘BLOB STORAGE’

Introdução

Ano passado comecei a trabalhar com Azure e tive que adaptar minhas rotinas de Backup para a nuvem. Ao estudar um pouco mais sobre as opções de backups para a nuvem, vi que existiam várias e que bastaria verificar qual melhor se encaixaria à minha realidade. Após ter escolhido de qual forma realizaria os meus backups, esbarrei em algumas limitações e vi também que mais soluções apareciam. Então, quero realizar uma série de posts ao longo de algumas semanas que mostram opções de realizar backups para a nuvem.

A agenda será dividida da seguinte forma:

Sobre as três primeiras opções, a Sulamita Dantas e eu realizamos uma palestra no SQL Saturday 792 de Brasília e após esta palestra veio a vontade de transformar isso em post.

Lembrando que os posts são estudos que realizei baseados em dificuldades que tive no dia-a-dia e soluções específicas para o cenário que eu tinha.

Se você está na nuvem, recomendo fortemente sempre ficar antenado às novidades, pois as evoluções são constantes e muitas destas novas features facilitarão muito a sua vida. Talvez uma limitação que você tem hoje pode ser sanada daqui a alguns meses e, justamente por este motivo, colocarei aqui opções de soluções. Caberá à você achar a melhor para o seu ambiente.

Então, usarei este post como controle (atualizarei os tópicos redirecionando para a URL correta de cada assunto) e deixo claro aqui que, para estas soluções, deveremos ter familiaridade com as sintaxes de BACKUP DATABASE, noções básicas de Powershell e o básico de Azure.

Espero que gostem dos assuntos que serão abordados durante esta série e que, caso tenham qualquer dúvida ou sugestão, coloquem no comentário.

Até breve!

Comunidade técnica Brasília – Onde estão os profissionais de T.I?

No último sábado, dia 24/03/2018, houve mais um evento na área de tecnologia de grande porte, organizado pelo Guzz (também autor deste blog), Jucinei e Raul em parceria com a Faculdade Projeção que sempre faz um excelente trabalho neste tipo de evento.

Uma coisa que observei e que já venho observando há um tempo é a falta de profissionais atuantes na área de T.I. nestes eventos. Esses eventos que ocorrem em faculdade sempre lotam e deixam todos os organizadores, palestrantes e envolvidos na comunidade de SQL Server contentes e certamente que isso que dá mais ânimo para que os próximos eventos ocorram.

Acontece que observo que há muitos alunos, mas pouquíssimos profissionais. Conheço tantos, mas encontro quase nenhum. Fico imaginando… Muitos em suas empresas reclamam de falta de treinamento, de falta de investimento da empresa nos funcionários, mas outro ponto que temos que refletir é se você também é capaz de investir em você mesmo! Não estou falando de investimento que envolve dinheiro, pois às vezes a pessoa não tem condições de ir em eventos caros. Mas TODOS OS EVENTOS QUE FUI NOS ÚLTIMOS ANOS EM BRASÍLIA FORAM GRATUITOS. O único investimento necessário era o tempo. Esses maiores eventos são realizados em um sábado e duram o dia todo. Certo! Nem todos podem reservar um sábado para ir em eventos por N motivos. Mas já tivemos eventos durante a semana em dias diferentes que duram 2 horas no máximo e que vão menos pessoas ainda.

Um fato ocorrido ano passado e que fez com que me chamasse muita atenção para esta falta de interesse foi o encontro 37 e 38 do SQL Server DF ano passado (2017)

Quem palestrou neste evento foi o Luti. Para quem não conhece, esta pessoa é um dos maiores especialista de SQL Server do BRASIL e temos a honra de tê-lo em Brasília e de ter fácil acesso aos seus conhecimentos, mas neste evento foram pouquíssimas pessoas. Então, a qualidade do conteúdo entregue não é uma desculpa.

Entendo que nos demais eventos podemos dar a desculpa de que é muito básico e que talvez por isso o não comparecimento. Mas mesmo em palestras de alto nível, o quórum é pequeno. Chego à uma reflexão que realmente há uma falta de interesse.

Listo aqui alguns motivos pelo qual faz com que essa galera não aproveite as palestras:

Acham que sabem de tudo: Mesmo você sabendo muito sobre um assunto, você nunca sabe 100%. Acontece que quando achamos que sabemos mais que os outros, vamos para as palestras sempre com um olhar de julgamento e desta forma, nenhuma palestra será boa o suficiente. Dica: Sempre que for à uma palestra, despida-se de todo conhecimento prévio, desta forma você aproveitará mais desses eventos absorvendo ainda mais conteúdos (mesmo dos assuntos que “domina”) e capturando detalhes e formas de implementação que não pensamos;

Eventos de fora são mais interessantes: Concordo que muitas cidades, como São Paulo, têm eventos bem interessantes, mas temos o prazer de também ter palestrantes de fora em eventos grandes como SQL Server Saturday;

Não me identifico com eventos/Palestras: Claro que temos um grande número de pessoas que não gostam de ir nestes eventos, que não se sentem bem e que por isso não aproveitam. Então, para este tipo de público, o melhor a ser fazer realmente é buscar conhecimento de outra forma, mas o importante é nunca parar de estudar!

No mais, isso serve de alerta. Vejo jovens e alunos cada vez mais engajados e interessados no mundo da T.I. participando ativamente e com sede de aprender. Lembremos que este mundo da tecnologia é altamente mutável, que a cada dia está lançando novidades, então se não tivermos em constante busca pelo conhecimento, rapidão esses jovens nos alcançarão. Não vejo isso como uma parte negativa, pois é mais uma forma de trocarmos conhecimento, mas para muitos isso pode ter uma consequência maior.

Este post tem como objetivo não de ofender e nem criticar nossos colegas de profissão,mas que sirva de incentivo e de reflexão. Invista em você, invista em conhecimento que certamente o mercado de trabalho sempre terá um lugarzinho para você.

Deixo aqui links de comunidades e de pessoas que vocês possam seguir para ficar por dentro dos eventos em nossa capital:

Grupo SQL Server DF (Facebook);

Facebook Jucinei;

Link SQL server DF (Google Groups);

Meetup Brasília Data Group.

E quem souber de outros links para ajudar na divulgação de eventos, fiquem a vontade de postar nos comentários.

🙂

 

Como foi o encontro 37 do SQLServerDF

Nesta última quarta-feira, dia 26/07/2017, tivemos o encontro de número 37 do nosso chapter SQLServerDF! Desta vez, realizamos a sessão no Makerspace da Casa Thomas Jefferson[1] da Asa Norte que foi viabilizado pelo Sidney Cirqueira, um membro presente dessa comunidade fantástica. Contamos também com o pessoal da NosCoworking[2] que deram uma palhinha do trabalho bacana que fazem junto à CTJ.

A sessão deste dia foi ministrada por um dos fundadores do capítulo de Brasília, o Luciano “Luti” Moreira (t|b). Mais uma vez o Luti trouxe uma sessão de altíssimo nível intitulada “SQL Server – Casos de Suporte, Parte 1”, discutindo sobre casos enfrentados por ele como Sr. Support Engineer na Microsoft!

Deixo para você alguns feedbacks do pessoal do nosso meetup[3] e fotos do evento:

Feedback (1)

Migrando de Ambiente (literalmente)

Desta vez o post não é nada técnico. Vou contar um pouco o que aconteceu na minha carreira no primeiro semestre de 2017.

Em novembro de 2016, recebi um telefonema de um conhecido com uma oportunidade para trabalhar em outra empresa. De imediato não me interessei muito, pois estava em um emprego que gostava muito e tinha muito orgulho do ambiente que eu trabalhava. Mas esse interesse mudou quando escutei a proposta do projeto que era a migração de TODO ambiente para o Azure. Que sonho!

Na primeira conversa, foi informado que um dos motivos da minha contratação era para ajudar na migração. Já fui logo avisando que eu não tinha experiência NENHUMA com nuvem e que era um mundo totalmente novo. Sempre fui DBA de Infra, já havia participado de migrações de servidores de SQL Server, mas nunca para o Azure. Então ao entrar nessa nova empresa eu teria o seguinte desafio: Migrar as bases de SQL Server para o Azure (Iaas) e migrar a versão do SQL Server de 2012 para 2016.

  • Motivação

Muitas pessoas trocam de empregos por basicamente um motivo: Salário. Mas neste meu caso, salário não era o “incentivo”, pois fui para ganhar menos ainda, então antes de tomar a decisão, tive que colocar na balança se os benefícios iriam ao menos equalizar as finanças, pois eu estava de mudança (saindo da casa dos pais para morar sozinha) e todo planejamento eu havia feito com o salário anterior. Sim, neste momento das contas, eu queria muito ir para esta empresa com o intuito aprender novas coisas (AZURE) e participar desse projeto.

  • Zona de conforto

Eu estava há mais de três anos em meu antigo emprego, já conhecia bastante o ambiente que era super estável e crítico, já tinha domínio das atividades então é claro que havia um risco. É difícil sair de um emprego no qual você gosta, tem amigos e um ótimo ambiente de trabalho e profissionais excelentes para outro emprego cuja motivação foi o projeto. E se esse projeto não saísse do papel?

  • Desafio

Acredito que todo profissional de T.I. deve procurar novos conhecimentos e nesse momento estava batendo na minha porta uma excelente oportunidade, então eu tive que agarrar essa oportunidade. Confiei nas propostas oferecidas e fui empolgada para estes novos desafios.

Em dezembro de 2016 aceitei a oferta e combinei meu início para 18/01/2017. Foi uma boa data, pois já estava com minhas férias marcadas para início de jan/2017 e o bom é que comecei no novo emprego com as baterias todas carregadas!

  • Ambiente diferente

Nos primeiros contados com o novo ambiente, percebi uma realidade totalmente diferente. Antigamente eu trabalhava em um ambiente totalmente transacional e neste novo ambiente a maior característica é processamento de dados e análises de dados. No ambiente antigo era tudo muito segregado e eu não escrevia uma linha de código de negócios (nem tinha contato), já no ambiente novo a equipe de banco está diretamente envolvida com programação em T-SQL na parte negocial. Fora a diferença de infra que antigamente trabalhava em um local com um datacenter com equipamentos TOP de linha e neste ambiente novo eu iria administrar bases de dados em um datacenter de terceiro, onde toda alteração deveria atender à regras do parceiro. Enfim, mundos totalmente diferentes que eu deveria me adaptar para trabalhar.

Fui me acostumando com este novo ambiente, estranhando algumas coisas, apanhando com outras, mas o que eu mais estranhava era a falta de “liberdade” com os nossos servidores. Logo eu que era acostumada a estar na equipe de infra, troquei de empresa e, além de não ficar na equipe de infra desta empresa, a infra não era de domínio nosso.

Então vamos direto ao que interessa. Neste ambiente tinha muita coisa para mudar, muita coisa para colocar nos padrões, nas melhoras práticas, mas para fazer isso no ambiente em que estávamos era muito custoso, demorado e difícil. A impressão que eu tinha é que era muito engessado. Não tinha flexibilidade de criar um disco para fazer alguma manobra ou até mesmo de criar uma máquina temporária para realizar mais manobras e adequações.

Entrei em 18/01/2017 e o projeto começou a ser desenhado desde então, mas começou de fato a ser planejado em março de 2017. Como eu havia dito, eu não tinha domínio e nem estudo suficiente para “comandar” uma migração de todo o ambiente para o Azure. Para minha sorte, esta empresa realmente é especial. Fui informada que havíamos um consultor para nos ajudar neste trabalho e para maior sorte ainda este consultor era um conhecido. Uma pessoa que domina do assunto e que eu já havia uma confiança muito grande, ainda mais pelas suas contribuições na comunidade de SQL Server. Acho que alguns de vocês já devem ter ouvido falar do Luan Moreno (hahahahahaha MAS É CLARO QUE SIM! ). Cara! Consultoria maravilhosa. Desde o início foi uma ótima parceria, tanto na empolgação pelo projeto, quanto na organização e conhecimento. Já nos primeiros dias foi me despejando um monte de materiais e ferramentas novas para que eu estudasse e que essa migração desse certo. Enfim, acho importante pontuar isso aqui, pois se não fosse uma empresa tão especial quanto esta é, eles poderiam muito bem não contratar uma consultoria e fazer com que eu me virasse nessa migração.

Foram três meses intensos, de muito estudo e planejamento para logo que tivéssemos alguma oportunidade essa migração acontecesse. E essa oportunidade foi exatamente no feriado do dia 15/06/2017. Tínhamos 5 instâncias a serem migradas com um total de 200 bases mais ou menos. A nossa proposta foi migrar do jeito que estava, mas claro que aproveitei para padronizar algumas coisas já que criamos os servidores na nuvem do zero.

A migração de fato iria começar dia 15/06, mas aproveitamos e pegamos uma instância menor e menos crítica e a migramos no dia 09/06, já para saber onde estávamos pisando e começar a explorar o mundo novo. Nossa maior preocupação era o link e a taxa de transferência dos dados para a nuvem e por isso começamos a transferi-los no dia 12/06 com backups full das bases maiores e depois enviar os diferenciais. Não pensem que essa estratégia de migração foi decidida de um dia para o outro. Foram muitas discussões com a equipe de infra e com os consultores para ver qual era a melhor forma de migração para o nosso ambiente.

A migração de fato começou dia 14/06 após às 19h. Então foram três dias intensos para fazer tudo acontecer e dar certo. No primeiro dia trabalhamos da tarde do dia 14 até após as 03h da manhã do dia 15/06. Voltamos para casa, descansamos e antes das 13h do dia 15/06 já estávamos de volta continuando a migração saindo somente as 04h da manhã do dia 16/06 com tudo migrado, faltando vários ajustes a ser realizados para o dia seguinte (entende-se em algumas horas seguintes), mas já tínhamos todas as instâncias, bases e dados migrados. Agora era fazer tudo funcionar no novo ambiente. Tivemos o cuidado de deixar os servidores com os mesmos nomes, mas a maioria das aplicações apontavam pelo IP fazendo necessário realizar a configuração de quase todos os apontamentos.

Quando se tem uma equipe foda, o resultado só pode ser mais foda ainda. No dia 18/06 nosso ambiente todo já estava na nuvem. Este trabalho foi um trabalho de parceria com todos da equipe de tecnologia. Desde os consultores, equipe de infra que foi o tempo todo atenciosa e solícita, equipe de dev nos ajudando a testar e reapontar as aplicações e claro, toda a equipe de banco que desde o início passou todas as informações necessárias, deu todo suporte que precisei já que era nova no ambiente e fazendo com que todas as rotinas funcionassem corretamente.

Tem um pouco mais de um mês que estamos na nuvem, hoje já está tudo mais estável, temos maior liberdade com o nosso ambiente. Agora podemos dizer que o ambiente é nosso (my precious). Tudo que eu preciso hoje, basta pedir para nossa equipe de infra que ela tem liberdade de fazer.

Gollum

Uma coisa que levo nessa mudança toda é: Vale a pena arriscar, vale a pena sair da zona de conforto, vale a pena estudar. O que eu sei hoje é muito maior do que eu sabia em Jan/2017. A curva de aprendizagem foi enorme para um curto período de tempo.

Temos muito ainda que melhorar, que ajustar, temos muitos projetos a implementar e sei que se depender de mim, ficarei muito tempo nesta empresa, pois agora vejo que não foi apenas um projeto de migração para o azure e fim. Foi um projeto de migração para o azure para que possamos realizar muitos outros projetos com o poder que a nuvem nos oferece!

 

Call for Speaker – Ainda dá tempo!

Boa noite, pessoal!

Passando rapidamente para lembrar que o Call for Speakers para o SQL Saturday Brasília 2017 será encerrado amanhã, dia 08/07!

SqlSat618

SQL Saturday Brasília 2017

Estamos muito animados com todas as palestras submetidas até o momento! Então, caso queria palestrar neste grande evento anual de SQL e ainda não mandou sua sessão, não perca tempo!

Entre agora no link abaixo e envie sua palestra:

http://www.sqlsaturday.com/618/Speakers/Submission.aspx

Nos vemos lá!