THE SQL TIMES

Respondendo os porquês sobre SQL Server, Windows, programação e outros assuntos sobre tecnologia

Instância DEFAULT e conectividade não default – Parte 1

Quanto tempo você acha que uma conexão com o SQL Server deve levar para ser considerada como rápida ou lenta? Esse é aquele tipo de pergunta que não foge do famoso “depende”. Você já precisou ajustar as configurações de timeout de conexão da sua aplicação? E você já conseguiu se conectar na instância errada, mesmo passando as credenciais e nomes corretos?

É meu caro, as configurações de um client tem um papel muito maior quando o assunto é instância DEFAULT. A brincadeira fica mais interessante quando este tipo de instância não está configurado para responder ou no pipe padrão ou na porta TCP padrão…

CLIENTs e Ordem dos Protocolos

Bom, antes vamos recapitular como um client escolhe um protocolo para se conectar no SQL Server. Dependendo da biblioteca de conexão que estiver usando, podemos ter algumas variações:

  • SQL Server Native Client (SNAC)
    Usa a ordem especificada no SQL Server Configuration Manager (configuração referente à client e não a serviços). Esta biblioteca é geralmente usada por aplicações escritas em C/C++. Um exemplo de aplicação que usa o SNAC é o SQLCMD.
    Como eu sei disso? BOL: https://technet.microsoft.com/en-us/library/ms187884(v=sql.130).aspx
  • SqlClient
    Esta é usada geralmente por aplicações escritas em .NET! O Management Studio é um exemplo bem clássico. A ordem padrão é: Shared Memory,  TCP/IP e Named Pipes.
    Lembre-se que este client não é afetado pela ordem do Configuration Manager
    Como eu sei disto? http://blogs.msdn.com/b/adonet/archive/2010/04/18/sqlclient-default-protocol-order.aspx (se não for suficiente, o link acima também fala isso).
SQL Native Client e SqlClient

O Native Client, grosseiramente falando, é um conjunto de bibliotecas disponibilizadas pela Microsoft para que seja possível se conectar com o SQL Server . Ele contém implementações das interfaces OLE DB  e ODBC e substitui o velho MDAC (Microsoft Data Access Components) que também fornecia implementações OLE DB e ODBC. Você pode obter mais informações e documentação do Native Client na página do mesmo: https://msdn.microsoft.com/en-us/data/ff658532.aspx.

Assim como o Native Client, o SqlClient é a biblioteca disponibilizada pelo .NET Framework para que as aplicações escritas na linguagem possam se comunicar com o SQL Server. Mais informações em: https://msdn.microsoft.com/en-us/library/system.data.sqlclient(v=vs.110).aspx

Quando se trata-de uma instância DEFAULT, o client irá usar as opções padrão de conexão para cada protocolo. Por exemplo, no caso do TCP/IP a porta default é a 1433. No caso do Native Client, você pode alterar tanto a porta como o named pipe padrão. Quando uma instância NOMEADA é utilizada, então entra em ação o SSRP, ou SQL Server Resolution Protocol, onde o client vai mandar uma mensagem pro SQL Browser para tentar descobrir as informações de pipe e porta da instância desejada.

Isso nos leva há alguns cenários bem interessantes quando estamos lidando com instâncias DEFAULT, em portas/pipe diferentes do padrão:

  1. O que acontece se a porta 1433 estiver fechada, isto é, nenhum serviço está associado a ela?
  2. O que acontece se houver um firewall eliminando os pacotes?
  3. O que acontece se houver uma outra instância rodando na porta 1433 neste mesmo servidor?

Bom, vamos fazer uma brincadeira com cada um destes casos!

Cenário Porta 1433 fechada!

O primeiro cenário é o mais interessante e provavelmente o mais comum neste tipo de situação. Você instalou a instância DEFAULT  e configurou para ela rodar em outra porta. Em meus testes, eu vi que a conexão sempre demora cerca de 1 segundo para completar. Este tempo não é alto! Ou é? Imagine uma aplicação que necessite abrir várias conexões a todo momento e que é crucial que o tempo de resposta do banco seja abaixo de 1 segundo. Bom, neste caso, você gastou 1 segundo só pra se conectar!

Para ilustrar, eu fiz um teste onde eu tento me conectar de um client, cujo o IP é 50.50.50.10, no servidor SQL1 (50.50.50.11) que possui uma instância default rodando na porta 1436. Eu usei um script muito simples em powershell pra gente poder medir o tempo que o sqlcmd levou:

