SQL Server: Configurando o Database Mail para Gmail

Muitas coisas mudaram a partir do SQL Server 2005 e uma dessas mudanças é a substituição do SQL Mail pelo Database Mail. Isso é bom, porque o SQL Mail confiava em ter um cliente de e-mail MAPI instalado, como o Outlook, para funcionar. Com o SQL Server 2005 e versões posteriores, isso mudou e agora os serviços de e-mail usam um servidor SMTP para enviar e-mails, o que torna muito mais fácil configurar e manter. Então, como você configura o Database Mail para o SQL Server?

Há duas maneiras de configurar o Database Mail usando estored procedures no SQL Server ou usando o SQL Server Management Studio. Para este exemplo, vamos demonstrar como configurar o Database Mail usando o Management Studio.

Para configurar o Database Mail, conecte-se ao seu servidor e expanda o Management e, em seguida, clique com o botão direito do mouse em "Database Mail".

Em seguida, selecione "Configure Database Mail" e você receberá a tela de boas-vindas a seguir e clique em "Next".

A tela a seguir aparecerá então selecione "Set up Database Mail by performing..." e clique em "Next".

Se o Database Mail não tiver sido ativado, você receberá esta tela a seguir. Basta clicar em "Yes" para ativá-lo. Se já tiver sido ativado, esta tela não aparecerá.

Digite um nome para o perfil e também uma descrição e clique em "Next ..."

A tela a seguir será exibida. Preencha os detalhes da sua conta de e-mail que será usada para enviar e-mails do SQL Server. Quando terminar, clique em "OK". 

MUITA ATENÇÃO: Observação em geral as aplicações SMTP usam a porta: 465 

Mas somente neste caso do Database Mail a "Port Number" que deve ser informada é a 587 

Documentada no Google - Gmail como  (TLS) - Transport Layer Security. 

Então acredito eu que, ao selecionarmos "This Server requires  .. SSL" a porta 465

é configurada por default automaticamente então aplicamos somente a TLS

Nota-se que é uma opinião pessoal, não oficial e não documentada.

Depois de clicar em "OK", você será levado de volta a essa tela e os detalhes do SMTP serão exibidos para a conta que você acabou de configurar. Clique em "Next .." para continuar.

Na próxima tela, você verá o nome do perfil que acabou de configurar. 

Clique na caixa de seleção para permitir que este seja um perfil Público 

e também selecione "Yes" para o perfil padrão e clique em "Next".

A tela a seguir possui alguns parâmetros adicionais que podem ser configurados para controlar como o email é enviado. Você pode fazer alterações ou deixar os padrões. Um parametro muito customizado nesta tela refere-se ao delay pra uma nova tentativa de envio caso houver uma ocilçao de internet "Account Retry Delay (seconds)" Quando terminar, clique em "Next".

Uma tela de resumo aparecerá mostrando todas as opções selecionadas. Se tudo estiver correto, clique em "Finish" ou clique em "Back" para voltar e fazer alterações.

Quando você clicar em "Finish", a próxima tela aparecerá mostrando o status da instalação do Database Mail. Quando isso terminar basta clicar em "Close" para fechar esta tela.

Para testar o Database Mail, clique com o botão direito do mouse em Database Mail

 e selecione "Send Test E-Mail".

Preencha um endereço de e-mail "To:" 

e altere o corpo do e-mail, se desejar, e clique em "Send Test E-Mail"

Depois de ter enviado o e-mail, você receberá esta caixa de mensagem para confirmar se o e-mail foi recebido ou não. Se foi você pode clicar em "OK" para fechar a tela ou clicar em "Solucionar problemas", que lançará as informações de ajuda para ver qual pode ser o problema e como ele pode ser resolvido.

The End, rs isso é tudo que existe para ser configurado. Como sabemos, estes eventos agora também podem ser configurados dentro das procedures, jobs e rotinas para monitoração SQL Server. Para aprofunda essa abordagem, consulte este artigo Microsoft completo em Database Mail no SQL Server .

Outras duvidas e sugestões estamos a disposição;

Obrigado pelo apoio ao grupo WhastApp SQLManiacs quando tivemos diversos problemas

com as configurações especificadas do SMTP Gmail. abraços a todos até a próxima ...

Qual instrução é melhor para o desempenho - SELECT ou SET? SQL Server

Pergunta:  Qual instrução é melhor para o desempenho - SELECT ou SET?

