Rotina de transferir Blob do tipo Page de uma Storage Account GPV1 para a Storage Account Blob com access tier Cool

Hoje vamos falar sobre uma rotina que iremos criar em nosso ambiente para poder economizar com armazenamento de nossos backups.

Relembrando, o nosso cenário é o seguinte:

• Backup sendo realizados diretamente para um Storage General Porpose V1(GPV1);
• O Blob está indo com o tipo “page”;
• Temos que reter esses backups durante 3 meses;
• Passar o Blob do tipo Page do  GPV1 para Storage Account “Blob” e acces tier Cool.

Como que realizaremos esses procedimentos, sendo que a Storage Account do tipo Blob não aceita o blobs do tipo“Page”?

Aqui eu tento passar o backup de um blob storage para outro através do “Microsoft Azure Storage Explorer”, porém é me retornado o erro:

Obs.: a stgcomunidadesqlserver1 é a storage account do tipo GPV1 e a stgcomunidadesqlserver0 é do tipo Blob.

Ao tentar passar via powershell com o comando “Start-AzureStorageBlobCopy” me retorna o mesmo erro e agora? Como que faço?

 

Simples! Basta converter o tipo do blob para block antes remove-lo, certo?

NO!

A gente especifica o tipo do blob quando o criamos e após isto, não é possível modificá-lo.

Fonte: https://docs.microsoft.com/en-us/rest/api/storageservices/Understanding-Block-Blobs–Append-Blobs–and-Page-Blobs?redirectedfrom=MSDN

Desta forma, a solução seria utilizar o AZCopy para baixar este arquivo para meu servidor e depois realizar o Download novamente.

Aqui não irei detalhar sobre o AZCopy, mas para quem nunca o utilizou pode ter todos os detalhes no link: https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azcopy

Login-AzureRmAccount #Passar as credenciais para acessar o Azure

Set-AzureRmContext -SubscriptionName "SubscriptionName"

#Preenche as variáveis para pegar os arquivos do Storage stgcomunidadesqlserver1
$SubscriptionName = "SubscriptionName"
$ResourceName = "ComunidadeSQLServer"
#Aqui eu coloco o nome do diretório para qual quero baixar meus backups
$destFile = "E:\RotinaAzCopy"
#storage account de origem
$srcStorageAccount = "stgcomunidadesqlserver1"
#Aqui estou pegando a access key da storage account para acessá-la
$srcStorageKey = (Get-AzureRmStorageAccountKey -ResourceGroupName $ResourceName -StorageAccountName $srcStorageAccount).Value[0]
$srcContext = New-AzureStorageContext -StorageAccountName $srcStorageAccount -StorageAccountKey $srcStorageKey
#Conteiner de origem
$srcContainer = "backup"
$srcBlob = (Get-AzureStorageBlob -context $srcContext -Container $srcContainer)
$srcBlob2 = $srcBlob.name

#Muda de pasta para usar o AzCopy
Set-Location "C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy"

.\AzCopy.exe  /Source:https://stgcomunidadesqlserver1.blob.core.windows.net/backup /Dest:$destFile /SourceKey:$srcStorageKey /Pattern:$srcBlob2 /Y 

Resultado:

E para passar o Blob da pasta local para o Storage Account do tipo Blob basta executar:

#Aqui começa a parte de enviar os arquivos para o storage cold
$coldStorageAccount = "stgcomunidadesqlserver0"
$coldStorageKey = (Get-AzureRmStorageAccountKey -ResourceGroupName $ResourceName -StorageAccountName $coldStorageAccount).Value[0]
$coldContext = New-AzureStorageContext -StorageAccountName $coldStorageAccount -StorageAccountKey $coldStorageKey


.\AzCopy.exe /Source:$destFile /Dest:https://stgcomunidadesqlserver0.blob.core.windows.net/rotinamove /DestKey:$coldStorageKey /Y /S

Resultado:

Podemos observar que o “Access Tier” e o “Blob Type” já estão alterados. Isso porque nesta Storage Account o Access Tier padrão é o cool (configurei assim) e quando enviamos algum arquivo via AZCopy, o padrão dele é do tipo Block . Caso você queira mudar o tipo do blob ao fazer o upload dele, basta passar o parâmetro: /BlobType:”TipoDoBlob” , mas neste caso, não necessitamos de passar este parâmetro.

Então, juntando os dois, o comando completo ficaria assim:

Login-AzureRmAccount #Passar as credenciais para acessar o Azure

Set-AzureRmContext -SubscriptionName "SubscriptonName"