Aqui está o meu resultado:

Medindo o tempo de conexão com instância default

No exemplo acima, o sqlcmd demorou mais de 1 segundo pra executar. Se você acha que isso é normal, então olhe uma versão mais rápida:

Tempo de Conexão especificando o protocolo diretamente

 

Incríveis 148 milisegundos, conta 1073 do anterior. Quase 90% a menos.
Note que a unica diferença entre os dois scripts é que eu especifiquei o protocolo diretamente na conexão. Para entender o porquê dessa diferença, primeiro vejamos o que está acontecendo debaixo dos panos.
Eu usei o wireshark para capturar os pacotes de rede entre minha máquina e o servidor SQL no momento em que eu fiz o primeiro teste. Eis o resultado:

Resultado do Wireshark quando a conexão ficou lenta

Resultado do Wireshark quando a conexão ficou lenta (clique para ampliar)

O que esse resultado nos revela:

  1. A coluna Time nos mostra o tempo desde o início da sessão de captura no formato Segundos.Milissegundos. A linha 1 nos mostra claramente que a primeira comunicação com o servidor SQL1 é feita diretamente na porta 1433, confirmando o que eu disse no ínicio do post. A coluna Info mostra que minha requisição, que está saindo pela porta 4752, está tentando abrir uma conexão na porta 1433. Como o protocolo TCP é usado, então um SYN enviado como parte do Three Way Handshake.
  2. Na linha 2, cerca de 0.0001 segundos depois do início da captura dos pacotes, o servidor SQL1 (50.50.50.11) responde com um RESET (coluna Info vem com a flag RST), isto é, como a porta está fechada e nenhum processo está na escuta, então a tentativa de conexão é negada. De novo, isso faz parte do processo Three Way Handshake do protocolo TCP.
  3. Cerca de 0.500 segundos depois, um TCP RETRANSMISSION é feito (linha 3). Isto é, a minha máquina está tentando novamente uma conexão na porta 1433. Na linha 4 o servidor volta a responder com um RST. Justo! Note que isto não é uma nova tentativa de conexão por parte do client SQL, mas uma tentativa do protocolo TCP. O client neste ponto, ainda está aguardando a reposta da chamada de rede (Ex.: WSAConnect())
  4. Na linha 5, já 1 segundo depois do ínicio da captura, um novo TCP RETRANSMISSION é feito. Se você reparar, o tempo que passou entre a linha 04 e a linha 05 foram os mesmos 500 milissegundos entre a linha 02 e linha 03. Novamente, como mostrado na linha 06, o servidor volta a negar a conexão. De novo, essa retrasmissão ainda faz parte da primeira tentativa de acesso do client (que está tentando o protocolo TCP/IP).
  5. A partir da linha 7, podemos perceber que o Named Pipes já começar a ser usado porque o client tenta se conectar na porta do SMB (445). O Named Pipes é uma implementação do protocolo SMB, e por isso estamos vendo ele em cena. Aqui, antes que esse tentativa fosse feita, o protocolo TCP respondeu ao client (no caso o Native Client) que a tentativa de conexão na 1433 foi sem sucesso, o que ocasionou um “failover” de protocolo, e o client tentou o próximo disponível , que é o Named Pipes.

Podemos concluir que devido ao fato da porta está fechada, uma retransmissão por parte do client está sendo feita, e essas retransmissões é quem estão consumindo a maior parte do tempo para efetivar a conexão com o SQL Server. Sim, mesmo que o TCP acaba não sendo usado no final… Quando eu especifico o protocolo diretamente, estamos forçando o client a usar este protocolo ao invés de tentar seguir a ordem configurada. Então a tentativa na porta 1433 é eliminada, e com isto os retransmissions. Os dois scripts abaixo permitem contornar esse problema porque estamos justamente eliminando aquelas tentativas de conexão iniciais:

Versão TCP:

Tempo de conexão com TCP forçado

Note que não há tentativa na 1433

Aqui a versão com Named Pipes:

Script-Tempo-NPforcado

Note que aqui também não há tentativa 1433

Curiosidade: Alterando a quantidade de retransmissões