Lembre-se de que o  SELECT  foi projetado para retornar dados, enquanto o  SET  foi projetado para atribuir valores a variáveis ​​locais.

Então ao comparar seu desempenho na instrução SELECT de loop, obtém-se melhor desempenho do que SET. Em outras palavras, SET é mais lento que SELECT. O motivo é que cada instrução SET é executada individualmente e atualiza os valores por execução, enquanto a instrução SELECT inteira é executada uma vez e atualiza todos os três valores em uma execução.

SET é o padrão ANSI para atribuição de variáveis, SELECT não é. SET só pode atribuir uma variável de cada vez, SELECT pode fazer várias atribuições de uma vez - o que dá a SELECT uma pequena vantagem de velocidade em relação a SET. Se atribuir a partir de uma consulta, SET só pode atribuir um valor escalar. Se a consulta retornar vários valores / linhas, SET gerará um erro. SELECT atribuirá um dos valores à variável e ocultará o fato de que vários valores foram retornados. Ao atribuir a partir de uma consulta, se não houver nenhum valor retornado, SET atribuirá NULL, onde SELECT não fará a atribuição mantendo a variável inalterada.

Referências Pinal Dave blog.sqlauthority.com
Estas e outras dicas aqui no blog acompanhe.

Grande abraços

Diferenças entre as funções SQL @@ IDENTITY, SCOPE_IDENTITY, IDENT_CURRENT

Na maior parte do nosso cotidiano de aplicação, precisamos obter as últimas informações de linha inseridas por meio da consulta SQL. E para isso, temos várias opções como:

• @@IDENTITY
• SCOPE_IDENTITY
• IDENT_CURRENT

Todas as três funções retornam valores de IDENTITY gerados pela última vez. No entanto, o escopo e a sessão em que o último é definido em cada uma dessas funções são diferentes.

@@IDENTITY

Ele retorna o último valor de identidade gerado para qualquer tabela na sessão atual, em todos os escopos. Deixe-me explicar ...  imaginamos que nós criamos um insert trigger na tabela que insere uma linha em outra tabela com gerar uma coluna de identidade e, em seguida, @@IDENTITY retorna esse registro de identidade que é criado por trigger.

SCOPE_IDENTITY

Ele retorna o último valor de identidade gerado para qualquer tabela na sessão atual e no escopo atual.

Deixe-me explicar isso ... imaginamos que criamos um trigger de inserção na tabela que insere uma linha em outra tabela com gerar uma coluna de identidade, então o SCOPE_IDENTITY resultado não é afetado, mas se um trigger ou uma função definida pelo usuário for afetada na mesma tabela que produziu o valor retorna esse registro de identidade e, em seguida, SCOPE_IDENTITY retorna esse registro de identidade que é criado por acionador ou uma função definida pelo usuário.

IDENT_CURRENT

Retorna o último valor de identidade gerado para uma tabela específica em qualquer sessão e qualquer escopo. Em outras palavras, podemos dizer que ele não é afetado pelo escopo e pela sessão, ele só depende de uma tabela específica e retorna esse valor de identidade relacionado à tabela que é gerado em qualquer sessão ou escopo.

Este artigo, juntamente com qualquer código-fonte e arquivos associados, está licenciado sob a Licença Aberta do Projeto de Código (CPOL).

Como reduzir o TempDB sem reiniciar o SQL Server ...

Durante atendimento de alguns clientes, fui encarregado desta tarefa. Quando solicitado rotinas de shrink database, questionamos por qual a razão eles gostariam que sempre esteja um dba acompanhando. O Shrink TempDB é uma tarefa omnipresente e elas não precisam de ajuda ou de nenhum acompanhamento. No entanto, sempre foram bastante inflexíveis que gostariam de uma presença em plantão durante a chamada.

Logo no primeiro momento percebemos qual era o problema. Eles não conseguiram encolher seu TempDB mesmo que eles estivessem executando o comando SHRINKFILE por diversas vezes.

Antes de todos pular e começar a falar, que não devemos reduzir o banco de dados, pois isso é ruim para o sistema e desempenho, Eu Concordo.

Agora, deixe-nos ver como podemos encolher o banco de dados TempDB.

1 2 3 4 5 6

CHECKPOINT GO DBCC FREEPROCCACHE GO DBCC SHRINKFILE (TEMPDB, 1024) GO

     