#Preenche as variáveis para pegar os arquivos do Storage stgcomunidadesqlserver1
$SubscriptionName = "SubscriptonName"
$ResourceName = "ComunidadeSQLServer"
#Aqui eu coloco o nome do diretório para qual quero baixar meus backups
$destFile = "E:\RotinaAzCopy"
#storage account de origem
$srcStorageAccount = "stgcomunidadesqlserver1"
#Aqui estou pegando a access key da storage account para acessá-la
$srcStorageKey = (Get-AzureRmStorageAccountKey -ResourceGroupName $ResourceName -StorageAccountName $srcStorageAccount).Value[0]
$srcContext = New-AzureStorageContext -StorageAccountName $srcStorageAccount -StorageAccountKey $srcStorageKey
#Conteiner de origem
$srcContainer = "backup"
$srcBlob = (Get-AzureStorageBlob -context $srcContext -Container $srcContainer)
$srcBlob2 = $srcBlob.name

#Muda de pasta para usar o AzCopy
Set-Location "C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy"

.\AzCopy.exe  /Source:https://stgcomunidadesqlserver1.blob.core.windows.net/backup /Dest:$destFile /SourceKey:$srcStorageKey /Pattern:$srcBlob2 /Y 



#Aqui começa a parter de enviar os arquivos para o storage cold
$coldStorageAccount = "stgcomunidadesqlserver0"
$coldStorageKey = (Get-AzureRmStorageAccountKey -ResourceGroupName $ResourceName -StorageAccountName $coldStorageAccount).Value[0]
$coldContext = New-AzureStorageContext -StorageAccountName $coldStorageAccount -StorageAccountKey $coldStorageKey


.\AzCopy.exe /Source:$destFile /Dest:https://stgcomunidadesqlserver0.blob.core.windows.net/rotinamove /DestKey:$coldStorageKey /Y /S

Porém, desta forma, estamos baixando somente um arquivo e se eu tiver vários arquivos a serem transferidos e com uma data de corte?

Nesta mesma lógica que utilizamos o AzCopy, vamos acrescentar o loop FOR e o Where-Object:

E o script vai ficar assim:

Login-AzureRmAccount #Passar as credenciais para acessar o Azure

Set-AzureRmContext -SubscriptionName "SubscriptionName"

#Preenche as variáveis para pegar os arquivos do Storage stgcomunidadesqlserver1
$SubscriptionName = "SubscriptionName"
$ResourceName = "ComunidadeSQLServer"

#Aqui eu coloco o nome do diretório para qual quero baixar meus backups
$destFile = "E:\RotinaAzCopy"
$srcStorageAccount = "stgcomunidadesqlserver1"

#Aqui estou pegano a access key da storage account para acessá-la
$srcStorageKey = (Get-AzureRmStorageAccountKey -ResourceGroupName $ResourceName -StorageAccountName $srcStorageAccount).Value[0]
$srcContext = New-AzureStorageContext -StorageAccountName $srcStorageAccount -StorageAccountKey $srcStorageKey

#Conteiner de origem
$srcContainer = "backup"

#colocar aqui a data de corte dos backups que deseja passar para o storage Cool. 
#Neste exemplo estamos passando a data com -7 dias
$dataExclusao = (Get-Date).AddDays(-7) 

#Aqui acrescentaremos o Where-Object a data de corte que passamos na vareável anterior
#Obs.: Para exemplo, comentei a parte do Where-Object, pois quis passar todos os backups do conteiner
$srcBlob = (Get-AzureStorageBlob -context $srcContext -Container $srcContainer) | Where-Object {$_.LastModified -lt $dataExclusao}

#Aqui estamos pegando somente o nome do blob, descartando as demais informações
$srcBlob2 = $srcBlob.name



#Aqui começa a parte de enviar os arquivos para o storage cood (Destino)
$coldStorageAccount = "stgcomunidadesqlserver0"
$coldStorageKey = (Get-AzureRmStorageAccountKey -ResourceGroupName $ResourceName -StorageAccountName $coldStorageAccount).Value[0]
$coldContext = New-AzureStorageContext -StorageAccountName $coldStorageAccount -StorageAccountKey $coldStorageKey



#Muda de pasta para usar o AzCopy
Set-Location "C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy"

#Na primeira execução, esta parte retornará um erro, pois os arquivos ainda não existirão
#Estes arquivos criei para verificar se minha rotina foi com sucesso ou não
Remove-Item E:\ResultadoRotinaAzCopy\resultadoQuente.txt -recurse -Confirm:$false   
Remove-Item E:\ResultadoRotinaAzCopy\resultadoFrio.txt -recurse -Confirm:$false   


#Aqui estpu pegando somente a quantidade de arquivos e logando 
$srcBlob2.Count | Out-File E:\ResultadoRotinaAzCopy\resultadoQuente.txt -append

