PROCESSAMENTO E OPTIMIZAÇÃO DE PERGUNTAS

Tamanho: px
Começar a partir da página:

Download "PROCESSAMENTO E OPTIMIZAÇÃO DE PERGUNTAS"

Transcrição

1 PROCESSAMENTO E OPTIMIZAÇÃO DE PERGUNTAS & Unidade Curricular: Sistemas de Bases de Dados Mestrado em Engenharia Informática Faculdade de Ciências e Tecnologia - Universidade Nova de Lisboa Ano Lectivo: 2011/2012 Trabalho realizado por: André Pita, n.º Cosme Benito, n.º Pedro Albuquerque Santos, n.º 37606

2 ÍNDICE Índice... 1 Índice de Tabelas... 3 Índice de Figuras... 4 Introdução... 5 Processamento e Optimização de Queries... 6 MySQL... 8 Enquadramento... 8 Marcos Históricos... 8 Operações Básicas... 9 Optimização da cláusula WHERE... 9 Optimização da cláusula LIMIT Optimizações do GROUP BY Optimizações do INSERT Optimizações do Update Optimizações do Delete Optimização de Índices Optimizações de Tabelas InnoDB Optimizações de Tabelas MyISAM Optimização Index Merge Optimização Left Join e Right Join Optimização Block Nested-Loop Join Utilização de Índices Processamento de Expressões Complexas Manipulação das Escolhas do Optimizador Planos de Execução de Perguntas Output resultante da execução de Explain O comando EXPLAIN em detalhe Cálculo de Estimativas de Custo de Queries Customizar Estatísticas SQL Server Cronologia do Microsoft SQL Server Linguagem Intermédia Operações Básicas Planos de execução de Select Planos de execução de insert, update e delete Página 1

3 Processamento de Expressões Complexas Pipelining Paralelismo Manipulação das Escolhas do Optimizador Join Hints Query Hints NOEXPAND NOWAIT Planos de Execução de Perguntas Cálculo de Custos Histogramas Criação de Estatísticas Exemplo Prático Comparativo Tabela Comparativa MySQL vs SQL Server Conclusão Bibliografia Página 2

4 ÍNDICE DE TABELAS Tabela 1 - Resultado do comando EXPLAIN Tabela 2 - Resultado do comando EXPLAIN Tabela 3 - Valores de select_type Tabela 4 - Valores de type Tabela 5 - Valores Extra Tabela 6 - Resultado de SHOW TABLE STATUS Tabela 7 - Versões do SQL Server Tabela 8 - Tabela Comparativa entre MySQL, SQL Server e Oracle Database Página 3

5 ÍNDICE DE FIGURAS Figura 1 Diagrama de Processamento de Queries... 6 Figura 2 - MySQL Logo... 8 Figura 3 - Campos do information_schema.statistics Figura 4 - Visão parcial da tabale information_schema.statistics Figura 5 - SQL Server 2008 R2 Logo Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura 31 Plano de Execução Figura 32 - Espaço utilizado por uma tabela Figura 33 Partition Stats Figura 34 - DBCC SHOW_STATISTICS Página 4

6 INTRODUÇÃO Este trabalho é desenvolvido no âmbito da unidade curricular de Sistemas de Bases de Dados do Mestrado em Engenharia Informática da Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa, tendo como objectivo o estudo de alguns aspectos de sistemas de gestão de bases de dados relacionais. O tema do trabalho foi escolhido de entre algumas opções possíveis. O nosso trabalho vai-se então focar na análise na capacidade de processamento e optimização de perguntas de dois sistemas de bases de dados. Os sistemas escolhidos são o MySQL e o Microsoft SQL Server. O trabalho será estruturado na análise primariamente do MySQL e depois do Microsoft SQL Server, finalizando-se com uma análise comparativa dos dois face ao sistema que é alvo de estudo na unidade curricular, isto é, o Oracle Database. A escolha dos sistemas de bases de dados prendeu-se com o facto de um ser fruto de uma comunidade de desenvolvimento de software livre de código aberto (MySQL) e o outro ser uma solução proprietária de uma grande empresa de software (Microsoft SQL Server). Além disso ambos são largamente utilizados a nível profissional e empresarial, possuindo uma extensa comunidade e documentação de apoio. Para cada um dos sistemas escolhidos iremos tentar saber e demonstrar como é que implementam as operações básicas de processamento de queries (selecção, junção, ordenação, etc.), os algoritmos utilizados nessas operações e a forma como usam índices quando disponíveis. Tentaremos também averiguar quais os mecanismos que suportam para o processamento de expressões complexas, tais como materialização, pipelining e paralelização. Será também importante informar como é que é possível fornecer hints ao processador de queries do sistema de base de dados de modo a forçar a execução de uma query de uma determinada forma, diferente da escolhida por omissão pelo sistema, utilizando as ferramentas disponíveis para visualização dos planos de execução de queries para comparar os vários cenários. Tão importante como forçar a utilização de determinados métodos e algoritmos de processamento de queries será saber como é que estas são transformadas, como os seus planos de execução são construídos e optimizados e que estatísticas são suportadas para serem usadas nessas optimizações. Há um número de factores que afectam o desempenho de um servidor SQL. Como um mau desenho de tabelas e índices, que poderá levar a um aumento de interacções I/O (input/output) e pior desempenho. Página 5

7 PROCESSAMENTO E OPTIMIZAÇÃO DE QUERIES O tema fulcral deste trabalho é a forma como as queries que são submetidas num sistema de gestão de bases de dados relacional (SGBDR) são processadas. O processamento de uma query passa por diversos passos, tal como esquematizado na Figura 1. Existe uma fase em que a query é analisada e traduzida para uma representação de álgebra relacional. Esta representação é depois passada por um optimizador que irá avaliar os vários planos de execução e determinar qual será processado para gerar o output da query. Para facilitar o trabalho do processamento das queries é da maior importância uma boa utilização de tabelas e de índices, de forma a obter o desempenho máximo de um SGBDR. Por exemplo, podemos reduzir o tempo de pesquisa utilizando índices de forma adequada para apoiar as pesquisa e operações que estão a ser feitas. Se por um lado a criação de índices reduzirá o tempo de operações de selecção, como efeito colateral poderá afectar negativamente outras operações como as de inserção, actualização e eliminação, pelo que convém dosear o seu uso. FIGURA 1 DIAGRAMA DE PROCESSAMENTO DE QUERIES Para demonstrar as capacidades de processamento e optimização de queries dos SGBDRs iremos focar-nos no estudo de algoritmos de selecção, junção, ordenação e paralelismo. Serão também alvo de estudo a medição do custo de queries e avaliação de expressões. A nível de algoritmos de selecção tentámos identificar o uso dos seguintes: File scan Index scan Index scan External Sort-Merge Página 6

8 Para operações de junção iremos focar-nos em identificar a utilização dos seguintes algoritmos leccionados nas aulas teóricas: Nested-loop join Block nested-loop join Indexed nested-loop join Merge-join Hash-join Iremos ainda tentar determinar a existência de mecanismos de materialização, pipelining e paralelismo nos sistemas estudados. Ao nível da optimização propriamente dita há que considerar as situações em que uma mesma query introduzida por um utilizador possa ser executada com planos de execução diferentes. Para tal o optimizador do SGBDR terá que simplificar a expressão introduzida e gerar os planos de execução alternativos, tentando determinar o custo de execução de cada um deles, de forma a escolher o mais vantajoso. Cada plano de execução define os algoritmos e operações a serem efectuados sobre as tabelas da base de dados, numa determinada ordem. Todos os planos gerados através de regras de equivalência de álgebra relacional têm que ser de facto equivalentes, isto é, retornar exactamente o mesmo conjunto de resultados. Para cada plano de execução o custo será então estimado tendo em conta estatísticas sobre as tabelas, resultados intermédios e os próprios algoritmos. Será então escolhido o plano que apresente o menor custo estimado de execução. Tendo em conta a importância da optimização baseada em custos, ir-se-á também apresentar as estatísticas armazenadas e as formas de cálculo aplicadas para estimar os custos de execução de cada plano. Página 7

9 MYSQL Nesta secção iremos realizar o estudo dos vários aspectos referidos na introdução em relação ao sistema de base de dados MySQL. O MySQL encontra-se actualmente na sua versão 5.5 e é nessa que iremos focar o nosso estudo. Mais concretamente iremos utilizar a versão distribuída no pacote XAMPP 1. Antes de passarmos ao estudo do tema propriamente dito fassamos um enquandramento geral da história e origem do MySQL. ENQUADRAMENTO O MySQL começou a ser desenvolvido por dois Suecos e um Finlandês, David Axmark, Allan Larsson e Michael Monty Widenius respectivamente, porque queriam utilizar o sistema de base de dados msql, já existente, para conectar as suas tabelas utilizando o seu sistema de rotinas de baixo nível rápido (ISAM). No entanto, depois realizar alguns testes concluíram que o msql não satisfazia as suas necessidades. Perante este problema, desenvolveram um novo sistema de base de dados que tinha uma API bastante semelhante ao do msql, que viria a ser o MySQL. FIGURA 2 - MYSQL LOGO O MySQL ganhou muita dimensão por ser open source e por fornecer compatibilidade com drivers como o ODBC, JDBC e.net e também porque tem módulos de interface para diversas linguagens de programação, como Delphi, Java, C/C++, C#, Visual Basic, Python, Perl, PHP, ASP e Ruby. De todas estas linguagens destaca-se PHP, que tem vindo a ser largamente utilizada na Web para alojar websites que utilizam MySQL como o seu suporte de dados persistente. Casos muito comuns disso são blogs desenvolvidos em Wordpress, forums em phpbb, SMF, vbulletin, entre outros, e sites desenvolvidos com CMS (Content Management System) como Joomla ou Drupal. Até em grandes empresas e projectos se tem visto a utilização de MySQL, como no Flickr, Facebook, Wikipedia, Google, Nokia e YouTube. Desde o início do desenvolvimento do MySQL foi dada muita importância aos conceitos de performance, fiabilidade e portabilidade, sendo estes os aspectos que permitem que MySQL se distinga de entre os vários sistemas de base de dados. Para além destes conceitos e à medida que foram sendo lançadas novas versões do sistema, foram incluídas novas funcionalidades cuja ausência inicialmente levara a uma forte critica. Neste sentido, actualmente o MySQL disponibiliza diversas funcionalidades, nomeadamente Query Caching, Replicação, Triggers, Subqueries, Views e Cursores. Além disso é muito comum conjugar o MySQL com o sistema operativo Linux, o servidor HTTP Apache e a linguagem de programação PHP, sendo este pacote de tecnologias e ferramentas conhecido como LAMP (Linux, Apache, MySQL, PHP). MARCOS HISTÓRICOS 1994 Michael Widenius, Allan Larsson e David Axmark, começaram a desenvolver o MySQL Foi lançada a primeira publicação interna no dia 23 de Maio de Página 8

10 1998 Em 8 de Janeiro de 1998, é lançada uma versão com compatibilidade com alguns sistemas operativos de Windows 2001 Lançada a versão Lançada a versão Jyoti adopta o MySQL v Lançada a versão 4.1, que suporta R-Tree e B-Tree 2005 Lançada a versão 5.0, que suporta Cursores, procedimentos, triggers, views e transacções XA O MySQL AB é adquirido pela Sun Microsystems; Lançada a versão 5.1, a 27 de Novembro de Este suporta event scheduler, particionamento, plugin API, replicação baseada em tuplos e tabelas de server-log Oracle adquiriu a Sun Microsystems, em 27 de janeiro de Lançada a versão 5.5 a 15 de Dezembro. Uso da Storage Engine InnoDB por padrão, replicação semi-síncrona, melhor desempenho e maior escalabilidade em máquinas com múltiplos núcleos (multicore), são as principais novidades da versão. A próxima versão prevista é a versão 5.6, em que se esperam novidades nas seguintes áreas: Melhoramentos no optimizador, para melhor performance global nas queries. Melhoramentos ao nível do motor de armazenamento InnoDB para uma melhor performance transaccional Novas APIs memcached ao estilo NoSQL Melhoramentos de particionamento para fazer queries e gerir tabelas de grandes dimensões. Diversas melhorias a nível de replicação Novas capacidades de monitorização de performance através da expansão da informação disponível através do PERFORMANCE_SCHEMA. OPERAÇÕES BÁSICAS Nesta secção focamo-nos na descrição das operações básicas realizadas num sistemas de base de dados, com especial destaque à forma como o MySQL as realiza de forma optimizada. OPTIMIZAÇÃO DA CLÁUSULA WHERE Existem diversas optimizações realizadas pelo MySQL na cláusula where antes de esta ser executada: Remoção de parêntesis desnecessários ((a AND b) AND c OR (((a AND b) AND (c AND d)))) -> (a AND b AND c) OR (a AND b AND c AND d) Remoção de premissas inválidas ou redundantes; (B>=5 AND B=5) OR (B=6 AND 5=5) OR (B=7 AND 5=6) -> B=5 OR B=6 Substituição de valores por constantes, se estas forem definidas (a<b AND b=c) AND a=5 -> b>5 AND b=c AND a=5 Página 9