Quando os usuários estavam executando apenas o Shrink File, eles não conseguiram reduzir o banco de dados.No entanto, quando recorremos ao DROPCLEANBUFFERS funcionou bem. No entanto, note que DROPCLEANBUFFERS irá remover todo o cache de PROCEDURES, o que pode diminuir a velocidade de alguns sistemas imediatamente, pois eles precisam reconstruir novamente os caches.

Atenção, reduza o seu TempDB SOMENTE se estiver fora do ar ou em situações criticas!

Se você chegar ao ponto em que você necessite reiniciar os serviços para reduzir o database, você pode considerar uma ultima opção e então executar o DBCC FREEPROCCACHE (que irá funcionar como quando você reinicia os serviços, não apenas remove o cache, mas também todas as paginações de dados em cache).


Referências:  Pinal Dave

https://docs.microsoft.com/pt-br/sql/relational-databases/databases/shrink-a-database

https://docs.microsoft.com/pt-br/sql/t-sql/database-console-commands/dbcc-dropcleanbuffers-transact-sql

https://docs.microsoft.com/pt-br/sql/t-sql/database-console-commands/dbcc-freeproccache-transact-sql

Como configurar e usar a ferramenta AMR no SQL Server 2014

A ferramenta Análise, Migração e Relatório (AMR) faz parte do SQL Server Management Studio 2014 e visa ajudá-lo a avaliar suas cargas de trabalho e quão eficaz e demorado seria a transformação para a memória.

Sob as capas, a ferramenta não é mais que um par de relatórios no SSMS, integrado como parte do recurso Gerenciamento de Data Warehouse. Então, antes de começar a usá-lo, você deve habilitar o MDW e iniciar os trabalhos de coleta.

No SQL Server 2014, eles são completamente reescritos e, agora, em vez de ter as coleções bem conhecidas da atividade do servidor, da atividade de disco e da atividade de consulta, temos análise de procedimentos armazenados e colecionadores de análise de uso de tabela:

Uma vez que isso seja implementado, os relatórios ARM são acessíveis através dos relatórios MDW no SSMS:

Nota: O MDW é o meu banco de dados do Gerenciamento de Data Warehouse.

Agora, deixe-me contar um pouco mais sobre a "ferramenta" - há três relatórios, que são úteis e que visam ajudá-lo a identificar todas as tabelas e procedimentos que você pode planejar transformar em OLTP em memória.

O relatório Visão geral da análise de desempenho de transações :

Este relatório é simplesmente o ponto de partida onde você pode começar a explorar :)

Este relatório é um dos meus favoritos - mostra graficamente as melhores opções de tabelas para transformar em OLTP na memória. No eixo esquerdo, você tem o "Ganho", ou seja, o quanto você ganhará se você se transformar. No eixo inferior você tem o trabalho que precisa ser feito para se transformar. Então - os melhores candidatos para o OLTP na memória são os melhores direitos!

A análise da tabela contenção relatório:

Este é basicamente o mesmo que o anterior, mas mostra as tabelas mais afetadas ou parte da contenção. Mais uma vez você tem trabalho de migração e ganho no eixo.

Bem, essa é a ferramenta AMR - nada mais do que alguns relatórios e um MDW ativado.

Agora estou realmente interessado na lógica por trás dos relatórios e vou começar a investigar - especialmente como a MS decidiu o quanto será necessário para migrar uma tabela / SP e qual seria o ganho. Suponho que também haja alguns números mágicos :) Mas isso é para outra postagem rs ;-)

[CASE] Estudo de caso - Bwin SQL Server 2014 In-Memory OLTP

Como a bwin está usando SQL Server 2016 In-Memory OLTP para alcançar desempenho e escala sem precedentes.

A bwin (parte do GVC Holdings PLC) é uma das principais marcas de apostas online da Europa e é sinônimo de esportes. Com escritórios situados em vários locais em toda a Europa, Índia e EUA, a bwin é líder em vários mercados, incluindo Alemanha, Bélgica, França, Itália e Espanha.

Para poder alcançar seus objetivos nesses mercados cada vez mais competitivos, a infraestrutura da bwin é constantemente empurrada para atender às demandas de tecnologia de hoje e, às vezes, até mesmo do futuro. Com cerca de 19 milhões de apostas e mais de 250 000 usuários ativos por dia, nossos requisitos de desempenho e escala são extraordinários. Neste blog, vamos discutir como adotamos o OLTP em memória com o SQL Server 2014 para atender a essas demandas.