Outro ponto bem interessante para se notar é que a maior parte do tempo gasto para abrir a conexão foi devido ao TCP Retransmission. Um dos parâmetros que controla quantas vezes o protocolo TCP/IP irá tentar um retransmission é o MaxSYNRetransmissions. Você precisa instalar este hotfix para poder alterar no Windows 7 ou no Windows Server 2008 R2. O chato é que o valor mínimo é 2 e o máximo é 8. Para alterar, depois que o hotfix estiver instalado, basta executar o comando netsh:

Para nós este comando não tem muita utilidade, uma vez que o menor é 2 (e é justamente as duas tentativas que observamos nos exemplos acima). Vou ficar devendo um teste mais minuncioso, usando um debugger e outras ferramentas para ver se conseguimos alterar este valor apenas para fazer uma brincadeira e matar umas curiosidades, já que você não vai querer alterar essas configurações em produção! Certo!?

Ao relizar os testes, eu percebi que a ordem que estava no configuration Manager era: Shared Memory, TCP/IP, Named Pipes. Eu também poderia ter contornado isto de várias formas, onde destaco:

  • Ajustar a ordem dos protocolos
    Isto atenderia perfeitamente este caso. Seu eu colocar o named pipes (sim, eu fiz este teste) antes do TCP/IP, então a conexão seria feita de imediato no pipe padrão (já que este eu não alterei lá na instancia). Porém, caso a instância não aceite o outro protocolo, então não vai adiantar muito. E também, pro caso do SqlClient do .NET, você não pode alterar a ordem padrão. Então, as tentativas no SSMS ainda continuariam com o delay.
  • Alterar a porta default ou pipe padrão
    Usando o SQL Server Configuration Manager, poderíamos alterar a porta default para 1436 (ou o pipe default, se foste o caso). Porém isso faria com que as conexões em outras instâncias DEFAULT , que estivessem rodando na 1433, falhassem.
  • Configurar um Alias
    Esta seria uma saída interessante, porém você precisaria sair alterando em todas as máquinas que possuem alguma aplicação que se conecta com a instância. Dependendo, poderia ser viavel.
  • [UPDATE 21/12/2012] Adicionar a porta 1433
    Esta é uma saída mais interessante ainda. Se estiver em um cenário onde mudar a porta atual não é uma saída (pelo fato de algumas aplicações estarem usando a mesma, por exemplo), você pode configurar o SQL Server para ouvir em mais de uma porta TCP. Basta separar portas por vírgula, no SQL Server Configuration Manager. Isso irá requerer um restart da instância! Os links a seguir fornecem mais detalhes:

 

Bom, por hoje é só. Nas próximas 2 duas partes eu vou te mostrar o que acontece quando um firewall está no meio, e também como você pode acabar se conectando na instância errada, mesmo tendo fornecido todas as informações corretamente.

Até lá!

UPDATE: O Link para a parte 2 está aqui!

[]’s
Rodrigo Ribeiro Gomes

 Ops… Não acabei ainda! Já se inscreveu pro SQL Saturday 469? Se não, corre lá: https://www.sqlsaturday.com/469/RegisterNow.aspx

AFTER SQL SATURDAY 424

SQL Saturday #424

SQL Saturday #424

Sensacionalmente fantástico. É assim que começo este post para tentar descrever o que foi o evento que aconteceu em uma das maiores cidades do mundo. No último sábado, dia 26/09/2015, aconteceu o SQL Saturday 424 em São Paulo.  O evento estava lotado e contou com a presença de grandes nomes da comunidade SQL e Microsoft.

O Evento

O show não foi somente por conta dos palestrantes, que aliás tinham muitos e que muita gente conhece através dos artigos que compartilham no mundo virtual. Uma das coisas que mais me impressionou foi o nível técnico daqueles que prestigiavam o evento. Os palestrantes puderam explorar ao máximo, oferecendo um conteúdo de qualidade, compartilhando informações que você não encontra em qualquer literatura, além de arrancar boas risadas com as descontrações.

A importância do evento não se limita somente às apresentações, mas ao networking. Conheci e conversei com muita gente, que conhecia apenas por e-mail, ou por ler algum artigo, e talvez essa tenha sido, para mim, a experiência mais marcante do evento. (Na verdade, mais marcante para mim, foi a minha própria apresentação (que irei falar sobre já já), e o networking ficou em segundo lugar. 🙂 ).

Outro espetáculo foi a organização do evento, que, apesar de gratuito, ofereceu coffee breaks, kits, livros (muita gente saiu feliz com a versão impressa do Complete Showplan Operators, do Fabiano Amorim. Ganhei o meu e recomendo fortemente!) e sorteou brindes. Tudo isso deve-se ao apoio dos patrocinadores e faço questão de deixar o meu muito obrigado:

Patrocinadores SQLSaturday

Também, deixo aqui os meus parabéns ao organizador do evento, o Diego Nogare (@DiegoNogare), que fez com que este evento honrasse o nome que carrega. Parabéns Diego! Mandou bem!

Bom, se você quiser conferir as fotos do evento pode ir lá no Blog do Marcelo Fernandes (@marcelodba) que além de apresentar, cuidou de registrar todos os momentos!

 

 

A minha apresentação

SQL Server, Windows e CPU. Este foi o título da minha apresentação. Com a sala cheia, fiquei bem à vontade e consegui entregar o que queria dentro do tempo de 60 minutos. Foi muito gratificante poder ver que a turma estava bem atenta e tranquila. Ver as pessoas assistindo e compreendendo este assunto, que apesar de simples e com um nível 100, foi incrível, e valeu a pena todo o esforço que coloquei em cada slide ou script. A minha responsabilidade ficou maior, quando, um pouco depois do início, o MCM Fabrício Catae (@FCatae) veio assitir a apresentação. Foi incrível poder apresentar um assunto tão simples, para um público que tinha desde quem nunca mexeu com SQL até aqueles que são referência no Brasil e no mundo. A sensação foi de missão cumprida, e se você estiver lendo este post e particiou de minha apresentação, deixo aqui um imenso muuuuuuuuuuuuuuuuuuuuito obrigado pelo o pouqinho do seu tempo!

Como forma de agradecimento e compromisso, eu disponibilizo os slides de minha apresentação, juntamtente com todos os scripts de todas as demos. A versão em PDF contém anotações detalhadas em um pouco mais completas daquilo que falei na apresentação, além do passo a passo para reproduzir as demos. Você pode baixar usando as seguintes opções:

 

Bom, novamente, agradeço muito a organização do evento, os voluntários, os palestrantes, e todo o púbico que foi prestigiar.

Palestrantes SQL Saturday 424

Palestrantes SQL Saturday 424

 

 

E a história não acaba por aqui

Está vendo como é importante participar destes eventos? Você aprende coisas novas, conhece pessoas, fecha negócios e se diverte. Já se inscreveu para Brasília? O evento vai acontecer de novo, em novembro! É o SQL Saturday 469! Não perca esta oportunidade, clique na imagem e garanta sua vaga! É gratuito!

SQL Saturday 469 BrasíliaSQL Saturday 469

 

 

[]’s
Rodrigo Ribeiro Gomes

 

 

 

 

 

 

SQL SATURDAY #424: Mais detalhes

Olá! Como você tem investido seu tempo para aprender novas técnicas, desmistificar erros e conversar pessoalmente com profissionais experientes em SQL Server e tecnologias relacionadas?

Já ouviu falar no SQL Saturday? O SQL Saturday é um evento gratuito que reúne grandes nomes da comunidade SQL Server. São várias palestras com temas variados onde você pode aproveitar e incrementar o seu conhecimento, além de trocar experiências e até dar um novo passo em sua carreira. Você aprende e compartilha o conhecimento sobre o produto SQL Server. O evento é organizado pelo PASS (Professional Association for SQL Server) e ocorre no mundo todo. As palestras envolvem temas dos mais variados, passando por temas principais como Desenvolvimento, Administração, BI, etc. Em 2013, eu palestrei no SQL Saturday #253, em Brasília, e este ano vou apresentar em São Paulo. Confira todas as sessões.

Este ano o evento já aconteceu em Joinville, em Santa Catarina, e já está confirmado as edições de São Paulo e Brasília. Não, perca tempo e inscreva-se para participar do evento. Reforço: o evento é gratuito e te dará a chance de aprender mais e te permitir fazer um networking.

São Paulo (26/09/2015): http://www.sqlsaturday.com/424/eventhome.aspx
Inscreva-se e confirme sua participação: https://www.sqlsaturday.com/424/RegisterNow.aspx

Brasília (21/11/2015): http://www.sqlsaturday.com/469/eventhome.aspx
I
nscreva-se e confirme sua participaçãohttps://www.sqlsaturday.com/469/registernow.aspx

 

Mais detalhes sobre minha apresentação