11 Expressões constantes usadas por índices apenas são avaliadas uma vez; Rápida detecção de expressões inválidas; HAVING é incluído no WHERE caso não existe nenhuma função de agregação; JOIN simplesmente implementado no WHERE; As tabelas constantes são as primeiras a ser lidas; Se existir um JOIN cujo ORDER BY ou GROUP BY sejam todos da mesma tabela essa tabela é a primeira a ser joined; O optimizador usa o melhor índice das tabelas a não ser que ache que existe uma maneira mais eficiente de o fazer; OPTIMIZAÇÃO DA CLÁUSULA LIMIT LIMIT: O MySQL consegue optimizar queries que usem o LIMIT row_count que não contenha a cláusula Quando o nº de rows seleccionadas é pequeno o MySQL usa índices quando normalmente usaria uma full table scan; Quando é usado um ORDER BY o MySQL ordena apenas as row_count primeiras rows ; Quando é usado um DISTINCT o MySQL pára após encontrar as row_count primeiras rows; LIMIT 0 retorna um set vazio imediatamente; Quando o MySQL usa tabelas temporárias usa o row_count para calcular o espaço necessário; Após enviar row_count rows para o cliente o MySQL aborta o restante cálculo da query. OPTIMIZAÇÕES DO GROUP BY A comum maneira de satisfazer uma cláusula GROUP BY é percorrer toda a tabela e criar uma nova tabela temporária com os dados já agrupados. Existem duas maneiras de executar o group by: Loose Index e Tight Index There are two ways to execute a GROUP BY query through index access, as detailed in the following sections. In the first method, the grouping operation is applied together with all range predicates (if any). The second method first performs a range scan, and then groups the resulting tuples. LOOSE INDEX SCAN A maneira mais eficiente de processar o GROUP BY é quando um índice é usado directamente para devolver os grupos de colunas. Com este método de aceso o MySQL usa a propriedade de alguns tipos de índice (por exemplo: BTree) cujas chaves estão ordenadas. Estas propriedades possibilitam a visualização de grupos de índices sem ter que satisfazer as condições de todas as chaves na cláusula WHERE. Quando não existe a cláusula WHERE, o algoritmo lê os grupos de chaves que são necessários. Para usar este tipo de algoritmo é necessário satisfazer algumas condições como: A query tem de ser sobre a mesma tabela; Os nomes das colunas na cláusula devem formar o prefixo mais a esquerda do índice; A única agregação que é feita na selecção só pode ser do tipo MIN() ou MAX(), e o tipo de coluna referenciado nestas tem de ser um índice e usado na cláusula GROUP BY ; Para as colunas que foram um índice, o valor dar coluna tem de ser indexado na integralidade. TIGHT INDEX SCAN Quando não é possível executar o algoritmo Loose Index Scan, em alguns casos ainda é possível fazer optimização através de índices e evitar as tabelas temporárias. Este algoritmo, pode ser feito através de Range Index Scan ou então por Full Index Scan. Normalmente aplicamos o Tight Index Scan quando Página 10

12 temos de ler todas as chaves que satisfazem as condições na cláusula WHERE, ou então quando fazemos uma leitura sobre todos os índices. Só depois de aplicar o algoritmo é que a cláusula GROUP BY é executada mas com as chaves que satisfazem as condições. Para usar este método tem de ser satisfeita uma condição de igualdade com uma constante, em todas as colunas, que referenciem partes da chave presente antes ou entre partes da chave do GROUP BY. No caso de recorrer a operação de ordenação dentro do agrupamento o MySQL evita operações de ordenação através dos prefixos dos índices que devolvem já as chaves ordenadas. OPTIMIZAÇÕES DO INSERT Quando se realiza um INSERT é importante ter noção que a maneira como inserimos dados no MySQL tem um impacto muito forte. Como tal existem algumas optimizações que podemos fazer, ao nível da query: Ao invés de se realizar vários INSERT é extremamente mais eficiente fazer um grande INSERT com todos os valores; Quando se está a ler uma tabela a partir de um ficheiro de texto é bastante mais rápido usar o comando LOAD DATA INFILE; Apenas inserir o valor de um campo quando este difere do valor por omissão, isto poupa o tempo que o MySQL perderia a fazer parsing desse valor; OPTIMIZAÇÕES DO UPDATE As optimizações do UPDATE são exactamente as mesma do SELECT, apenas é adicionado o overhead da escrita. OPTIMIZAÇÕES DO DELETE O tempo requerido para eliminar uma row é directamente proporcional ao número de índices. Para eliminar rows mais rapidamente pode aumentar a cache das chaves. OPTIMIZAÇÃO DE ÍNDICES A(s) chave(s) primárias(s) de uma tabela deve(m) ser a(s) coluna(s) usadas nas queries vitais e deverão ser NOT NULL. Assim será criado um índice associado e a performance será muito superior; Se uma tabela tiver diversas colunas e existirem queries para diversas combinações de colunas então uma boa ideia seria mover as colunas menos usadas para novas pequenas tabelas, relacionada com a principal. Assim cada tabela terá um Índice para rápidas pesquisas. OPTIMIZAÇÕES DE TABELAS INNODB Quando o tamanho de uma tabela cresce bastante é conveniente usar o comando OPTIMIZE TABLE para reorganizar a tabela e compactar o espaço desperdiçado. Em InnoDB ter PRIMARY KEY extensa desperdiça imenso espaço em disco. É preferível criar um campo com AUTO INCREMENT; VARCHAR é um tipo de dados mais eficiente do que CHAR para guardar strings de tamanho variável; Em InnoDB todas as tabelas têm uma chave primária atribuída, quer a tenhamos seleccionado ou não. É importante seleccionar as chaves primárias mais eficientes; Os índices deverão ser NOT NULL Se existirem queries usadas com frequência em tabelas que não actualizadas frequentemente é conveniente ligar a query cache. Página 11

13 OPTIMIZAÇÕES DE TABELAS MYISAM Evitar SELECTs complexos em tabelas usadas frequentemente para evitar problemas com o Table Lock; Após uma tabela ser completamente preenchida deverá ser usado o comando ANALYZE TABLE para melhorar a consistência dos índices da tabela; Evitar campos de tamanho variável em tabelas que são actualizadas frequentemente; Usar ORDER BY para seleccionar cambos pela ordem correcta no comando ALTER TABLE pode aumentar imenso a performance; Usar OPTIMIZE TABLE com frequência para evitar fragmentação. OPTIMIZAÇÃO INDEX MERGE O Index Merge é utilizado para devolver registos com diversas verificações por intervalo e para juntar os resultados numa só. Esta junção de resultados pode produzir uniões, intersecções, etc. Existem três algoritmos de acesso que passaremos a explicar. INDEX MERGE INTERSECTION ACCESS Este algoritmo pode ser utilizado quando a cláusula WHERE foi convertida em várias condições de intervalo com AND que respeitam uma das seguintes condições: Todos os índices estão igualados a uma constante e todos eles separados por AND; Qualquer condição de intervalo de uma primary key de uma tabela InnoDB. INDEX MERGE UNION ACCESS Neste algoritmo a ideia é a exactamente a mesmo do anterior mas com OR. Pode ser utilizado quando a cláusula WHERE foi convertida em várias condições de intervalo com OR que respeitam uma das seguintes condições: Todos os índices estão igualados a uma constante e todos eles separados por OR; Qualquer condição de intervalo de uma primary key de uma tabela InnoDB. INDEX MERGE SORT-UNION ACCESS O último algoritmo é utilizado apenas quando a cláusula Where é convertida em várias condições sob intervalo utilizando combinações de OR, mas em que não é possível utilizar o algoritmo Index Merge Union Access. OPTIMIZAÇÃO LEFT JOIN E RIGHT JOIN O MySQL implementa a condição A LEFT JOIN B condition da seguinte maneira: A tabela B está dependente de A e todas as tabelas de que A possa depender; A tabela A está dependente de todas as tabelas que são utilizadas na condição LEFT JOIN excepto da tabela B; A condição de junção é utilizada para decidir como recolher as rows da tabela B; Todas as optimizações de junção são feitas, com excepção de um tabela que é sempre lida depois de todas as tabelas de que depende. No caso de existir alguma um ciclo de dependências, o MySQL avisa o utilizador que ocorreu um erro; Todas as optimizações da cláusula WHERE discutidas acima serão feitas; Caso exista um row na tabela A que coincida com a cláusula WHERE mas não exista um correspondente na tabela B então são adicionadas as colunas da tabela B com todos os valores a NULL; Página 12

14 Se for utilizado LEFT JOIN para procurar registos que não existem em nenhuma tabela, e na cláusula WHERE se tem col_name IS NULL, em que que essa coluna está definida como NOT NULL então o MySQL pára de procurar registos assim que encontrar um registo que satisfaça a condição de junção; O RIGHT JOIN é análogo mas com os papéis das tabelas invertidos. Optimização Nested-Loop Join Este algoritmo baseia-se na leitura de um registo de cada vez da primeira tabela num ciclo, passando cada registo para um outro ciclo que vai processar as restantes tabelas da junção. Este processo será repetido tantas vezes quantas tabelas faltarem ser processadas na junção. OPTIMIZAÇÃO BLOCK NESTED-LOOP JOIN O Block Nested-Loop extende o algoritmo anterior ao adicionar buffering de rows lidas nos outer loops de modo a reduzir o número de leituras. O MySQL usa este algoritmo se: A variável de sistema join_buffer_size determina o tamanho de cada buffer; Um buffer é alocado para cada junção, desta forma cada query que seja processada pode utilizar múltiplos buffers; Um buffer nunca é alocado para a primeira tabela; Numa determinada junção, nem todos os registos são guardados no buffer, apenas aquelas que obedecem a uma dada condição. Página 13