Nossos sistemas de armazenamento em cache:

Durante anos, dependemos do Microsoft AppFabric e de outros sistemas de cache distribuídos, como a Cassandra ou a Memcached , como uma das peças centrais da nossa arquitetura, para atender aos exigentes requisitos em nossos sistemas. Todos os principais componentes, incluindo apostas esportivas, poker e jogos de cassino, dependem desse cache, o que o torna um componente crítico para nossas necessidades comerciais atuais e futuras. De fato, uma falha neste sistema de cache seria traduzido diretamente para um total apagamento do nosso negócio, tornando-o um dos sistemas mais críticos da missão na arquitetura geral.

Com esta configuração, enfrentamos problemas de escalabilidade, e pior ainda, vimos isso com maiores volumes de transações, a estabilidade de todo o sistema de cache distribuído não conseguiu acompanhar a carga de trabalho. Mesmo na redução da quantidade de nós de cache, ainda enfrentamos problemas de estabilidade, levando a uma degradação de alta disponibilidade.

Por estas razões, para tornar-se mais estável e acompanhar os requisitos de negócios, fomos obrigados a considerar melhores alternativas e soluções globais para a nossa camada de cache.

Esse foi o momento em que percebemos que já tínhamos a solução - codinome project "Hekaton", o mecanismo OLTP In-Memory, construído no SQL Server. Na verdade, esta foi a tecnologia que já estávamos usando para uma solução similar por um tempo, nosso ASP.NET SessionState.

Bwin foi o primeiro cliente a usar o mecanismo OLTP In-Memory para um banco de dados ASP.Net SessionState em produção, com o SQL Server 2014 (muito antes de ser chamado de SQL Server 2014). Para referência, antes do SQL Server 2014, nosso banco de dados SessionState do ASP.NET foi capaz de lidar com cerca de 12.000 solicitações por lotes / seg antes de sofrer a contenção locks. Nós fomos obrigados a implementar 18 bancos de dados SessionState e particionar nossa carga de trabalho para lidar com a carga de usuário necessária. Com o SQL Server 2014 In-Memory OLTP, poderíamos consolidar de volta a uma 7nicúninstância de banco de dados do SQL Server para lidar com ~ 300,000 pedidos em lote / seg, com o gargalo movendo para a divisão de dados, pois não havia suporte de tipos de dados LOB com memória - tabelas otimizadas.

Abaixo está o resumo das melhorias de desempenho que conseguimos usando o OLTP In-Memory para o nosso SessionState do ASP.NET. Também incluímos as solicitações / segundo do lote do monitor de desempenho e as medidas de espera no SQL Server