Em 2013, escolhi um tema um pouco mais básico: Índices – Introdução. Por ser a primeira apresentação oficial, eu fiquei bem empolgado mas não queria submeter nada além do meu alcance. Este ano, para São Paulo, fui um pouco mais ousado e submeti um tema um pouco mais interessante: SQL Server, Windows e CPU. Eu já fiz esta apresentação para o VirtualPASSPT e também para um grupo de DBAs em um local que trabalhei. A primeira versão foi bem interessante mas não me agradou muito. Porém a segunda foi além de minhas expectativas e recebi bons feedbacks. Claro que para a versão de São Paulo irei fazer alguns ajustes, também para atender feedbacks, e estou confiante que o resultado ficará bem bacana!

Este é um tema um tanto interessante e é um assunto pouco falado. Vejo dezenas de artigos e blogs ensinando a usar contadores de performance, DMOs, etc., para solucionar, ou mesmo identificar, problemas de CPU, mas percebo que nem sempre existe uma base teórica boa a respeito deste assunto e que tornam as recomendações e dicas complicadas de entender ou de se aproveitar. É aí onde este tema entra. É o meu preferido. Para resumir, os principais assuntos envolvidos nesta apresentação são estes:

  • O significado do percentual de CPU
  • Mitos comuns em relação ao uso de CPU
  • O gasto de CPU por queries

Originalmente com o nome SQL Server CPUing, esta apresentação faz parte, de uma série de três apresentações, onde eu começo falando dos fundamentos e encerro com detalhes como Resource Governor e Hard Binding, além de dar uma boa pincelada em sincronização de threads, o que é extremamente importante. Porém, nenhuma das partes é tão interessante como a primeira. Pois ela é a base e tenho certeza que muita gente, mesmo estes com um pouco mais de experiência, vai aprender algo com ela. Por isso eu escolhi esta sessão para São Paulo.

O público-alvo são estes que já possuem alguma experiência com SQL Server, seja desenvolvendo, seja Administrando.

Este post fala um pouco sobre a apresentação. E este aqui tem um vídeo curto bem legal com principais trechos da apresentação. Dá pra ter uma idéia do que você vai encontrar.

Agradeço aos organizadores, especialmente ao Diego Nogare, pela oportunidade de contribuir para este evento, que é considerado um dos melhores da América Latina.

Bom, espero ver você lá, e não deixe de conferir e aproveitar ao máximo todo o evento. Tenho certeza que você irá sair de lá com bastante proveito.

E em breve, mais detalhes do evento em Brasília.

Pré-Conf Tune like a Guru!

No dia anterior ao SQL Saturday (25/09/2015) vai acontecer um treinamento sobre tunning, com o Kevin Boles, o @TheSQLGuru. Infelizmente eu não conseguirei está presente no horário da apresentação. Mas recomendo fortemente, que se você puder, aproveite esta oportunidade para aumentar suas habilidades de tuning com a experiência e técnicas que serão apresentadas por Kevin. O ingresso custa R$ 300 e é um excelente investimento.  Segue os principais assuntos abordados:

  • Processo de Otimização;
  • Estatísticas: Uso e Manutenção;
  • Índices: Uso e Manutenção;
  • Entendendo o Query Plan;
  • Configurações de Servidor e Database;
  • Melhoramentos no Design;
  • Melhoramentos no Código;
  • Análise de Profiler;
  • Uso de objetos temporários;
  • Análises de Waits e IO

Para se inscrever: https://www.eventbrite.com/e/tune-like-a-guru-by-kevin-boles-thesqlguru-tickets-17913462649

[]’s Rodrigo Ribeiro Gomes

Devo saber programar?

Oi caro leitor!

Estou abrindo um pequeno parênteses para compartilhar uma opinião que faz tempo que quero falar a respeito… Vou fugir um pouquinho do conteúdo técnico e vamos falar sobre conhecimento.

Nos últimos meses tenho experimentado problemas incrivelmente difíceis e interessantes ao mesmo tempo. Problemas que antes me davam medo só de pensar em acontecer, mas ultimamente, fico na expectativa que aconteçam! Sim, é isso mesmo que você leu… 🙂

A questão é que nos últimos meses eu desenvolvi mais ainda minhas habilidades e conhecimento dos porquês e dos funcionamento do SQL server e do Windows. Além do mais, graças a isso eu tenho conseguido ir direto na ferida e, por exemplo, ver estatísticas de uso de recursos e de performance me mostrarem valores mais positivos e elegantes, além de responder com segurança diversos questionamentos que me são feitos.