15 UTILIZAÇÃO DE ÍNDICES Os algoritmos de indexação são usados para tornar as pesquisar mais eficientes. Sem indexação o MySQL teria de iterar sempre todos os tuplos da tabela, índices é gerada uma colecção de atributos que pretendemos pesquisar e iteramos apenas sobre essa colecção. Nos engines que estamos a considerar (MyISAM e InnoDB) a única indexação disponível é a B+Tree. PROCESSAMENTO DE EXPRESSÕES COMPLEXAS O MySQL não suporta vistas materializadas nativamente, paralelismo ou pipelining. Como tal, não tem qualquer suporte específico para o processamento de queries com expressões de elevada complexidade. Tal poderá ser um handicap para algumas utilizações mais avançadas de um sistema de bases de dados. MANIPULAÇÃO DAS ESCOLHAS DO OPTIMIZADOR O MySQL apenas permite manipular as escolhas do optimizador ao nível da selecção dos índices a utilizar. Esta manipulação é feita através de Index Hints aquando da realização de uma query de selecção. A sintaxe para as referidas hints é a seguinte: tbl_name [[AS] alias] [index_hint_list] index_hint_list: index_hint [, index_hint]... index_hint: USE {INDEX KEY} [{FOR {JOIN ORDER BY GROUP BY}] ([index_list]) IGNORE {INDEX KEY} [{FOR {JOIN ORDER BY GROUP BY}] (index_list) FORCE {INDEX KEY} [{FOR {JOIN ORDER BY GROUP BY}] (index_list) index_list: index_name [, index_name]... Utilizando o USE INDEX (index_list) é possível indicar ao MySQL para utilizar um determinado índice para encontrar linhas numa tabela. Alternativamente é possível utilizar o IGNORE INDEX (index_list) para impedir a utilização de um ou mais índices. Estas hints são especialmente úteis se o MySQL estiver a utilizar o índice incorrecto, conforme pode ser visto no plano de execução de uma query (alvo de estudo mais à frente neste trabalho). Existe ainda o FORCE INDEX que funciona de forma semelhante ao USE INDEX só que neste caso considera-se que um table scan é muito dispendioso, isto é, o table scan apenas é utilizado se não houver forma de executar a query utilizando os índices fornecidos. Em cada hint é necessário o nome do(s) índice(s) a utilizar. No caso do índice de uma chave primária o seu nome é PRIMARY. É ainda possível, no caso do USE INDEX, fornecer uma lista vazia de índices, o que significa que não deve ser utilizado qualquer índice. É também possível definir o scope de uma hint através da cláusula FOR. Por exemplo, FOR JOIN afecta apenas a utilização de índices nas operações de JOIN, FOR ORDER BY nos ORDER BY Página 14

16 e FOR GROUP BY os GROUP BY. Apesar desta funcionalidade, se existir um índice sobre uma tabela a ser acedida e este for utilizado para o seu acesso hints como IGNORE INDEX FOR {ORDER BY GROUP BY} são simplesmente ignoradas. Exemplos da utilização de hints: SELECT * FROM table1 USE INDEX (col1_index,col2_index) WHERE col1=1 AND col2=2 AND col3=3; SELECT * FROM table1 IGNORE INDEX (col3_index) WHERE col1=1 AND col2=2 AND col3=3; Podem-se especificar várias hints na mesma query: SELECT * FROM t1 USE INDEX (i1) IGNORE INDEX FOR ORDER BY (i2) ORDER BY a; Pode-se utilizar o mesmo índice em várias hints, e mesmo na mesma hint: SELECT * FROM t1 USE INDEX (i1) USE INDEX (i1,i1); Mas não se pode FORCE INDEX e USE INDEX para a mesma tabela (causa um erro): SELECT * FROM t1 USE INDEX FOR JOIN (i1) FORCE INDEX FOR JOIN (i2); Se numa hint não for específcado o FOR então a hint aplicar-se-á a todos os casos. É possível definir a variável old aquando do arranque do servidor, significando que nesse caso a ausência de FOR indica que a hint apenas deve ser aplicada ao acesso a linhas da tabela. Quando as hints são processadas estas são agrupadas numa única lista, por tipo e por scope. Por exemplo: SELECT * FROM t1 USE INDEX () IGNORE INDEX (i2) USE INDEX (i1) USE INDEX (i2); é equivalente a: SELECT * FROM t1 USE INDEX (i1,i2) IGNORE INDEX (i2); As hints são então aplicadas para cada scope na seguinte ordem: USE INDEX e FORCE INDEX são aplicadas se presentes (se não são aplicadas as regras do optimizador) IGNORE INDEX é aplicado após o resultado do passo anterior. Por exemplo, estas duas queries são equivalentes: SELECT * FROM t1 USE INDEX (i1) IGNORE INDEX (i2) USE INDEX (i2); SELECT * FROM t1 USE INDEX (i1); Para pesquisas FULLTEXT as hints funcionam da seguinte forma: Para pesquisas em modo de linguagem natural as hints são simplesmente ignoradas. Para pesquisas em modo booleano hints que contenham FOR ORDER BY ou FOR GROUP BY são simplesmente ignoradas. Hints com FOR JOIN ou sem FOR são tidas em conta na execução da query. Em contraste com as queries tradicionais no caso da utilização de FULLTEXT a hint é utilizada em todas as fases de execução de queries. Tal é válido mesmo se a hint for sobre um índice não FULLTEXT. Por exemplo, estas duas queries são equivalentes: Página 15

17 SELECT * FROM t USE INDEX (index1) IGNORE INDEX (index1) FOR ORDER BY IGNORE INDEX (index1) FOR GROUP BY WHERE... IN BOOLEAN MODE... ; SELECT * FROM t USE INDEX (index1) WHERE... IN BOOLEAN MODE... ; Por fim, há ainda que referir que as hints são aceites em expressões de UPDATE mas são completamente ignoradas. PLANOS DE EXECUÇÃO DE PERGUNTAS OUTPUT RESULTANTE DA EXECUÇÃO DE EXPLAIN O MySQL possui um mecanismo que gera automaticamente o plano para um dado query ou tabela. Este mecanismo é especialmente útil para optimizar queries e/ou a estrutura da base dados. Usando um exemplo muito simples com duas tabela teste e teste2 exactamente iguais, sem índices e apenas três registos. Usamos então o comando EXPLAIN: EXPLAIN SELECT * FROM teste INNER JOIN teste2 ON teste.id = teste2.id O resultado obtido seria o apresentado na Tabela 1. TABELA 1 - RESULTADO DO COMANDO EXPLAIN id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE teste ALL NULL NULL NULL NULL 3 1 SIMPLE teste2 ALL NULL NULL NULL NULL 3 Using where Como podemos observar o resultado mostra-nos o plano de execução para uma dada query e revela-nos desde já um dado interessante: o resultado final tem três rows mas nós sabemos que tem apenas um. Isto acontece pelo facto de não estarmos a usar nenhum índice. Colocando o id com índice vemos que o resultado é um pouco diferente, como mostrado na Tabela 2. TABELA 2 - RESULTADO DO COMANDO EXPLAIN id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE teste ALL PRIMARY NULL NULL NULL 3 1 SIMPLE teste2 eq_ref PRIMARY PRIMARY 4 Teste.id 1 Podemos então comprovar que o resultado esperado já tem apenas uma row que era o que estávamos à espera. Reparamos também que o EXPLAIN nos indica a ordem com que as tabelas estão a ser comparadas. A ordem neste exemplo não é relevante mas num join com várias tabelas a ordem pode ter uma grande importância na performance. Página 16

18 O COMANDO EXPLAIN EM DETALHE O comando Explain, tal como já vimos, devolve uma linha por cada tabela utilizada no comando SELECT. As tabelas são listadas pela mesma ordem que o MySQL as lê durante o processamento da query. A partir de um algoritmo de Nested-Loop Join, o MySQL efectua todas as junções que existem na query. Cada linha do resultado do Explain contém informação sobre uma tabela, composta pelas colunas: id - Identificador do SELECT; select_type - tipo de SELECT executado, os vários valores que a coluna pode tomar são detalhadamente descritos na Tabela 3; table - nome da tabela a que corresponde a linha do Explain; type - tipo de junção, os vários valores que esta coluna pode tomar são tratados na Tabela 4; possible_keys - indica qual o índice que o MySQL pode escolher usar para encontrar os registos da tabela. Esta coluna pode ter o valor Null, representando a inexistência de indexes relevantes para a selecção. Neste caso, é possível tentar melhorar o desempenho da query, examinando a cláusula Where, e verificando se existe alguma coluna referenciada que beneficiasse com a criação de um índice; key - indica qual a chave(índice) que o MySQL decidiu utilizar. No InnoDB, um index secundário pode ser seleccionado mesmo que a query já tenha seleccionado a chave primária, uma vez que o InnoDB guarda o valor da chave primária com cada index secundário. Se o valor de key for NULL, o MySQL não encontrou nenhum índice que tornasse a query mais eficiente; key_len - indica o comprimento da chave(índice) que o MySQL decidiu utilizar; ref - define o número de constantes ou colunas que são comparadas com o índice key para selecionar registos pretendidos da tabela; rows - no storage engine em estudo, InnoDB, esta coluna coluna representa uma estimativa do valor de registos acedidas durante a execução da query; filtered - indica uma estimativa percentual dos registos da tabela que serão filtrados pela condição. Isto é, rows contém o número estimado de registos que são examinados e rows filtered/100 representa o número de registos que sofrerão a junção das tabelas anteriores. Esta coluna apenas surgirá se for usada a opção Explain Extended; Extra - contém informação adicional de como o MySQL resolveu a query. Os valores que Extra pode tomar são apresentado na Tabela 5. É possível retirar conclusões de quão bom é um join dependendo dos valores indicados na coluna rows. Esta indica-nos quantos registos o MySQL tem de examinar para processar a query em questão. Se as queries estiverem restringidas pela variável de sistema max_join_size, este total de registos é usado para determinar se se deve executar o comando SELECT com múltiplas tabelas, ou se deve abortar. TABELA 3 - VALORES DE SELECT_TYPE Valor select_type SIMPLE PRIMARY UNION DEPENDENT UNION UNION RESULT SUBQUERY DEPENDENT SUBQUERY Significado SELECT simples, sem Union nem subqueries Outermost SELECT Segundo SELECT, ou posterior, numa UNION Segundo comando SELECT, ou posterior, numa UNION dependente de uma outer query Resultado de uma UNION. Primeiro SELECT numa subquery Primeiro SELECT numa subquery, dependendo de uma outer query Página 17

19 DERIVED UNCACHEABLE SUBQUERY UNCACHEABLE UNION Tabela derivada de SELECT (subquery numa cláusula FROM) Uma subquery para a qual o resultado não pode ser armazenado em cache e que tem que ser reavaliado para cada linha da outer query. Segundo SELECT, ou posterior, numa UNION que pertence a uma subquery que não pode ser guardada em cache. (veja UNCACHEABLE SUBQUERY) TABELA 4 - VALORES DE TYPE Valor type system const eq_ref ref fulltext ref_or_null index_merge unique_subquery index_subquery range index ALL Significado A tabela contém apenas um registo, sendo este um caso especial do tipo de junção const A tabela tem pelo menos um registo que coincide, o que é lido desde o inicio de query. As tabelas const são bastante rápidas uma vez que são lidas apenas uma vez Um registo é lido da tabela, para cada combinação de registos das tabelas anteriores Todos os registos que coincidam com o valor do índice são lidos da tabela, para cada combinação de registos das tabelas tratadas anteriormente. Este ref é utilizado se a junção usar apenas a o prefixo leftmost da chave ou se a chave não é primária ou índice Unique. Pode ser usado para colunas indexadas que sejam comparadas a partir dos operadores de comparação =, <=> Esta junção é processada a partir um índice FULLTEXT Idêntico ao ref, se bem que ainda é feita uma procura extra pelo MySQL, à procura de registos que contenham valores Null. Este tipo de optimização de junção é utilizado maioritariamente na avaliação de subqueries Indica que foi utilizada uma optimização Index Merge. Neste caso, a coluna key da tabela resultante do comando Explain, contém a lista de índices usados, enquanto que a key_len contém a lista das maiores partes das chaves dos índices utilizados Substitui o ref por algumas subqueries IN, isto é, a partir de uma função de pesquisa por índice, reformula a subquery de forma a obter uma maior eficiência Este tipo de junção é semelhante ao unique_subquery. Substituindo as subqueries IN, mas funciona para os índices não-únicos de subqueries Apenas os registos que estão num dado intervalo são devolvidos, estes registos são seleccionados a partir da utilização de índices. Para estes tipos de junção a coluna ref tem o valor Null. O range pode ser usado quando uma chave é comparada com uma constante através da utilização de operadores de comparação. Este tipo de junção é o mesmo que o ALL, exceptuando o facto de que apenas a árvore de índices é verificada. Normalmente, este tipo é mais rápido que o ALL, uma vez que o ficheiro dos índices é maioritariamente mais pequeno que o ficheiro de dados É feita uma verificação completa sobre uma tabela para cada combinação de registos das tabelas já analisadas. É possível evitar este ALL através da criação de índices que permitem a recuperação do registo da tabela baseada em valores constantes ou valores de colunas de tabelas anteriores. A coluna extra, resultante do comando Explain, contém informação acerca de como o MySQL processou a query. Segue-se uma lista com os valores que esta coluna pode tomar. Se se pretender melhorar a velocidade de uma query, é aconselhável analisar os valores Using filesort e Using temporary. TABELA 5 - VALORES EXTRA Valores type const row not found Significado A tabela sujeita a query encontra-se vazia Página 18

20 Distinct Full scan on NULL key Impossible Having Impossible Where Impossible Where notice after reading const tables No matching minmax row no matching row in const table No tables used No exists Range checked for each record (index map N) Scanned N databases SELECT tables optimized away Skip_open_table, Open_frm_only, Open_trigger_only, Open_full_table unique row not found Using filesort Using index Using index for groupby Using join buffer Using sort_union(...), Using union(...), Using intersect(...) Using temporary Using where O MySQL procura por valores distintos, assim, pára a procura por mais registos para a actual combinação destes depois de encontrar um registo que coincida Esta situação ocorre na optimização de subquery, uma vez que o plano de optimização não pôde utilizar a pesquisa por índice A cláusula Having é sempre falsa e não selecciona qualquer registo A cláusula Where é sempre falsa e não selecciona qualquer registo; O MySQL leu todas as tabelas constantes e informa que a cláusula Where é sempre falsa Nenhum registo satisfaz a condição de uma query: SELECT MIN( ) F R O M WHERE condicao Para queries com junções, existe uma tabela sem registos ou então sem registos que satisfaçam a condição do índice único A query não tem a cláusula From, ou então tem uma cláusula From Dual em que nenhuma tabela foi especificada; O MySQL consegue fazer uma optimização Left Join na query e não necessitando de examinar mais registos nesta tabela para para as anteriores combinações, depois de encontrar um registo respeite o critério de Left Join O MySQL não encontrou nenhum índice que fosse bom para utilizar. Ainda assim, verificou que alguns podem ser utilizados depois de se conhecerem os registos das tabelas anteriormente analisadas Este valor indica quantas directorias foram processadas durante a execução da query A query contém apenas funções de agregação (Min(), Max()) que foram resolvidas através de um índice. O plano de optimização determinou que apenas um registo deveria ser devolvido Open_full_table - qualquer destes valores indica que foi aplicada uma optimização na abertura do ficheiro sobre as queries que envolvem as tabelas Information_Schema Para uma query: SELECT FROM nome_tabela Nenhum registo satisfaz a condição da índice único ou de chave-primária da tabela O MySQL deve fazer mais um passo para encontrar aforma de recuperar os registos ordenados. A informação da tabela é obtida utilizando apenas informações que estejam na árvore de índices, sem ter que fazer nenhuma pesquisa adicional para ler o registo actual. Tal pode acontecer quando a consulta só utiliza colunas que fazem parte de um único índice. No caso do storage engine InnoDB, as tabelas que têm um clustered index definido pelo utilizador, esse índice pode ser utilizado mesmo quando está ausente o valor Using index na coluna Extra. Este é o caso em que a coluna type tem index e a key contém Primary Idêntico ao anterior, indicando que o MySQL descobriu um índice que pôde ser usado para obter todas as colunas de uma query com Group By ou Distinct sem qual acesso extra ao disco para a actual tabela As tabelas provenientes de junções anteriores são lidas em porções para dentro do join buffer, e então os seus registos são utilizados do buffer para efectuar a junção com a actual tabela Indica como o índices são unidos obtendo-se o tipo de junção index_merge Para resolver a consulta o MySQL necessita criar uma tabela temporária para guardar o resultado. Esta situação normalmente sucede quando a query contém as cláusulas Group By e Order By referindo-se a colunas diferentes Indica o uso da cláusula Where que o utilizador usou para limitar a consulta. No Página 19

21 Using where with pushed condition caso da coluna Extra não conter este valor e o tipo de join contiver All ou index, algo de errado se passa com a query Este valor apenas se aplica a tabelas NDBCLUSTER (um dos storage engines do MySQL). Significando que o MySQL Cluster está a utilizar a opmitização Condition Pushdown para melhorar a eficiência de uma comparação directa entre um constante e um coluna não indexada. CÁLCULO DE ESTIMATIVAS DE CUSTO DE QUERIES Para estimar o custo de execução de uma query, normalmente o factor mais importante a ter em conta é o número de disk seeks realizados. Em tabelas de pequena dimensão poder-se-á encontrar um registo com apenas um disk seek, pois o índice se encontra muito possivelmente em cache. No caso de tabelas maiores é possível estimar quantos disk seeks serão necessários, usando índices B+Tree, a partir da seguinte fórmula: ( ) O MySQL utiliza blocos para índices com 1024 bytes e data pointers de 4 bytes. Só se começa a notar um decréscimo na performance de uma query quando os dados começam a ser demasiado grandes para estar em cache, quer no sistema operativo ou no MySQL, dando origem a um número elevados de disk seeks. Para controlar de algum modo esta perda de performance é possível parametrizar o MySQL para aumentar o tamanho do buffer utilizado para blocos de índices. No caso do storage por omissão do MySQL, o InnoDB, para evitar que as consultas se comecem a tornar lentas é possível alterar o valor da variável innodb_buffer_pool_size que controla o valor máximo que é permitido guardar em cache. Algumas das variáveis apresentadas na fórmula apresentada, podem ser calculadas directamente sem ser necessário por exemplo contar todas as linhas de uma determinada tabela, uma vez que todas as informações relativas a todas as tabelas da base de dados se encontram alojados na tabela information_schema.statistics. Cada registo desta é referente a uma tabela da base de dados, e é composta pelos campos listados na Figura 3. Página 20

22 FIGURA 3 - CAMPOS DO INFORMATION_SCHEMA.STATISTICS Uma visão parcial da tabela information_schema.statistics pode ser vista na Figura 4. Na figura é possível ver a na coluna CARDINALITY o número de tuplos por tabela. E realmente, no caso da tabela address realizando SELECT COUNT(*) FROM address o resultado é 19614, mostrando como a estatística está próxima da realidade. O comando ANALYZE TABLE <nome da tabela> pode ser utilizado para recalcular as estatísticas de uma dada tabela. No caso do InnoDB é possível ajustar o número de páginas analisadas através da alteração do parâmetro innodb_stats_sample_pages, que por omissão toma o valor de 8 páginas. Quanto mais elevado o valor mais precisa a estatística mas mais pesada será a sua computação. FIGURA 4 - VISÃO PARCIAL DA TABALE INFORMATION_SCHEMA.STATISTICS Para além da utilização da tabela de sistemas information_schema.statistics, existe ainda o comando SHOW TABLE STATUS. Voltando a usar novamente as simples tabelas teste e teste2 que são exactamente iguais e contêm apenas três registos podemos ver os resultados do referido comando na Tabela 6. TABELA 6 - RESULTADO DE SHOW TABLE STATUS Name Engine Version Row_for mat Rows Avg_row _length Data_Length Max_data_le ngth Index_le ngth Data_free teste MyISA M 10 Dynamic Página 21

23 Name Engine Version Row_for mat Rows Avg_row _length Data_Length Max_data_le ngth Index_le ngth Data_free teste2 MyISA M 10 Dynamic A tabela não se encontra completa mas os dados mais relevantes estão presentes. Também é possível ver o checksum, data de criação e edição de cada tabela. CUSTOMIZAR ESTATÍSTICAS Não existe um comando explícito para controlar directamente a maneira como as estatísticas são calculadas. A única customização que se pode fazer ao nível das estatísticas apenas está presente no engine InnoDB. É possível parameterizar o número de sample pages usado para estimar a cardinalidade de um índice cujo valor por omissão é 8. Díminuir este valor pode aumentar a performance do optimizador mas reduzir a sua precisão. Aumentar o valor faz o inverso. SQL SERVER O Microsoft SQL Server é um sistema de gestão de bases de dados criado pela Microsoft em 1989, sendo inicialmente desenvolvido em parceria com a Sybase. Após o termo do acordo com a Sybase em 1994, o desenvolvimento continuou por parte da Microsoft aperfeiçoando o produto a cada versão desde então. As várias versões lançadas até hoje podem ser visualizadas na Tabela 7, sendo que neste trabalho iremos focar-nos essencialmente na análise da última versão, o SQL Server 2008 R2 (actualmente com o seu Service Pack 1). Apesar de apenas estar disponível para utilização em ambientes Windows, tem hoje uma forte posição no mercado de sistemas de bases de dados, potenciado pelo sucesso de outros produtos da Microsoft, nomeadamente o Windows e tecnologias.net, com os quais se integra facilmente. Disponibiliza também capacidades bem ao nível de outros pesos pesados do mercado, tais como a Oracle e a IBM (com o seu sistema DB2). Tem também actualmente disponível uma versão baseada em cloud computing, o SQL Server Azure, mostrando que a Microsoft está determinada em continuar a expandir e melhorar o produto. TABELA 7 - VERSÕES DO SQL SERVER Versão Ano Nome da versão Nome de código 1.0 (OS/2) 1989 SQL Server 1.0 (16bit) (OS/2) 1991 SQL Server 1.1 (16bit) (WinNT) 1993 SQL Server 4.21 SQLNT SQL Server 6.0 SQL SQL Server 6.5 Hydra SQL Server 7.0 Sphinx Página 22

24 SQL Server 7.0 OLAP Tools Plato SQL Server 2000 Shiloh SQL Server bit Edition Liberty SQL Server 2005 Yukon SQL Server 2008 Katmai SQL Azure Matrix (aka CloudDB) SQL Server 2008 R2 Kilimanjaro (aka KJ) SQL Server 2012 Denali CRONOLOGIA DO MICROSOFT SQL SERVER Microsoft lança sua primeira versão do SQL Server. desenvolvida para a plataforma OS/2 juntamente com a Microsoft e a Sybase. Início dos anos 90 - Microsoft inicia o desenvolvimento de uma versão para a plataforma Windows NT. Enquanto o SQL Server estava sendo desenvolvido a Microsoft decidiu que ele deveria ser uma camada encapsulada sobre o sistema operativo Windows NT Lançamento do Windows NT 3.1 e o SQL Server 4.2 (primeira versão para a nova plataforma NT). A filosofia da Microsoft em combinar um banco de alta performance com uma interface fácil de usar mostrou-se um sucesso. Microsoft rapidamente tornou-se o segundo mais popular vendedor de softwares de bancos de dados relacionais Microsoft e a Sybase encerram formalmente a sua parceria Lançamento da versão 6.0 do SQL Server. Esse lançamento foi uma das maiores rescritas da tecnologia SQL Server. A versão 6.0 aumentou a performance substancialmente provendo mecanismos internos de replicação e administração centralizada Lançamento da versão 6.5 do SQL Server. Essa versão trouxe melhoras significativas para a tecnologia e disponibilizou diversas novas funcionalidades A Microsoft lançou a versão Enterprise do SQL Lançamento da versão 7 do SQL Server o qual foi completamente rescrito Lançamento do SQL Server Essa versão foi construída sobre o framework do SQL Server O SQL Server 2000 ganha a sua versão em 64-bit para processadores Intel Itanium, podendo aceder a maiores quantidades de memória É lançado o SQL Server 2005 (nome de código Yukon) com grande integração com a plataforma.net. O SQL Server dá mais um passo em direcção às grandes plataformas corporativas. A Microsoft Página 23

25 exibe alguns grandes casos de sucesso (como a Xerox que consegue realizar até de transações diárias utilizando o SQL Server 2005 e a Bovespa, que é a bolsa de valores do Brasil) Lançamento do SQL Server 2008 com o principal slogan de "ir um pouco além do relacional". Novas funcionalidades como tipos de dados geográficos, controle de carga por usuário, etc são introduzidas Lançamento do SQL Server 2008 R2. O nome SQL Server 2010 não foi utilizado pois trata-se apenas de uma versão com alguns melhoramentos face à anterior, trazendo até algumas funcionalidades prometidas para a versão 2008 que não foram cumpridas. FIGURA 5 - SQL SERVER 2008 R2 LOGO LINGUAGEM INTERMÉDIA Utiliza como linguagem intermédia o CLR (Common Language Runtime) que permite aos programadores implementarem procedimentos, triggers e funções em qualquer outra linguagem que utilize CLR, mais especificamente, Microsoft Visual C#.NET, Microsoft Visual Basic.NET, e Microsoft Visual C++. Permitindo também estender a base de dados com novos tipos e agregados. OPERAÇÕES BÁSICAS Passamos agora a demonstrar diversas operações básicas feitas na nossa base de dados, com o efeito de demonstrar o funcionamento por detrás de cada uma delas. PLANOS DE EXECUÇÃO DE SELECT SELECT * Um simples select from onde podemos ver duas formas e a eficiência destas: FROM Person.Contact Obtemos o plano de execução da Figura 6 com utilização de um clustered índex.como podemos ver na imagem a operação de varrimento é aplicada ao índice para obter a informação necessária. Os índices no SQLServer são guardados como B-tree. Que não só guarda a estrutura principal como a própria informação nela contida, inclusivamente ordenando-a. Por esta razão é que não existe mais do que um clustered índex por tabela. Como tal qualquer varrimento deste índice é como uma pesquisa na tabela. O optimizador inclusivamente consegue escolher se realmente utiliza a chave de identificação do índice ou se simplesmente percorre todas as casas deste pela ordem que estão guardadas caso seja necessária a passagem por muitas ou todas as casas. Página 24

26 FIGURA 6 Agora um exemplo sobre da cláusula where aplicada ao exemplo acima (Figura 7): SELECT * FROM Person.Contact WHERE ContactID = 1 Como podemos ver a operação de pesquisa é totalmente diferente da de varrimento, onde o motor passa por todas as linhas para descobrir o que precisa. A operação pesquisa, quer seja clustered ou não, ocorre num índice quando o optimizador consegue encontrar um que contenha todos os registos necessários. Seguidamente o valor da chave é utilizado para rapidamente identificar a linha que se procura, sendo esta imediatamente devolvida pois a informação encontra-se contida no próprio índice. Página 25

27 FIGURA 7 Considerando agora uma pesquisa sobre um índice non-clustered de s (Figura 8): SELECT ContactID FROM Person.Contact WHERE Address LIKE sab% A pesquisa em si é feita da mesma forma que um índice clustered. Dependendo da query em si o optimizador poderá encontrar toda a informação no índice ou terá também que procurar clustered index piorando o seu desempenho, como será demonstrado seguidamente. Página 26

28 FIGURA 8 Voltando à query anterior e adicionando alguns campos, passemos a considerar (Figura 9, conjunto das 3 figuras nas próximas páginas). SELECT ContactID, LastName. Phone FROM Person.Contact WHERE Address LIKE %sab Como podemos ver no plano teremos mais do que uma operação isto porque o optimizador não será capaz de obter toda a informação (colunas) que necessita a partir do índice non-clustered, ou seja non-covering, como consequência é forçado a não só ler o índice anterior como o clustered índex de forma a devolver o pesquisado. Página 27

29 Página 28

30 FIGURA 9 Estes valores serão então utilizados para fazer uma pesquisa por chave sobre o índice clustered para obter a informação do último nome e telefone que corresponde a cada um dos tuplos. Uma key lookup indica que a query poderá beneficiar de uma optimização, como a adição de um covering ou included índex. Ambas as hipóteses contêm todas as colunas que precisam ser devolvidas para satisfazer a query evitando assim o key lookup. Um key lookup está sempre acompanhado por um nested loop join para combinar os resultados das duas operações (Figura 10). Página 29

31 FIGURA 10 Também é possível que o query optimizer decida fazer um table scan, que simplesmente percorre cada linha da tabela. Utilizado quando a tabela não tem nenhum índice, ou quando necessita de devolver todas as entradas da tabela, neste último caso por vezes é mais rápido aceder a todas as linhas da tabela do que percorrer cada tuplo no índice (normalmente ocorre em tabelas mais pequenas). Para demonstrar este caso fazemos (Figura 11): SELECT * FROM [dbo].[databaselog] Página 30

32 FIGURA 11 Tal como nos índices temos o RID lookup (Raw ID), que nos permite aceder a partir de um identificador a uma linha da tabela. Consideramos então a seguinte query (Figura 12): SELECT * FROM [dbo].[databaselog] WHERE DatabaseLogID = 1 Página 31

33 FIGURA 12 Para devolver os resultados que satisfazem a query pedida, o optimizador começa por fazer um índex seek na chave primária para determinar o resultado da cláusula WHERE, faltando só obter os dados das outras colunas que não se encontram no índice (Figura 13). Como podemos ver o próprio índex seek devolve como output um Bmk1000 que comprova que este faz parte de um plano para responder à query pedida, seguidamente utilizando esta referência faz um RID look up para devolver a linha com os dados desejados, pois estamos a considerar que não existe um clustered índex para esta tabela (que tornaria esta pesquisa não só mais rápida, como a reduziria a uma operação). Seguidamente os resultados teriam de ser juntos com a operação de nested loops join(figura 14). Página 32

34 . FIGURA 13 Página 33

35 FIGURA 14 Introduzimos agora a ideia de união de tabelas, consideremos o seguinte caso: SELECT e.[title], a.[city], c.[lastname] +, + c.[firstname] AS EmployeeName FROM [HumanResources].[EmployeeAddress] e JOIN [HumanResources].[EmployeeAddress] ed ON e.[employeeid] = ed.[employeeid] JOIN [Person].[Address] a ON [ed].[addressid] = [a].[addressid] JOIN [Person].[Contact] c ON e.[contactid] = c.[contactid]; Obteremos o seguinte plano de execução (Figura 15). Página 34

36 FIGURA 15 Como podemos ver para resolver esta query teremos que processar múltiplos passos, que têm custos diferentes, os custos são acumulados da direita para a esquerda: 1. O índex scan da tabela Person.Address (45%); 2. A junção por hash match entre HumanResources.Employee.Address e Person.Address (28%); 3. O clustered índex seek na tabela de Person.Contact (18%). Vamos então analisar cada operação, começamos com o índex scan sobre o índex que corresponde à tabela HumanResources.EmployeeAddress, directamente abaixo temos outro scan desta vez sobre o índice de Person.Address (exposto na Figura 16). Página 35

37 FIGURA 16 Seguidamente é feito um hash match (join), que passamos a explicar. Nesta operação aquilo que irá ocorrer é a inserção da hash de cada uma das linhas da tabela mais pequena, seguidamente será calculada a hash de cada entrada da segunda tabela e tenta-se juntar nos argumentos que identificam o tuplo. Este processo consegue ser consideravelmente rápido se uma das tabelas for substancialmente mais pequena que a outra, ou quando não há índices utilizáveis, caso contrário poderá ser bastante ineficiente comparando com outras uniões. Por outro lado o facto de se fazer hash match join poderá ser um indicativo de: Um índex incorrecto ou inexistente; Uma cláusula WHERE inexistente; Uma cláusula WHERE cujo calculo não consiga ser pesquisado, logo não utilizando nenhum índice. Caso nenhum dos parâmetros acima seja verificado é provável que este seja o melhor tipo de join para este caso (Figura 17). Uma pequena nota, neste exemplo temos que o número de linhas estimadas é de , como é óbvio isto é impossível, e consideramos também que o número de linhas realmente criadas é de 290, que não parece ser uma grande diferença, mas ao escalar poderá ser um problema. Página 36

38 FIGURA 17 De seguida temos um cluster índex seek como já foi explicado previamente (Figura 18): Página 37

39 FIGURA 18 Agora temos outro tipo de junção, o nested loop, que já mencionamos previamente (Figura 19). Página 38

40 FIGURA 19 Também conhecido como a nested iteration. Esta operação agarra no input de dois grupos de dados e une-os varrendo o outer data set para cada linha da inner set. Se o número de tuplos em cada set for pequeno, esta é uma operação extremamente eficiente. A não ser que os sets de dados sejam muito grandes, este é o tipo de join que é mais desejável encontrar no plano de execução. Por fim, temos o compute Scalar (Figura 20). Página 39

41 FIGURA 20 Esta operação permite o calculo de um valor com quaisquer argumentos que temos na tabela, neste caso é necessário para concatenar as duas strings de primeiro e último nome. Para além dos métodos de junção que já descrevemos temos também o merge join. Como um exemplo desta operação vamos ver a query (Figura 21): SELECT c.customerid FROM Sales.SalesOrderDetail od JOIN Sales.SalesOrderHeader oh ON od.salesorderid = oh.salesorderid JOIN Sales.Customer c ON oh.customerid = c.customerid FIGURA 21 Passando os scans à frente que já foram explicados anteriormente, temos então a operação merge join. Ocorre em tabelas cujas colunas a serem juntas já se encontram organizadas previamente. Caso tal pré-ordenação não se verifique, para utilizar esta ordenação podemos fazer uma de duas Página 40

42 hipóteses: ordenar as colunas antes de fazer o join, ou fazer um hash join que será menos eficiente. O query optimizer escolherá sempre o plano que necessite de menos recursos. O facto de fazer merge joins sem as colunas estarem pré-ordenadas poderá ser um indicativo da necessidade de outros índices. FIGURA 22 Agora vamos analisar a operação ORDER BY (Figura 23), para tal consideramos a seguinte query: SELECT * FROM [Production].[ProductInventory] ORDER BY [Shelf] FIGURA 23 Página 41

43 Comparando com outras operações o ORDER BY é bastante simples de entender e identificar. Como podemos ver no nosso caso temos uma operação que custa 76%, não sendo aconselhado que gaste mais de 50%, caso contrário deve ser analisado. Neste caso como não temos uma cláusula WHERE consideramos que estamos a receber mais tuplos o que os que realmente são necessários. Outros pontos a ter em conta quando é necessária a utilização desta operação são: É realmente necessária a ordenação? Será possível pré-ordenar para evitar esta ordenação, utilizando por exemplo um clustered índe? Se existirem múltiplos sorts é possível remover ou rescrever o código de forma a reduzir o seu número? FIGURA 24 Ao trocarmos a query para: SELECT * Página 42

44 FROM [Production].[ProductInventory] ORDER BY [ProductID] Veremos que no mapa das operações (Figura 25) nem existe um sort isto porque o query optimizer já reconhece que os dados já se encontram ordenados graças ao facto de estarem a ser ordenados por a chave de um clustered índex. Como outra hipótese pode-se reorganizar os dados em memória em vez de no disco. FIGURA 25 Voltando agora à hash match, é de notar que não existe só a hipótese de fazer join, veremos agora a operação de agregação (Figura 26): SELECT [City], COUNT([City]) AS CityCount FROM [Person].[Address] GROUP BY [City] FIGURA 26 Assim que é realizado o índex scan está planeado então o hash match de agregação, isto porque nos é pedido a contagem das cidades, para tal é necessário criar uma hash table temporária, como no join, de forma a contar e organizar os dados segundo a função de GROUP BY. Passamos agora a explicar os filtros, adicionando uma instância HAVING á nossa query (Figura 27): SELECT [City], COUNT([City]) AS CityCount FROM [Person].[Address] GROUP BY [City] HAVING COUNT([City]) > 1 Página 43

45 FIGURA 27 Como podemos ver a operação de filtro é colocada mais a esquerda, isto implica que será a última a ser realizada, como tal poderá não ser a forma mais eficaz de escrever a query, pois estamos a processar desde início dados que no final serão retirados. Se possível esta operação deve ser substituída por a cláusula WHERE para limitar o grupo inicial de tuplos com que vamos trabalhar. PLANOS DE EXECUÇÃO DE INSERT, UPDATE E DELETE Começando pelo insert: INSERT INTO [AdventureWorks].[Person].[Address] ( [AddressLine1], [AddressLine2], [City], [StateProvinceID], [PostalCode], [rowguid], [ModifiedDate] ) VALUES ( '1313 Mockingbird Lane', 'Basement', 'Springfield', '79', '02134', NEWID(), GETDATE() ) ; Página 44

46 FIGURA 28 Começamos a decompor este plano, de novo da direita para a esquerda. Temos então um novo operador, o constant scan, que permite a introdução de uma linha na query. Seguidamente temos um compute scalar que exprime o momento onde é feito o getidentity, é gerado um novo valor de identidade. É de notar que estas são as primeiras operações na inserção por isso é que é possível haver falhas entre os valores de identificadores, pois se ocorrer algum erro a inserção não é feita e o valor já lhe foi atribuído. É feita outra scalar para determinar o GETDATE. De seguida tudo isto é passado para a operação de cluster índex insert, onde a maioria do custo é efectuada. Efectua-se uma pesquisa no mesmo índice para ter a certeza que a integridade da chave externa se mantem. Seguidamente fazemos o nested loop join, que recebe estes dois inputs e retorna uma nova expressão que é testada pelo próximo operador, o assert. Utilizado para verificar se uma condição particular existe. Neste caso é utilizado para garantir que a informação adicionada no campo Person.Address.StateProvinceId é igual á contida na tabela Person.StateProvince. Update (Figura 29): UPDATE [Person].[Address] SET [City] = 'Munro', [ModifiedDate] = GETDATE() WHERE [City] = 'Monroe' FIGURA 29 A primeira operação a efectuar é um varrimento num non-clustered índex, que retorna todos os tuplos necessários. Não é particularmente eficiente e deve ser tomado como indicação que a tabela poderá necessitar de índices melhores para aumentar o desempenho. A utilidade deste pedido é a de identificar todas as linhas cuja cidade é Monroe. O próximo operador é o TOP, num update é utilizado para reforçar o limite do número de linhas, se tal existir. Algo que não existe neste exemplo. De seguida é aplicado um eager spool. Agarra em cada fila a ser alterada e guarda-as num objecto escondido temporário. Mais tardiamente se o operador for rewound e não for necessário rebind, a informação obtida pelo spool pode ser reutilizada, caso contrario teríamos que repetir o scan no non cluster índex. As três operações seguintes são scalar que já vimos previamente. Chegando assim ao núcleo do update o clustered índex update. Como os valores a serem actualizados fazem parte do índice este identifica-os e altera-os. Lançando por fim a confirmação do update bem sucedido. Página 45

47 Por fim o delete (Figura 30): DELETE FROM [Person].[Address] WHERE [AddressID] = 52; FIGURA 30 Demonstramos o plano de uma eliminação de um tuplo para se ter noção da complexidade desta operação, há que ter em conta que ao eliminar de uma tabela todas as que se relacionam com esta têm de ser alteradas. Começa logo com a operação de delete no cluster índex. Depois do delete são feitas uma série de seeks e scans sobre o índex clustered índex. Estas são especificamente semi junções à esquerda. Finalmente temos um operador assert que com cada valor devolvido dos joins confere se existe informação referencial. Se não existir o delete está completo. PROCESSAMENTO DE EXPRESSÕES COMPLEXAS PIPELINING É suportado e encontra-se escondido. Permite a utilização da capacidade de processamento de uma forma mais eficaz, tendo por consequência um aumento no desempenho. Mais especificamente o SSIS (SQL Server Integration Services) atribui múltiplos threads a um buffer num plano de execução, permitindo assim que múltiplos componentes sejam executados em paralelo. É possível afectar o funcionamento destes pipelines manipulando o Data Flow conseguindo assim afectar o desempenho da base de dados. Os caminhos do Data Flow normalmente constroem árvores com um número de fontes que fazem entrar os dados necessários, chegando a um único destino. Durante o run time a Data Flow engine para uma dada árvore de execução é partida em varias sub árvores baseadas nos componentes do nosso SSIS, se são row transformations, partial blocking ou blocking transformations. Cada um destes irá afectar á sua maneira o funcionamento dos threads. PARALELISMO Está disponibilizado a hipótese de fazer queries paralelas para optimizar a execução e as operações sobre índices em computadores com mais do que um CPU. Ao utilizar diversos threads do sistema operativo o SQL Server permite que cada operação seja desempenhada em menos tempo tornando assim mais eficiente a base de dados. Durante a optimização o SQL Server procura por queries ou operações sobre índices que possam beneficiar da execução paralela. O Server insere então exchange operators nestas queries para as preparar para a execução em paralelo que providencia gestão de processos, redistribuição de dados e controlo do fluxo. Página 46

48 Depois dos exchange operators estarem inseridos, o resultado é um plano de execução sobre uma query paralela. Esta poderá então ser executada em diversos threads, se aparecer uma query não paralela utiliza um único thread. O número de threads a serem utilizados é definido no plano de execução da query, sendo este número determinado por a complexidade do plano e o grau de paralelismo. O grau de paralelismo está relacionado com o número de CPUs a ser utilizados e pode ser manipulado especificando a query hint MAXDOP explicada na secção de hints. MANIPULAÇÃO DAS ESCOLHAS DO OPTIMIZADOR JOIN HINTS As join hints são especificadas no FROM. LOOP HASH MERGE Especifica o algoritmo de join que será usado: loop, hash ou merge. REMOTE Especifica que a operação de join é aplicada à tabela da direita. Isto é especialmente útil quando a tabela da direita é remota e a da esquerda é local. EXEMPLO USE AdventureWorks2008R2; GO SELECT p.name, pr.productreviewid FROM Production.Product p LEFT OUTER HASH JOIN Production.ProductReview pr ON p.productid = pr.productid ORDER BY ProductReviewID DESC; Página 47

49 QUERY HINTS { HASH ORDER } GROUP Especifica que a agregação descrita no GROUP BY, DISTINCT ou COMPUTE usam hashing ou ordering. { MERGE HASH CONCAT } UNION Especifica que todas as operações de união são executas por merge, hash ou concat. Se várias opções forem seleccionadas o optimizador usa aquela que ele acha ser mais eficiente. FAST N Especifica que a query está optimizada para as primeiras n rows. FORCE ORDER Especifica a ordem de join a usar. MAXDOP N Faz override ao grau máximo paralelismo. OPTIMIZE FOR { UNKNOWN = LITERAL_CONSTANT } [,...N ] ) Instruir ao optimizador um valor particular para variável Nome da variável a ser optimizada; UNKOWN: Especifica que o query optimizer irá usar dados estatísticos; OPTIMIZE FOR UNKNOWNliteral_constant: literal a ser atribuído à variável a ser optimizada. OPTIMIZE FOR UNKNOWN Especifica que o query optimizer irá usar dados estatísticos. PARAMETERIZATION { SIMPLE FORCED } Especifica as regras de parametrização que o optimizador aplica. RECOMPILE Instrui o optimizador a descartar o plano gerado após a execução da query para forçar uma nova criação do mesmo. ROBUST PLAN KEEP PLAN Força o optimizador a escolher um plano que maximize o número de rows. Minimiza o número de recompilações dos planos feitas pelo optimizador. KEEPFIXED PLAN Força o optimizador a não realizar recompilações dos planos. EXPAND VIEWS Especifica que as views indexadas estão expandidas e que como tal não é necessário considerar nenhuma outra view para nenhuma parte do query. Página 48

50 MAXRECURSION N Especifica que existiram no máximo n recursões permitidas para este query. USE PLAN N'XML_PLAN' Força o optimizador a usar o plano alvo. EXEMPLO USE AdventureWorks2008R2; GO SELECT * FROM Sales.Customer AS c INNER JOIN Sales.vStoreWithAddresses AS sa ON c.customerid = sa.businessentityid WHERE TerritoryID = 5 OPTION (MERGE JOIN); GO Página 49

51 TABLE HINTS NOEXPAND Especifica que as views indexadas não estão expandidas. KEEPIDENTITY Especifica que o valor identidade na informação importada é para ser usado na coluna identidade. KEEPDEFAULTS Especifica os valores defeitos para cada coluna no acto da inserção em bulk. FASTFIRSTROW Especifica que a query está optimizada para a primeira row. FORCESEEK [ (INDEX_VALUE(INDEX_COLUMN_NAME [,... N ] )) ] Especifica que o query optimizer use apenas um índex seek como ponto de acesso à informação na tabela ou view. FORCESCAN Força o optimizador a usar sempre um índex scan. HOLDLOCK/SERIALIZABLE Especifica que os shared locks são mais restritivos e duram até ao final de cada transacção. IGNORE_CONSTRAINTS Especifica que quaisquer restrições da tabela são ignoradas quando é feita uma inserção em bulk. IGNORE_TRIGGERS Especifica que quaisquer triggers da tabela são ignorados quando é feita uma inserção em bulk. NOWAIT Instrui a base de dados a devolver uma mensagem assim que encontrar um lock na tabela. READCOMMITTED Especifica que as operações de read devem respeitar o nível de isolamento read commited. READCOMMITTEDLOCK Especifica que as operações de read devem respeitar o nível de isolamento read commited por recurso a locks READPAST Especifica que o sistema não lê linhas que estejam locked por outras transacções. READUNCOMMITTED/NOLOCK Especifica que não existem locks. REPEATABLEREAD Página 50

52 Especifica que as operações de read devem respeitar o nível de isolamento repeatable read. ROWLOCK Especifica que os row locks são tomados quando os locks de página ou tabela já estão tomados. TABLOCK Especifica que os locks são ao nível da tabela. TABLOCKX Especifica que os locks são ao nível da tabela e exclusivos. UPDLOCK Especifica que os update locks mantêm-se até ao fim da transacção. XLOCK Especifica que os locks exclusivos mantêm-se até ao fim da transacção. EXEMPLO USE AdventureWorks2008R2; GO UPDATE Production.Product WITH (TABLOCK) SET ListPrice = ListPrice * 1.10 WHERE ProductNumber LIKE 'BK-%'; GO PLANOS DE EXECUÇÃO DE PERGUNTAS O SQL Server 2008 R2 Management Studio oferece ferramentas para a visualização dos detalhes de execução de queries. Podem ver um exemplo desta funcionalidade em acção na Figura 31. FIGURA 31 PLANO DE EXECUÇÃO Página 51

53 CÁLCULO DE CUSTOS O SQL Server realiza a sua optimização de processamento de queries utilizando como factor principal os custos estimados de execução de cada plano. No SQL Server 2008 R2 a seguinte informação é armazenada ao nível da própria tabela, não fazendo parte do objecto de estatísticas do sistema: Número de linhas na tabela ou índice (coluna rows em sys.sysindexes) Número de páginas ocupadas pela tabela ou pelo índice (coluna dpages em sys.sysindexes) Adicionalmente são recolhidas outras estatísticas no objecto de estatísticas, o statblob. Entre estas podemos destacar: Quando é que as estatísticas foram recolhidas O número de linhas utilizadas para produzir histogramas e informação de densidade O comprimento médio de uma chave O histograma de uma única coluna, incluindo o número de passos Um sumário de strings, se a coluna for do tipo dados de carácter. (DBCC SHOW_STATISTICS permite visualizar no seu output uma coluna chamada String Index, que tem o valor YES se o objecto de estatísticas tiver um sumário de strings. O número estimado de linhas que correspondem ao filtro 2 (para estatísticas filtradas), ou todas as linhas na tabela (para estatísticas convencionais) Com efeito, toda a informação sobre um único objecto de estatísticas é armazenada em várias colunas de uma +única linha na na tabela sysindexes, e num BLOB (Binary Large Object) dedicado a estatísticas (statblob) mantido apenas numa tabela interna. Adicionalmente, a informação sobre as estatísticas estão disponíveis nas vistas de meta-dados sys.stats e sys.indexes. HISTOGRAMAS O SQL Server suporta histogramas, sendo que um histograma é um conjunto de até 200 valores de uma dada coluna. Todos ou uma amostra de valores numa dada coluna são ordenados, a sequência ordenada é dividida em até 199 intervalos de modo a que a informação estatística mais relevante seja capturada. De um modo geral, este intervalos não são do mesmo tamanho entre si. Os valores seguintes, ou informação suficiente para os derivar, são armazenados em cada passo do histograma. Um histograma é constituído pelos elementos na Valor RANGE_HI_KEY Descrição Representa o valor superior dos passos de um histrograma. Este é um valor chave. RANGE_ROWS Específica quantas linhas estão dentro do intervalo (são mais pequenas do que este RANGE_HI_KEY, mas maiores que o anteriormente mais pequeno RANGE_HI_KEY) 2 Filtro Uma condição que é avaliada para determinar se uma linha deve ou fazer parte de estatísticas filtradas. O predicado aparece na cláusula WHERE de CREATE STATISTICS ou CREATE INDEX (no caso de estatísticas serem automaticamente criadas como consequência da criação de um índice) Página 52

54 EQ_ROWS AVG_RANGE_ROWS Específica exactamente quantas linhas são iguais a RANGE_HI_KEY Específica o número médio de linhas por valor distinto dentro do intervalo. DISTINCT_RANGE_ROWS Específica quantos valores chave distintos estão dentro deste intervalo, CRIAÇÃO DE ESTATÍSTICAS não incluindo a chave antes de RANGE_HI_KEY e o próprio RANGE_HI_KEY É possível a criação de estatísticas sobre uma tabela e colunas como no seguinte exemplo: CREATE STATISTICS FirstLast2 ON Person.Contact(FirstName,LastName) WITH SAMPLE 50 PERCENT Pode-se também definir se as estatísticas devem ou não ser criadas automaticamente com: ALTER DATABASE dbname SET AUTO_CREATE_STATISTICS OFF ALTER DATABASE dbname SET AUTO_CREATE_STATISTICS ON Para além destes commandos básicos existem outros que permitem a manutenção e actualização das estatísticas. Com base em todas as estatísticas referidas, e outras para além destas, o SQL Server é capaz de calcular os custos a utilizar na optimização de queries. EXEMPLO PRÁTICO Algumas estatísticas que podem ser consultadas a partir da base de dados de exemplo AdventureWorks exec sp_spaceused 'Sales.SalesOrderHeader' FIGURA 32 - ESPAÇO UTILIZADO POR UMA TABELA SELECT in_row_data_page_count, in_row_used_page_count, in_row_reserved_page_count FROM sys.dm_db_partition_stats p WHERE p.object_id = OBJECT_ID ('Sales.SalesOrderHeader' ) AND index_id < 2 FIGURA 33 PARTITION STATS Página 53

55 DBCC SHOW_STATISTICS( 'Sales.SalesOrderHeader', IX_SalesOrderHeader_CustomerID ) FIGURA 34 - DBCC SHOW_STATISTICS COMPARATIVO Nesta secção final do nosso trabalho iremos realizar a comparação dos resultados obtidos sobre os dois sistemas de bases de dados em estudo. Além, disso iremos também colocá-los em comparação com o Oracle Database, tal como leccionado nas aulas teóricas e laboratoriais. TABELA COMPARATIVA A forma mais fácil de compreender as diferenças entre os vários sistemas, no que diz respeito ao processamento e optimização de perguntas, é a elaboração de uma tabela comparativa. Na Tabela 8 é apresentamos várias das características e funcionalidades estudadas, agrupadas segundo o seu objectivo/tema, e seguidamente apresentamos uma coluna para cada um dos sistemas analisados. Conforme a legenda da tabela indicamos o leque de funcionalidades suportadas em cada um dos sistemas de bases de dados analisados. TABELA 8 - TABELA COMPARATIVA ENTRE MYSQL, SQL SERVER E ORACLE DATABASE Funcionalidades MySQL SQL Server Oracle Database Selecção File scan / Full table scan x x x Index scan x x x Index fast full scan 3 n/a n/a x Cluster and hash cluster access x External Sort-Merge n/s n/s n/s Join Nested-Loop Join x x x Block Nested-Loop Join x x x Indexed Nested-Loop Join x x x Merge-Join x x x Hash-Join - x x Parallelism Parallel Sort - X x Parallel Join - X x Partitioned Join - n/s n/s 3 Varrimento de toda a tabela utilizando um índice B+Tree 4 Acesso de dados utilizando uma chave cluster Página 54

PostgreSQL Performance

PostgreSQL Performance PostgreSQL Performance André Restivo Faculdade de Engenharia da Universidade do Porto February 24, 2012 André Restivo (FEUP) PostgreSQL Performance February 24, 2012 1 / 45 Sumário 1 Armazenamento 2 Índices

Leia mais

António Rocha Nuno Melo e Castro

António Rocha Nuno Melo e Castro António Rocha Nuno Melo e Castro SQL- Strutured Query Language é a linguagem mais usada nas bases dados relacionais. Originalmente desenvolvida pela IBM Actualmente é um standard, o mais recente é o SQL:2003

Leia mais

SQL Structured Query Language

SQL Structured Query Language Janai Maciel SQL Structured Query Language (Banco de Dados) Conceitos de Linguagens de Programação 2013.2 Structured Query Language ( Linguagem de Consulta Estruturada ) Conceito: É a linguagem de pesquisa

Leia mais

SQL (Structured Query Language)

SQL (Structured Query Language) (Structured Query Language) I DDL (Definição de Esquemas Relacionais)... 2 I.2 Domínios... 2 I.3 Criação de Tabelas... 2 I.4 Triggers... 4 II DML Linguagem para manipulação de dados... 5 II.2 Comando SELECT...

Leia mais

Consistem num conjunto de apontadores para instâncias especificas de cada relação.

Consistem num conjunto de apontadores para instâncias especificas de cada relação. Mecanismo usado para mais fácil e rapidamente aceder à informação existente numa base de dados. Bases de Dados de elevadas dimensões. Consistem num conjunto de apontadores para instâncias especificas de

Leia mais

UFCD 787. Administração de base de dados. Elsa Marisa S. Almeida

UFCD 787. Administração de base de dados. Elsa Marisa S. Almeida UFCD 787 Administração de base de dados Elsa Marisa S. Almeida 1 Objectivos Replicação de base de dados Gestão de transacções Cópias de segurança Importação e exportação de dados Elsa Marisa S. Almeida

Leia mais

Programação SQL. INTRODUÇÃO II parte

Programação SQL. INTRODUÇÃO II parte Programação SQL INTRODUÇÃO II parte Programação SQL SELECT; INSERT; UPDATE; DELETE. Este conjunto de comandos faz parte da sublinguagem denominada por DML Data Manipulation Language (Linguagem de manipulação

Leia mais

DISCIPLINAS DO CURSO INFORMÁTICA ÊNFASE GESTÃO DE NEGÓCIOS.

DISCIPLINAS DO CURSO INFORMÁTICA ÊNFASE GESTÃO DE NEGÓCIOS. DISCIPLINAS DO CURSO INFORMÁTICA ÊNFASE GESTÃO DE NEGÓCIOS. PROFESSOR: DOUGLAS DUARTE DISCIPLINA: LPBD 5º SEMESTRE AULA 02 MYSQL O MySQL é um sistema de gerenciamento de banco de dados (SGBD), que utiliza

Leia mais

BANCO DE DADOS II. AULA MySQL.

BANCO DE DADOS II. AULA MySQL. UNIVERSIDADE FEDERAL DE SANTA MARIA - UFSM COLÉGIO AGRÍCOLA DE FREDERICO WESTPHALEN BANCO DE DADOS II BANCO DE DADOS II AULA MySQL. DISCIPLINA: Banco de Dados II PROF.: ROMULO VANZIN Data: 27/06/2014 Banco

Leia mais

Comandos de Manipulação

Comandos de Manipulação SQL - Avançado Inserção de dados; Atualização de dados; Remoção de dados; Projeção; Seleção; Junções; Operadores: aritméticos, de comparação,de agregação e lógicos; Outros comandos relacionados. SQL SQL

Leia mais

SQL Linguagem de Manipulação de Dados. Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri

SQL Linguagem de Manipulação de Dados. Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri SQL Linguagem de Manipulação de Dados Banco de Dados SQL DML SELECT... FROM... WHERE... lista atributos de uma ou mais tabelas de acordo com alguma condição INSERT INTO... insere dados em uma tabela DELETE

Leia mais

PROGRAMA. Aquisição dos conceitos teóricos mais importantes sobre bases de dados contextualizados à luz de exemplos da sua aplicação no mundo real.

PROGRAMA. Aquisição dos conceitos teóricos mais importantes sobre bases de dados contextualizados à luz de exemplos da sua aplicação no mundo real. PROGRAMA ANO LECTIVO: 2005/2006 CURSO: LICENCIATURA BI-ETÁPICA EM INFORMÁTICA ANO: 2.º DISCIPLINA: BASE DE DADOS DOCENTE RESPONSÁVEL PELA REGÊNCIA: Licenciado Lino Oliveira Objectivos Gerais: Aquisição

Leia mais

Tarefa Orientada 12 Junção Externa, Auto-Junção e União

Tarefa Orientada 12 Junção Externa, Auto-Junção e União Tarefa Orientada 12 Junção Externa, Auto-Junção e União Objectivos: Junção externa (Outer JOIN) Junção externa à esquerda (LEFT Outer JOIN) Junção externa à direita (RIGHT Outer JOIN) Junção externa completa

Leia mais

COMPETÊNCIAS ESPECÍFICAS Compreender e utilizar a linguagem SQL, na construção e manutenção de uma base de dados.

COMPETÊNCIAS ESPECÍFICAS Compreender e utilizar a linguagem SQL, na construção e manutenção de uma base de dados. PLANIFICAÇÃO DA DISCIPLINA DE SISTEMAS DE INFORMAÇÃO 12.ºH CURSO PROFISSIONAL DE TÉCNICO MULTIMÉDIA ANO LECTIVO 2013/2014 6. LINGUAGENS DE PROGRAMAÇÃO IV Pré-requisitos: - Planificar e estruturar bases

Leia mais

SQL é uma linguagem de consulta que implementa as operações da álgebra relacional de forma bem amigável.

SQL é uma linguagem de consulta que implementa as operações da álgebra relacional de forma bem amigável. SQL (Structured Query Language) SQL é uma linguagem de consulta que implementa as operações da álgebra relacional de forma bem amigável. Além de permitir a realização de consultas, SQL possibilita: definição

Leia mais

INSTITUTO SUPERIOR TÉCNICO Administração e Optimização de Bases de Dados

INSTITUTO SUPERIOR TÉCNICO Administração e Optimização de Bases de Dados Número: Nome: 1 -------------------------------------------------------------------------------------------------------------- INSTITUTO SUPERIOR TÉCNICO Administração e Optimização de Bases de Dados Exame

Leia mais

Tarefa Orientada 14 Subconsultas

Tarefa Orientada 14 Subconsultas Tarefa Orientada 14 Subconsultas Objectivos: Subconsultas não correlacionadas Operadores ALL, SOME e ANY Subconsultas correlacionadas Operador EXISTS Subconsultas incluídas na cláusula FROM de uma consulta

Leia mais

Sumário 1 0.1 Introdução 1 0.2 Breve História da Linguagem SQL l 0.3 Características da Linguagem SQL 3 0.4 A Composição deste Livro 3

Sumário 1 0.1 Introdução 1 0.2 Breve História da Linguagem SQL l 0.3 Características da Linguagem SQL 3 0.4 A Composição deste Livro 3 ÍNDICE o -INTRODUÇÃO Sumário 1 0.1 Introdução 1 0.2 Breve História da Linguagem SQL l 0.3 Características da Linguagem SQL 3 0.4 A Composição deste Livro 3 0.5 Sistemas Utilizados 6 0.5.1 Access 2003 (Microsoft)

Leia mais

Administração e Optimização de BDs

Administração e Optimização de BDs Departamento de Engenharia Informática 2010/2011 Administração e Optimização de BDs Mini-Projecto 1 2º semestre A resolução deve ser claramente identificada com o número de grupo e entregue sob a forma

Leia mais

SQL TGD/JMB 1. Projecto de Bases de Dados. Linguagem SQL

SQL TGD/JMB 1. Projecto de Bases de Dados. Linguagem SQL SQL TGD/JMB 1 Projecto de Bases de Dados Linguagem SQL SQL TGD/JMB 2 O que é o SQL? SQL ("ess-que-el") significa Structured Query Language. É uma linguagem standard (universal) para comunicação com sistemas

Leia mais

SQL. SQL (Structured Query Language) Comando CREATE TABLE. SQL é uma linguagem de consulta que possibilita:

SQL. SQL (Structured Query Language) Comando CREATE TABLE. SQL é uma linguagem de consulta que possibilita: SQL Tópicos Especiais Modelagem de Dados Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Mestrado Profissional em Ensino de Ciências

Leia mais

APOSTILA BÁSICA DE MYSQL

APOSTILA BÁSICA DE MYSQL APOSTILA BÁSICA DE MYSQL História O MySQL foi criado na Suécia por dois suecos e um finlandês: David Axmark, Allan Larsson e Michael "Monty" Widenius, que têm trabalhado juntos desde a década de 1980.

Leia mais

Introdução à Banco de Dados. Nathalia Sautchuk Patrício

Introdução à Banco de Dados. Nathalia Sautchuk Patrício Introdução à Banco de Dados Nathalia Sautchuk Patrício Histórico Início da computação: dados guardados em arquivos de texto Problemas nesse modelo: redundância não-controlada de dados aplicações devem

Leia mais

SQL. Prof. Márcio Bueno. {bd2tarde,bd2noite}@marciobueno.com

SQL. Prof. Márcio Bueno. {bd2tarde,bd2noite}@marciobueno.com SQL Prof. Márcio Bueno {bd2tarde,bd2noite}@marciobueno.com Material dos professores Ana Carolina Salgado, Fernando Foncesa e Valéria Times (CIn/UFPE) SQL SQL - Structured Query Language Linguagem de Consulta

Leia mais

Prof. Carlos Majer Aplicações Corporativas UNICID

Prof. Carlos Majer Aplicações Corporativas UNICID Este material pertence a Carlos A. Majer, Professor da Unidade Curricular: Aplicações Corporativas da Universidade Cidade de São Paulo UNICID Licença de Uso Este trabalho está licenciado sob uma Licença

Leia mais

Principais características

Principais características .Net Framework O que é.net? Proprietário da Microsoft Versão simplificada para Linux Versão compacta para dispositivos móveis Plataforma de desenvolvimento e execução Interface com usuário, conectividade

Leia mais

SQL (Structured Querie Language) Escola Secundária de Emídio Navarro 2001/2002 Estruturas, Tratamento e Organização de Dados

SQL (Structured Querie Language) Escola Secundária de Emídio Navarro 2001/2002 Estruturas, Tratamento e Organização de Dados SQL (Structured Querie Language) SQL é mais que uma linguagem de interrogação estruturada. Inclui características para a definição da estrutura de dados, para alterar os dados de uma base de dados, e para

Leia mais

Sumário Agradecimentos... 19 Sobre.o.autor... 20 Prefácio... 21 Capítulo.1..Bem-vindo.ao.MySQL... 22

Sumário Agradecimentos... 19 Sobre.o.autor... 20 Prefácio... 21 Capítulo.1..Bem-vindo.ao.MySQL... 22 Sumário Agradecimentos... 19 Sobre o autor... 20 Prefácio... 21 Capítulo 1 Bem-vindo ao MySQL... 22 1.1 O que é o MySQL?...22 1.1.1 História do MySQL...23 1.1.2 Licença de uso...23 1.2 Utilizações recomendadas...24

Leia mais

Linguagem de Consulta Estruturada (SQL)

Linguagem de Consulta Estruturada (SQL) Linguagem de Consulta Estruturada (SQL) Conceitos sobre a versão ANSI da SQL, a sublinguagem de definição de dados (DDL) e a sublinguagem de manipulação de dados (DML) Prof. Flavio Augusto C. Correia 1

Leia mais

FEAP - Faculdade de Estudos Avançados do Pará PROFª LENA VEIGA PROJETOS DE BANCO DE DADOS UNIDADE V- SQL

FEAP - Faculdade de Estudos Avançados do Pará PROFª LENA VEIGA PROJETOS DE BANCO DE DADOS UNIDADE V- SQL Quando os Bancos de Dados Relacionais estavam sendo desenvolvidos, foram criadas linguagens destinadas à sua manipulação. O Departamento de Pesquisas da IBM desenvolveu a SQL como forma de interface para

Leia mais

Bases de Dados 2005/2006. Aula 5

Bases de Dados 2005/2006. Aula 5 Bases de Dados 2005/2006 Aula 5 Sumário -1. (T.P.C.) Indique diferenças entre uma tabela e uma relação. 0. A base de dados Projecto 1. SQL Join (variantes) a. Cross Join b. Equi-Join c. Natural Join d.

Leia mais

PROGRAMA. Objectivos Gerais :

PROGRAMA. Objectivos Gerais : PROGRAMA ANO LECTIVO : 2005/2006 CURSO : ENGENHARIA MULTIMÉDIA ANO: 2.º DISCIPLINA : SISTEMA DE GESTÃO DE BASE DE DADOS DOCENTE RESPONSÁVEL PELA REGÊNCIA : Licenciado Lino Oliveira Objectivos Gerais :

Leia mais

DESENVOLVIMENTO DE SOFTWARE

DESENVOLVIMENTO DE SOFTWARE VARIAÁ VEL Antes de iniciarmos os comandos referentes a Banco de Dados, precisamos de uma breve descrição técnica sobre Variáveis que serão uma constante em programação seja qual for sua forma de leitura.

Leia mais

Banco de Dados. Marcio de Carvalho Victorino www.dominandoti.eng.br. Exercícios SQL

Banco de Dados. Marcio de Carvalho Victorino www.dominandoti.eng.br. Exercícios SQL Banco de Dados Exercícios SQL 1 TRF (ESAF 2006) 32. Analise as seguintes afirmações relacionadas a Bancos de Dados e à linguagem SQL: I. A cláusula GROUP BY do comando SELECT é utilizada para dividir colunas

Leia mais

Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri. Banco de Dados Processamento e Otimização de Consultas

Banco de Dados Profa. Dra. Cristina Dutra de Aguiar Ciferri. Banco de Dados Processamento e Otimização de Consultas Processamento e Otimização de Consultas Banco de Dados Motivação Consulta pode ter sua resposta computada por uma variedade de métodos (geralmente) Usuário (programador) sugere uma estratégia para achar

Leia mais

SQL - Banco de Dados. Disciplina: Banco de Dados. Professor: José Antônio. José Antônio - CEFET-RN 23/09/2015

SQL - Banco de Dados. Disciplina: Banco de Dados. Professor: José Antônio. José Antônio - CEFET-RN 23/09/2015 SQL - Banco de Dados 1 Disciplina: Banco de Dados Professor: José Antônio 2 Tópicos de discussão Criando um banco de dados Incluindo, atualizando e excluindo linhas nas tabelas Pesquisa básica em tabelas

Leia mais

IF685 Gerenciamento de Dados e Informação - Prof. Robson Fidalgo 1

IF685 Gerenciamento de Dados e Informação - Prof. Robson Fidalgo 1 IF685 Gerenciamento de Dados e Informação - Prof. Robson Fidalgo 1 Banco de Dados Fundamentos de SQL Structured Query Language Aula2 Apresentado por: Robson do Nascimento Fidalgo rdnf@cin.ufpe.br IF685

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

Um objeto de estatística contém informações de distribuição de valores de uma ou mais colunas de uma tabela ou view indexada

Um objeto de estatística contém informações de distribuição de valores de uma ou mais colunas de uma tabela ou view indexada Desvendando Estatísticas do SQL Server Parte 1 Nesta série de artigos vamos dar um mergulho profundo nas Teorias Probabilísticas (mais conhecido como estatísticas) do SQL Server. Introdução Estatísticas

Leia mais

Operação de União JOIN

Operação de União JOIN Operação de União JOIN Professor Victor Sotero SGD 1 JOIN O join é uma operação de multi-tabelas Select: o nome da coluna deve ser precedido pelo nome da tabela, se mais de uma coluna na tabela especificada

Leia mais

Tarefa Orientada 20 Cursores

Tarefa Orientada 20 Cursores Tarefa Orientada 20 Cursores Objectivos: Declarar cursores Utilizar cursores Utilizar funções do sistema para trabalhar com cursores Actualizar dados através de cursores Um cursor é um objecto da base

Leia mais

Os dados no MySQL são armazenado em tabelas. Uma tabela é uma colecção de informação relacionada e consiste em colunas e linhas.

Os dados no MySQL são armazenado em tabelas. Uma tabela é uma colecção de informação relacionada e consiste em colunas e linhas. MySQL 101 Recapitulando Os dados no MySQL são armazenado em tabelas. Uma tabela é uma colecção de informação relacionada e consiste em colunas e linhas. As bases de dados são úteis quando necessitamos

Leia mais

BANCO DE DADOS Parte 4

BANCO DE DADOS Parte 4 BANCO DE DADOS Parte 4 A Linguagem SQL Introdução Desenvolvida pelo depto de pesquisa da IBM na década de 1970 (System R) Linguagem padrão de BD Relacionais; Apresenta várias padrões evolutivos: SQL86,

Leia mais

LINGUAGEM SQL. DML - Linguagem de Manipulação de Dados

LINGUAGEM SQL. DML - Linguagem de Manipulação de Dados LINGUAGEM SQL Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL, é uma linguagem de pesquisa declarativa para banco de dados relacional (base de dados relacional). Muitas das características

Leia mais

Tarefa Orientada 16 Vistas

Tarefa Orientada 16 Vistas Tarefa Orientada 16 Vistas Objectivos: Vistas só de leitura Vistas de manipulação de dados Uma vista consiste numa instrução de SELECT que é armazenada como um objecto na base de dados. Deste modo, um

Leia mais

DESENVOLVIMENTO DE SOFTWARE

DESENVOLVIMENTO DE SOFTWARE VARIAÁ VEL Antes de iniciarmos os comandos referentes a Banco de Dados, precisamos de uma breve descrição técnica sobre Variáveis que serão uma constante em programação seja qual for sua forma de leitura.

Leia mais

Tarefa Orientada 13 Agrupamento e sumário de dados

Tarefa Orientada 13 Agrupamento e sumário de dados Tarefa Orientada 13 Agrupamento e sumário de dados Objectivos: Funções de agregação Agrupamento e sumário de dados Funções de agregação Nesta tarefa orientada iremos formular consultas que sumariam os

Leia mais

ADMINISTRAÇÃO DE BANCO DE DADOS

ADMINISTRAÇÃO DE BANCO DE DADOS ADMINISTRAÇÃO DE BANCO DE DADOS ARTEFATO 02 AT02 Diversos I 1 Indice ESQUEMAS NO BANCO DE DADOS... 3 CRIANDO SCHEMA... 3 CRIANDO TABELA EM DETERMINADO ESQUEMA... 4 NOÇÕES BÁSICAS SOBRE CRIAÇÃO E MODIFICAÇÃO

Leia mais

Programação SQL. Manipulação de Dados. DML Data Manipulation Language

Programação SQL. Manipulação de Dados. DML Data Manipulation Language Programação SQL Manipulação de Dados DML Data Manipulation Language Manipulação de Dados (DML) Os comandos INSERT, UPDATE, DELETE, são normalmente classificados como pertencendo a uma sublinguagem da linguagem

Leia mais

Princípio dos anos 70 IBM desenvolve a linguagem Sequel para o System R. Standards ISO e ANSI SQL-86, SQL-89, SQL-92, SQL:1999, SQL:2003

Princípio dos anos 70 IBM desenvolve a linguagem Sequel para o System R. Standards ISO e ANSI SQL-86, SQL-89, SQL-92, SQL:1999, SQL:2003 Bases de Dados Introdução à linguagem SQL História Princípio dos anos 70 IBM desenvolve a linguagem Sequel para o System R Renomeada para SQL (Structured Query Language) Standards ISO e ANSI SQL-86, SQL-89,

Leia mais

ORACLE 11 G INTRODUÇÃO AO ORACLE, SQL,PL/SQL. Carga horária: 32 Horas

ORACLE 11 G INTRODUÇÃO AO ORACLE, SQL,PL/SQL. Carga horária: 32 Horas ORACLE 11 G INTRODUÇÃO AO ORACLE, SQL,PL/SQL Carga horária: 32 Horas Pré-requisito: Para que os alunos possam aproveitar este treinamento ao máximo, é importante que eles tenham participado dos treinamentos

Leia mais

Tarefa Orientada 15 Manipulação de dados

Tarefa Orientada 15 Manipulação de dados Tarefa Orientada 15 Manipulação de dados Objectivos: Criação de tabelas teste Comando INSERT INTO Inserção de dados Comando INSERT Actualização de dados Comando UPDATE Eliminação de dados Comando DELETE

Leia mais

Tuning para Desenvolvedores DB2

Tuning para Desenvolvedores DB2 Tuning para Desenvolvedores DB2 Perallis IT Innovation Soluções em Armazenamento de dados www.perallis.com contato@perallis.com +55 19 3203-1002 SOBRE ESTE CURSO PÚBLICO-ALVO O curso Tuning para Desenvolvedores

Leia mais

Banco de Dados Oracle 10g: Introdução à Linguagem SQL

Banco de Dados Oracle 10g: Introdução à Linguagem SQL Oracle University Entre em contato: 0800 891 6502 Banco de Dados Oracle 10g: Introdução à Linguagem SQL Duração: 5 Dias Objetivos do Curso Esta classe se aplica aos usuários do Banco de Dados Oracle8i,

Leia mais

Desenvolvendo Aplicações Web com NetBeans

Desenvolvendo Aplicações Web com NetBeans Desenvolvendo Aplicações Web com NetBeans Aula 3 Cap. 4 Trabalhando com Banco de Dados Prof.: Marcelo Ferreira Ortega Introdução O trabalho com banco de dados utilizando o NetBeans se desenvolveu ao longo

Leia mais

Junções e Índices em Tabelas

Junções e Índices em Tabelas Junções e Índices em Tabelas Prof. Fernanda Baião fernanda.baiao@uniriotec.com.br SGBD Considerados MySQL (http://www.mysql.org) SGBD gratuito e simples, sem muitos recursos avançados Fácil de instalar

Leia mais

Python Acessando o Banco de Dados MySQL

Python Acessando o Banco de Dados MySQL Python Acessando o Banco de Dados MySQL ANTONIO SÉRGIO NOGUEIRA PRESIDENTE PRUDENTE SP 2009 1 Sumário 1. Introdução...3 2. Interface MySQL...3 3.Instalando o MySQLdb...3 4.Verificando se o MySQL está instalado...4

Leia mais

Linguagem de Consulta Estruturada SQL- DML

Linguagem de Consulta Estruturada SQL- DML Linguagem de Consulta Estruturada SQL- DML INTRODUÇÃO A SQL - Structured Query Language, foi desenvolvido pela IBM em meados dos anos 70 como uma linguagem de manipulação de dados (DML - Data Manipulation

Leia mais

Gabarito - Banco de Dados SQL - 30/07/2013 AULA 01

Gabarito - Banco de Dados SQL - 30/07/2013 AULA 01 Gabarito - Banco de Dados SQL - 30/07/2013 AULA 01 1 1- Bancos de dados compreendem desde agendas telefônicas até sistemas computadorizados. (Sim) 2- Só podemos instalar o SQL Server Express se tivermos

Leia mais

DBMS%Performance% Carlos%Soares% (baseado%em%materiais%gen8lmente%cedidos% por%andré%res8vo,%joão%correia%lopes%e%do% livro%ramakrishnan%&%gehrke)% %

DBMS%Performance% Carlos%Soares% (baseado%em%materiais%gen8lmente%cedidos% por%andré%res8vo,%joão%correia%lopes%e%do% livro%ramakrishnan%&%gehrke)% % DBMS%Performance% Carlos%Soares% (baseado%em%materiais%gen8lmente%cedidos% por%andré%res8vo,%joão%correia%lopes%e%do% livro%ramakrishnan%&%gehrke)% % Plano% Contexto% Índices% Carga%da%base%de%dados%%

Leia mais

Definida pelo American National Standard Institute (ANSI) em 1986

Definida pelo American National Standard Institute (ANSI) em 1986 2.3. Linguagens Relacionais SQL Structured Query Language Linguagem para o modelo relacional: Definida pelo American National Standard Institute (ANSI) em 1986 Adoptada em 1987 como um standard internacional

Leia mais

Tarefa Orientada 19 Triggers

Tarefa Orientada 19 Triggers Tarefa Orientada 19 Triggers Objectivos: Criar triggers AFTER Criar triggers INSTEAD OF Exemplos de utilização Os triggers são um tipo especial de procedimento que são invocados, ou activados, de forma

Leia mais

Tipos de dados complexos e objectos Tipos de dados estruturados e herança em SQL Herança de tabelas Matrizes e multi-conjuntos em SQL Identidade de

Tipos de dados complexos e objectos Tipos de dados estruturados e herança em SQL Herança de tabelas Matrizes e multi-conjuntos em SQL Identidade de Capítulo 8: BDs Objecto-Relacional Tipos de dados complexos e objectos Tipos de dados estruturados e herança em SQL Herança de tabelas Matrizes e multi-conjuntos em SQL Identidade de Objectos e Referência

Leia mais

Ex.: INSERT INTO tmpautor (CDAUTOR, NMAUTOR) VALUES (1, Renato Araújo )

Ex.: INSERT INTO tmpautor (CDAUTOR, NMAUTOR) VALUES (1, Renato Araújo ) PRONATEC - Programador de Sistemas Banco de Dados 1) Incluindo linhas nas tabelas a. Para incluir linhas em tabelas utilize o comando INSERT INTO INSERT INTO tabela [ ( coluna [, coluna,...] ) ] VALUES

Leia mais

Banco de Dados. Prof. Antonio

Banco de Dados. Prof. Antonio Banco de Dados Prof. Antonio SQL - Structured Query Language O que é SQL? A linguagem SQL (Structure query Language - Linguagem de Consulta Estruturada) é a linguagem padrão ANSI (American National Standards

Leia mais

XML e Banco de Dados. Prof. Daniela Barreiro Claro DCC/IM/UFBA

XML e Banco de Dados. Prof. Daniela Barreiro Claro DCC/IM/UFBA XML e Banco de Dados DCC/IM/UFBA Banco de Dados na Web Armazenamento de dados na Web HTML muito utilizada para formatar e estruturar documentos na Web Não é adequada para especificar dados estruturados

Leia mais

Prof. Daniela Barreiro Claro

Prof. Daniela Barreiro Claro Prof. Daniela Barreiro Claro SQL, SQL3 e OQL são linguagens declarativas O SGBD deve processar e otimizar estas consultas antes delas serem efetivamente executadas Uma consulta possui muitas estratégias

Leia mais

Álgebra Relacional. Conjunto de operações que usa uma ou duas relações como entrada e gera uma relação de saída. Operações básicas:

Álgebra Relacional. Conjunto de operações que usa uma ou duas relações como entrada e gera uma relação de saída. Operações básicas: Álgebra Relacional Conjunto de operações que usa uma ou duas relações como entrada e gera uma relação de saída operação (REL 1 ) REL 2 operação (REL 1,REL 2 ) REL 3 Operações básicas: seleção projeção

Leia mais

Introdução a Informática. Prof.: Roberto Franciscatto

Introdução a Informática. Prof.: Roberto Franciscatto Introdução a Informática Prof.: Roberto Franciscatto 6.1 ARQUIVOS E REGISTROS De um modo geral os dados estão organizados em arquivos. Define-se arquivo como um conjunto de informações referentes aos elementos

Leia mais

SQL92 DDL( RIS, ACTUALIZAÇÕES E VISTAS) DML (QUERIES, SUBQUERIES,JUNÇÕES, E OPERAÇÕES SOBRE CONJUNTOS)

SQL92 DDL( RIS, ACTUALIZAÇÕES E VISTAS) DML (QUERIES, SUBQUERIES,JUNÇÕES, E OPERAÇÕES SOBRE CONJUNTOS) SQL92 DDL( RIS, ACTUALIZAÇÕES E VISTAS) DML (QUERIES, SUBQUERIES,JUNÇÕES, E OPERAÇÕES SOBRE CONJUNTOS) SQL SQL, é uma linguagem de programação que foi desenvolvida para questionar bases de dados relacionais

Leia mais

BACO BAse de Co-Ocorrências

BACO BAse de Co-Ocorrências BACO? BACO BAse de Co-Ocorrências Luís Sarmento O BACO é uma base de dados que guarda informação gerada a partir um processamento efectuado a um ou vários corpora. O objectivo: Permitir pesquisar rapidamente

Leia mais

CIÊNCIA E TECNOLOGIA DO RIO

CIÊNCIA E TECNOLOGIA DO RIO INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE BANCO DE DADOS II Docente: Éberton da Silva Marinho e-mail: ebertonsm@gmail.com eberton.marinho@ifrn.edu.br Curso de Tecnologia

Leia mais

APOSTILA BANCO DE DADOS INTRODUÇÃO A LINGUAGEM SQL

APOSTILA BANCO DE DADOS INTRODUÇÃO A LINGUAGEM SQL 1. O que é Linguagem SQL 2. Instrução CREATE 3. CONSTRAINT 4. ALTER TABLE 5. RENAME TABLE 6. TRUCANTE TABLE 7. DROP TABLE 8. DROP DATABASE 1 1. O que é Linguagem SQL 2. O SQL (Structured Query Language)

Leia mais

SQL. Introdução. Por que SQL? Setenças Select-From-Where

SQL. Introdução. Por que SQL? Setenças Select-From-Where Introdução SQL Bancos de Dados I Altigran Soares da Silva IComp/UFAM 2013/02 Adaptado do Material do Professor Jeffrey Ullman Originalmente proposta para o System R desenvolvido nos laboratórios da IBM

Leia mais

Banco de Dados. StructuredQuery Language- SQL. Prof. Walteno Martins Parreira Jr www.waltenomartins.com.br waltenomartins@yahoo.

Banco de Dados. StructuredQuery Language- SQL. Prof. Walteno Martins Parreira Jr www.waltenomartins.com.br waltenomartins@yahoo. Banco de Dados StructuredQuery Language- SQL Prof. Walteno Martins Parreira Jr www.waltenomartins.com.br waltenomartins@yahoo.com 2015 A Origem Em 1970, Ted Codd (pesquisador da IBM) publicou o primeiro

Leia mais

SQL. Structured Query Language

SQL. Structured Query Language SQL Structured Query Language Construções básicas Junção de Tabelas Join O uso da operação JOIN numa cláusula FROM especifica como se deseja que as tabelas sejam vinculadas. Use INNER JOIN para associar

Leia mais

Relatório de SBD. Ricardo Martins, nº 26013, LEI João Furtado, nº 40147, MEI João Rato, nº 41045, MEI Grupo 3

Relatório de SBD. Ricardo Martins, nº 26013, LEI João Furtado, nº 40147, MEI João Rato, nº 41045, MEI Grupo 3 Relatório de SBD Ricardo Martins, nº 26013, LEI João Furtado, nº 40147, MEI João Rato, nº 41045, MEI Grupo 3 Índice 1. INTRODUÇÃO... 4 2. ARMAZENAMENTO E FILE STRUCTURE... 5 2.1 BUFFER MANAGEMENT... 5

Leia mais

Portal AEPQ Manual do utilizador

Portal AEPQ Manual do utilizador Pedro Gonçalves Luís Vieira Portal AEPQ Manual do utilizador Setembro 2008 Engenharia Informática - Portal AEPQ Manual do utilizador - ii - Conteúdo 1 Introdução... 1 1.1 Estrutura do manual... 3 1.2 Requisitos...

Leia mais

Principais Instruções em SQL. Contidas nesta apostila as principais instruções em SQL para a manutenção em Bancos de Dados.

Principais Instruções em SQL. Contidas nesta apostila as principais instruções em SQL para a manutenção em Bancos de Dados. Principais Instruções em SQL Contidas nesta apostila as principais instruções em SQL para a manutenção em Bancos de Dados. Atenção: Esta apostila foi desenvolvida com o auxílio on-line do banco MS-ACCESS,

Leia mais

Desempenho da Base de Dados

Desempenho da Base de Dados Desempenho Parte I Base de Dados 1 Desempenho da Base de Dados O desempenho de uma base de dados pode ser optimizado e afinado, escolhendo os valores adequados dos parâmetros do SGBD usado, o desenho dos

Leia mais

Programação WEB II. PHP e Banco de Dados. progweb2@thiagomiranda.net. Thiago Miranda dos Santos Souza

Programação WEB II. PHP e Banco de Dados. progweb2@thiagomiranda.net. Thiago Miranda dos Santos Souza PHP e Banco de Dados progweb2@thiagomiranda.net Conteúdos Os materiais de aula, apostilas e outras informações estarão disponíveis em: www.thiagomiranda.net PHP e Banco de Dados É praticamente impossível

Leia mais

Histórico de revisões

Histórico de revisões Apostila 3 Histórico de revisões Data Versão Descrição Autor 30/09/2011 1.0 Criação da primeira versão HEngholmJr CONTEÚDO Exclusão de registros Consultas por Dados de Resumo Group by / Having Funções

Leia mais

Algoritmos para Processamento e Otimização de Consultas. Adriano Douglas Girardello Ana Paula Fredrich Tiago Alexandre Schulz Sippert

Algoritmos para Processamento e Otimização de Consultas. Adriano Douglas Girardello Ana Paula Fredrich Tiago Alexandre Schulz Sippert UNIOESTE Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Informática Curso de Bacharelado em Informática Algoritmos para Processamento e Otimização de Consultas

Leia mais

NOMES: Leonardo Claro Diego Lage Charles Tancredo Márcio Castro

NOMES: Leonardo Claro Diego Lage Charles Tancredo Márcio Castro NOMES: Leonardo Claro Diego Lage Charles Tancredo Márcio Castro O MySQL Cluster é versão do MySQL adaptada para um ambiente de computação distribuída, provendo alta disponibilidade e alta redundância utilizando

Leia mais

4 Conversor EDTV Raw. 4.1 Arquitetura

4 Conversor EDTV Raw. 4.1 Arquitetura 4 Conversor EDTV Raw O conversor EDTV Raw é o programa que lê um documento escrito no perfil NCL EDTV e gera um documento Raw equivalente, i.e. que define a mesma apresentação. Este capítulo, apresenta

Leia mais

Introdução ao SQL. O que é SQL?

Introdução ao SQL. O que é SQL? Introdução ao SQL 1 O que é SQL? Inicialmente chamada de Sequel, SQL (Structured Query Language), é a linguagem padrão utilizada para comunicar-se com um banco de dados relacional. A versão original foi

Leia mais

Faculdade Pitágoras 16/08/2011. Curso Superior de Tecnologia: Banco de Dados Sistemas para Internet

Faculdade Pitágoras 16/08/2011. Curso Superior de Tecnologia: Banco de Dados Sistemas para Internet Faculdade Pitágoras Curso Superior de Tecnologia: Banco de Dados Sistemas para Internet Disciplina: Banco de Dados Prof.: Fernando Hadad Zaidan SQL A linguagem SQL é responsável por garantir um bom nível

Leia mais

Faculdade Pitágoras. Curso Superior de Tecnologia: Banco de Dados. Disciplina: Banco de Dados Prof.: Fernando Hadad Zaidan SQL

Faculdade Pitágoras. Curso Superior de Tecnologia: Banco de Dados. Disciplina: Banco de Dados Prof.: Fernando Hadad Zaidan SQL Faculdade Pitágoras Curso Superior de Tecnologia: Banco de Dados Disciplina: Banco de Dados Prof.: Fernando Hadad Zaidan SQL A linguagem SQL é responsável por garantir um bom nível de independência do

Leia mais

AULA 2 INTERAÇÃO COM O BANCO DE DADOS

AULA 2 INTERAÇÃO COM O BANCO DE DADOS AULA 2 INTERAÇÃO COM O BANCO DE DADOS BANCO DE DADOS POSTGRESQL O PostgreSQL é um sistema gerenciador de banco de dados dos mais robustos e avançados do mundo. Seu código é aberto e é totalmente gratuito,

Leia mais

Aula 5. Carlos Eduardo de Carvalho Dantas (carloseduardocarvalhodantas@gmail.com)

Aula 5. Carlos Eduardo de Carvalho Dantas (carloseduardocarvalhodantas@gmail.com) Persistência com JDBC e JPA Aula 5 Carlos Eduardo de Carvalho Dantas (carloseduardocarvalhodantas@gmail.com) Quem é sábio procura aprender, mas os tolos estão satisfeitos com a sua própria ignorância..

Leia mais

Hugo Pedro Proença, 2007

Hugo Pedro Proença, 2007 Stored Procedures À medida que a complexidade dos sistemas aumenta, torna-se cada vez mais difícil a tarefa de integrar o SQL com as aplicações cliente. Além disto, é necessário que todas as aplicações

Leia mais

O que são Bancos de Dados?

O que são Bancos de Dados? SQL Básico Liojes de Oliveira Carneiro professor.liojes@gmail.com www.professor-liojes.blogspot.com O que são Bancos de Dados? É o software que armazena, organiza, controla, trata e distribui os dados

Leia mais

SQL. Banco de Dados I. Componentes de SQL

SQL. Banco de Dados I. Componentes de SQL Banco de Dados I Adrovane Marques Kade 1 1 Curso de Análise e Desenvolvimento de Sistemas Instituto Federal de Educação, Ciência e Tecnologia adrovane.kade@bento.ifrs.edu.br 2011/1 ( Structured Query Language

Leia mais

MySQL - Operações com SQL básico

MySQL - Operações com SQL básico MySQL - Operações com SQL básico Para testar se o MySQL esta instalado corretamente, execute a seguinte linha no prompt do DOS: c:\mysql\bin\mysql Se tudo estiver nos seus devidos lugares você vai receber

Leia mais

ZS Rest. Manual Avançado. Instalação em Rede. v2011

ZS Rest. Manual Avançado. Instalação em Rede. v2011 Manual Avançado Instalação em Rede v2011 1 1. Índice 2. Introdução... 2 3. Hardware... 3 b) Servidor:... 3 c) Rede:... 3 d) Pontos de Venda... 4 4. SQL Server... 5 e) Configurar porta estática:... 5 5.

Leia mais

S Q L 31/03/2010. SQL - Structured Query Language Linguagem de Consulta Estruturada

S Q L 31/03/2010. SQL - Structured Query Language Linguagem de Consulta Estruturada Gerenciamento de Dados e Informação Fernando Fonseca Ana Carolina Robson Fidalgo SQL SQL - Structured Query Language Linguagem de Consulta Estruturada Apesar do QUERY no nome, não é apenas de consulta,

Leia mais

Cursos Guia DBA Pacote Curso SQL Server 2014 e o passo a passo para otimização SQL Server 2016

Cursos Guia DBA Pacote Curso SQL Server 2014 e o passo a passo para otimização SQL Server 2016 2015 Cursos Guia DBA Pacote Curso SQL Server 2014 e o passo a passo para otimização SQL Server 2016 O pacote inclui os dois cursos mais simulados para a prova de certificação, exercícios, e-book e app

Leia mais

Introdução à Engenharia da Computação. Banco de Dados Professor Machado

Introdução à Engenharia da Computação. Banco de Dados Professor Machado Introdução à Engenharia da Computação Banco de Dados Professor Machado 1 Sistemas isolados Produção Vendas Compras Banco de Dados Produtos... Banco de Dados Produtos... Banco de Dados Produtos... Desvantagens:

Leia mais

Descrição Tinyint[(M)] Inteiro pequeno. Varia de 128 até +127

Descrição Tinyint[(M)] Inteiro pequeno. Varia de 128 até +127 Disciplina: Tópicos Especiais em TI PHP Este material foi produzido com base nos livros e documentos citados abaixo, que possuem direitos autorais sobre o conteúdo. Favor adquiri-los para dar continuidade

Leia mais

Tópicos Avançados em Banco de Dados Visão Geral de Tópicos Avançados em Banco de Dados I. Prof. Hugo Souza

Tópicos Avançados em Banco de Dados Visão Geral de Tópicos Avançados em Banco de Dados I. Prof. Hugo Souza Tópicos Avançados em Banco de Dados Visão Geral de Tópicos Avançados em Banco de Dados I Prof. Hugo Souza Iniciaremos nossos estudos sobre os tópicos avançados sobre banco de dados recapitulando o histórico

Leia mais