** NOTA: No Teste, atingimos problemas de spinlock em cerca de 800.000 solicitações por lotes / seg, isso já foi resolvido no SQL Server 2016 CU2 (Blog : https://blogs.msdn.microsoft.com/sqlcat/2016/09/29 / sqlsweet16-episode-8-how-sql-server-2016-cumulative-update-2-cu2-can-improvement-performance-of-altamente-concurrent-workloads / )

Com este nível de desempenho e estabilidade alcançados, juntamente com toda a experiência que reunimos durante anos trabalhando com a solução ASPS.NET SessionState, sentimos confiar em podermos utilizar isso como nosso bloco de construção para um novo sistema de cache global baseado no In- Mecanismo OLTP de memória.

Nosso novo sistema de cache global

O sistema de cache global, baseado em nossa implementação do estado da sessão ASP.NET e OLTP em memória, agora é a substituição de todos os nossos sistemas de armazenamento em cache distribuídos. Tendo mudado a arquitetura, agora não podemos acompanhar o desempenho que tivemos com o nosso sistema de cache distribuído, mas superá-lo, usando apenas um único nó de banco de dados, em comparação com os 19 nós de cache de camada intermediária anteriormente utilizados.

Além de reduzir o número de servidores necessários para obter o desempenho que precisamos, também conseguimos vários ganhos de desempenho, conforme mostrado no diagrama abaixo. O gráfico, que vem da nossa solução de monitoramento de aplicativos, mostra três coisas:

Uso : primeiro, os anéis circulares verdes representam todos os produtos diferentes (e as contagens de servidores correspondentes que são representadas pelos números nos círculos) dependentes do cache global. Isso inclui inúmeros produtos de apostas esportivas, jogos de cassino, bingo, todo o caminho para o nosso portal e API de vendas, apenas para citar alguns. Com todos esses componentes acessando o cache, tornou-se ainda mais central em nossa arquitetura do que o ASPS.NET SessionState.

Performance Throughput : Em seguida, você pode ver nossa carga média, cerca de 1,6 milhão de pedidos por minuto. Com a expansão do nosso carregamento do usuário, esperamos ter o dobro do número de solicitações por lotes / seg e esperamos poder controlar até 20 vezes essa carga.

Latência do Desempenho: Finalmente, você pode ver a latência consistente medida pelo cliente em torno do tempo de ida e volta em 1 ms. Este número é ainda mais importante se compararmos diretamente com o sistema de cache distribuído anterior, onde a latência variou o tempo todo, tendo tempos de resposta de 2ms até 200ms.

Fonte:  Biljana Lazic (bwin - Senior DBA) e Rick Kutschera (bwin - Gerente de Engenharia). Avaliado por: Mike Weiner (SQLCAT)

Nos próximos tópico falaremos um pouco mais sobre a implementação do In-Memory OLTP

Ferramentas de analise tools AMR para otimização do In-Memory e outros informações ...

acompanhe conosco, um abraço.

Update 20/02 conheça a ferramenta AMR:

https://scriptsemsql.blogspot.com.br/2018/02/como-configurar-e-usar-ferramenta-amr.html

Exames da Microsoft que serão retirados em 2018

Exames da Microsoft agendados para se aposentar no início de 2018

Há tantas conversas sobre o que é a certificação, o exame a ser aprovado, quais são os requisitos e como obter a certificação. No entanto, o lado oposto da moeda são as mais velhas certificações e exames que desaparecem ao longo do tempo. Quando as tecnologias se tornam obsoletas, a Microsoft se retira de exames de certificação que não são mais relevantes, para abrir espaço para que as certificações mais recentes das tecnologias atuais.

O que significa "retirar" um exame ?

Basicamente, quando um exame de certificação da Microsoft é retirado, o exame não estará mais disponível. Isso significa que, uma vez que o exame é aposentado, a certificação obtida ao passar pelo exame pode ser desativada. Se a sua certificação for desativada, talvez seja necessário aprovar em um novo exame de certificação da Microsoft para obter novamente a versão atual dessa certificação.

Aqui está a lista dos exames de certificação da Microsoft que estão programados para serem aposentados no primeiro semestre de 2018:

Retiring on March 31, 2018

70-696 Administering System Center Configuration Manager and Intune.

Retiring on July 31, 2018

70-398 Planning for and Managing Devices in the Enterprise.
70-488 Developing SharePoint Server 2013 Core Solutions.
70-489 Developing SharePoint Server 2013 Advanced Solutions.
70-496 Administering Visual Studio Team Foundation Server.
70-497 Software Testing with Visual Studio.
70-498 Delivering Continuous Value with Visual Studio.
70-680 Windows 7, Configuring.
70-685 Windows 7, Enterprise Desktop Support Technician.
70-686 Windows 7, Enterprise Desktop Administrator.
74-343 Managing Projects with Microsoft Project 2013.
74-409 Server Virtualization with Windows Server Hyper-V and System Center.


Exames da Microsoft aposentados no final de 2017

Além disso, uma vez que esta é minha primeira postagem falando sobre os exames de certificação vencedores da Microsoft, aqui está uma lista dos exames que se aposentaram no final de 2017:

Retired on December 31, 2017

70-246 Monitoring and Operating a Private Cloud with System Center 2012
70-247 Configuring and Deploying a Private Cloud.
70-534 Architecting Microsoft Azure Solutions.
74-344 Managing Programs and Projects with Project Server 2013.
74-678 Designing and Providing Microsoft Volume Licensing Solutions to Large Organizations.

MB2-709 Microsoft Dynamics Marketing.
MB6-890 Microsoft Dynamics AX Development Introduction.
MB6-892 Microsoft Dynamics AX Distribution and Trade.
MB6-893 Microsoft Dynamics AX Financials.


Espero que isso ajude a esclarecer algumas das confusões que algumas pessoas têm em relação à retirada do exame de certificação da Microsoft e à desativação da certificação. Se você tiver outras questões, coloque-as nos comentários.

Grande abraços