#Utilizaremos esta data para futuras verificações
#Importante lembrar que a timezone do servidor deverá ser a mesma do azure, pois aqui estamos usando a data como filtro
$DataInicio = (Get-Date)

#Cria um loop para baixar somente os arquivos que eu quero
for ($i=0; $i -lt $srcBlob2.Count; $i++) {
    #Nas duas próximas linhas passo o arquivo na posição do array, jogo na variável e depois logo no meu arquivo .txt
    $file = $srcBlob2[$i]
    $file | Out-File E:\ResultadoRotinaAzCopy\resultadoQuente.txt -append

    #Aqui começo o procedimento do download do meu backup e logo novamente o resultado. 
    #Observar que desta vez estamos passando o parâmetro /Pattern: , pois queremos pegar somente um arquivo.
    .\AzCopy.exe  /Source:https://stgcomunidadesqlserver1.blob.core.windows.net/backup /Dest:$destFile /SourceKey:$srcStorageKey /Pattern:$file /Y | Out-File E:\ResultadoRotinaAzCopy\resultadoQuente.txt -append
    $file  | Out-File E:\ResultadoRotinaAzCopy\resultadoFrio.txt -append
   
    #Aqui começo o meu upload para o blob de destino
    .\AzCopy.exe /Source:$destFile /Dest:https://stgcomunidadesqlserver0.blob.core.windows.net/rotinamove /DestKey:$coldStorageKey /Y | Out-File E:\ResultadoRotinaAzCopy\resultadoFrio.txt -append
    Remove-Item $destFile -recurse -Confirm:$false   
}

#Importante lembrar que a timezone do servidor deverá ser a mesma do azure, pois aqui estamos usando a data como filtro 
$ResultadoCold = (Get-AzureStorageBlob -context $coldContext -Container "rotinamove" | Where-Object  {$_.LastModified -ge $DataInicio})
$resultadoCold2 = $resultadoCold.name

$TamanhoCold = $resultadoCold2.Count
$tamanhoHot = $srcBlob2.Count

#Aqui realizaremos uma simples verificação se todos os blobs do período que quis passar foram com sucesso.
#Caso positivo, os blobs da origem serão excluídos
IF($TamanhoCold -eq $tamanhoHot) {

    Get-AzureStorageBlob -context $srcContext -Container $srcContainer | Where-Object {$_.LastModified -le $dataExclusao} | Remove-AzureStorageBlob | Out-file F:\Resultado\ErroDelete.txt

}

Blob de Origem:

Blob de destino:

Ficando com a nossa arquitetura final:

Para completar, como queremos deixar isso automático, podemos criar um job no Agent (isso mesmo, dentro do SQL Server) para que todos os dias as “X” horas essa rotina é executada. A única diferença é que no comando  Login-AzureRmAccount  já tenhamos que passar as credenciais. Talvez isso seja uma “falha” se segurança, mas levando em consideração que somente pessoas autorizadas terão acesso aos jobs, e que a conta que será configurada tiver somente o acesso restrito à movimentação de arquivos entre as storage accounts, certamente não teremos problemas com segurança!

Acrescentando o código assim:

$Usuario = "sqlazure@seudominio.onmicrosoft.com"
$secpasswd = ConvertTo-SecureString "senha" -AsPlainText -Force
$mycreds = New-Object -typename System.Management.Automation.PSCredential -ArgumentList $Usuario,$secpasswd

#Loga no Azure
Login-AzureRmAccount -Credential $mycreds

Desta forma, espero que não tenha ficado confuso os scripts (ainda tenho que melhorar e muito em minhas documentações de códigos rsrs), mas qualquer dúvida estou disponível para responder.

Até o próximo post: “Limitações/Erros (Access Key Credential)”

Anúncios

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:

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

 

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:

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

 

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

 

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.

 

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:

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:

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:

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!

 

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.

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.

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:

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

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

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

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

• 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.

Aqui você confirma as informações configuradas.

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:

• Introdução ao Blob Storage
• Backup With Access Key credential 
  • Rotina de transferir Blob do tipo Page de uma Storage Account GPV1 para a Storage Account Blob  com access tier Cool
  • Limitações/Erros (Access Key Credential)
• Backup With SAS Credential (Limitações/Erros do SAS)
• Backup Automatizado para VM
• Recovery Services Vault SQL Server
• Conclusão

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.

🙂

 

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.

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!

 

Material encontro XXXVI SQL Server DF

Dia 28/06/2017 apresentei pela primeira vez no SQL Server DF. Foi muito gratificante, pois foi lá que comecei a minha carreira como DBA.

Então segue o PPT da apresentação, assim como algumas fotos desse dia:

Link do PPT.

 

 

Até o encontro XXXVII!