As aventuras mais recentes foram dois casos, um envolvendo consumo de CPU e o outro consumo de memória. Graças ao estudos dos últimos meses, eu pude, sem muita demora, encontrar a causa raiz, de forma certeira, entender os porquês e levantar soluções com ações simples. Tudo isso graças a utilização das ferramentas certas (isto é, queries, contadores de perfomance, DMVs, etc.).

Mas o que tem mudado e me permite ir tão certeiramente? Simples: um conhecimento mais rico e detalhado sobre como todas as partes envolvidas funcionam. Conhecer a arquitetura de um software e suas dependências é um fator determinamente na velocidade com a qual você vai solucionar problemas desconhecidos e novos, bem como te permitir estimar, planejar e “dizer nãos” com propriedade.

Ok, você pode está se perguntando onde entra a tal da programação e chegamos nela exatamente agora. A programação é a maneira como você torna as coisas mais palpáveis no mundo da TI.  Sabendo programar você materializa suas idéias. Este texto está ficando meio filosófico, mas não tenho outras palavras para descrever o que programar representa. Talvez eu resuma em uma: prática. Você sabe o que é um latch? Você sabe porque threads precisam se sincronizar? Você entende porque deve haver um CMEMTHREAD ? Você sabe ao menos explicar porque quando usa funções escalares, as queries tendem a ficar mais lentas? Você entende o que é uma heap ou um stack e porque é um conceito tão importante? Sabe o WinDBG…? Sabe a real utilizadade daquilo e pra quem server?Dica: Não é pro DBA! Você sabe programar? Pode parecer ignorância, mas para que certos conceitos fiquem mais claros, talvez colocar a mão na massa pode ser uma alternativa não mais rápida, mas efetiva a longo prazo. Isto é, um conhecimento que você não vai aproveitar uma única vez…

Claro, que não posso falar sobre programação sem falar em meus xodós: C/C++ e WINAPI. Eu fortemente recomendo que você aprenda essas duas coisas assim que puder. Isso vai te dar uma nova visão. Aqui que vos escreve não é nenhum expert, ou mesmo intermediário. Conheço algumas coisinhas (sempre fui apaxionado na linguagem C e na API do Windows)… Que já me ajudam bastantes… Imagine se eu  dominasse like a boss.

Aprender a programar pode fazer você absorver melhor os porquês de muitas coisas. Um software complexo, como um SGDB comercial, precisa ter o máximo de perfomance ao mesmo tempo que um controle do ciclo de vida. Sim estou falando de correções de bugs, novas versões, etc. Tudo isso vai definir, entre outras coisas, a arquitetura. E cá estamos aqui, falando de desenvolvimento, perfomance e arquitetura na mesma frase ;)…

Nossa Rodrigo que baboseira! Você está doido

Não, não estou. Assim como aprender inglês e a arquitetura do SO são essenciais, aprender a programar (e puxando a sardinha, aprender C) também é, e muito. Tudo, tudo mesmo, esta voltado e relacionado com programação. O software do mais simples ao mais complexo vão ter em comum o fato de terem sido criados usando alguma linguagem. Aprender a programar é aprender a entender a arquitetura do hardware e do sistema operacional .Familiar? Pelo menos um destes dois itens você precisa entender para lidar com qualquer vertente da área de tecnologia e o nível com o qual você os domina, é o nível com o qual você irá dominar a sua ferramenta de estudo/trabalho.

E afinal, somente serei o “bonzão” se souber programar?

A questão aqui não é ser o “bonzão”. Mas sim, realizar um trabalho com mais qualidade. Afinal, te pagam pelo seu conhecimento e tempo. Você pode ser um excelente profissional e de sucesso sem saber nada de programação. Assim como você não precisa saber muita coisa de inglês… Mas já tentou a diferença? Há algum assunto que você nunca entendeu? Alguma coisa que você achou que era de um jeito mas te mostraram que você estava errado? Então, certos conhecimentos vão incrementar suas habilidades, te fazer compreender os porquês, atuar como blocos simples (coisas complexas são feitas de várias simples). Cabe a você escolher se quer depender pelo resto da vida dos mecanismos de pesquisa ou se quer dominar o assunto e agir sem medo e com propriedade, dando resultados imediatos! Eu escolho a segunda opção e to seguindo nela já há algum tempo, sem arrependimentos, e gerando resultados.