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

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

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

Transcrição

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

2 Índice 1. INTRODUÇÃO ARMAZENAMENTO E FILE STRUCTURE BUFFER MANAGEMENT TABLESPACE ESTRUTURA DOS REGISTOS PARTIÇÃO COMPARAÇÃO COM O ORACLE INDEXAÇÃO E HASHING ESTRUTURAS DE DADOS TIPOS DE ÍNDICE Índices clustered Índice secundário Índices FULLTEXT Natural Language Query Expansion Boolean Índices Multi-Coluna Índice Bitmap Índice Unique HASHING Índices de Hash Adaptivo Hashing dinâmico COMPARAÇÃO COM O ORACLE PROCESSAMENTO E OPTIMIZAÇÃO DE QUERIES OPTIMIZAÇÕES Optimizações Básicas Optimizações da cláusula where: Optimizações da cláusula LIMIT row_count: Optimizações da cláusula GROUP BY Optimizações da Data Manipulation Language Optimizações da operação INSERT Optimizações da operação UPDATE Optimizações da operação DELETE Optimizações de Índices Optimizações de Tabelas InnoDB Optimização Index Merge Optimização Left/Right Join Optimização (Block) Nested Loop Join PLANOS DE EXECUÇÃO DE PERGUNTAS Resultado do comando Tipos de selecções... 19

3 4.2.2 Manipulação dos Planos: Index Hints Estimativas Customização de Estatísticas COMPARAÇÃO COM O ORACLE GESTÃO DE TRANSAÇÕES E CONTROLO DE CONCORRÊNCIA NÍVEIS DE ISOLAMENTO NÍVEIS DE LOCKING PHANTOM PROBLEMS DEADLOCKS PROCESSOS DE RECUPERAÇÃO TRATAMENTOS DE ERROS NO INNODB MULTI-VERSÕES SAVEPOINTS E ROLLBACKS PARA SAVEPOINTS NESTED TRANSACTIONS CONCLUSÕES SUPORTE PARA BASES DE DADOS DISTRIBUÍDAS ARQUITECTURA DO MYSQL CLUSTER REPLICAÇÃO E FRAGMENTAÇÃO DOS DADOS TRANSPARÊNCIA DE ACESSOS LIMITAÇÕES Limites relacionados com as transações Features que faltam no MySQL Cluster Limitações dos Cluster Nodes CONCLUSÕES CONCLUSÃO BIBLIOGRAFIA... 39

4 1. Introdução O sistema que decidimos escolher foi o MySQL. Embora o MySQL seja um sistema muito interessante, é também muito complexo e extenso, pois é constituído por muitos engines, que oferecem certas features extra. Neste trabalho apenas iremos abordar o InnoDB, que é um engine que oferece todas as features necessárias para o modelo de transações e algoritmos querys. Na parte de base de dados distribuídas, iremos abordar outro engine, o MySQL Cluster, também conhecido como NDB Cluster (ou simplesmente NDB). Escolhemos focar-nos sobre o MySQL porque nos dias de hoje é dos sistemas de gestão de base de dados, open-source, mais usado no mundo. A parte mais interessante desde sistema é o facto de ser totalmente modular e de se poder adaptar a cada uma das necessidades do utilizador. Assim é possível evitar complexidades adicionais, devido a ter de suportar muitas features, que nunca são usadas. Embora isto seja algo de bom, pois torna o sistema mais leve, também tem os seus problemas, pois obriga o gestor da base de dados a usar diversos engines para fazer algo que, noutros sistemas, está assegurado nativamente. Quanto mais engines se usar, maior será o overhead das operações, pois é necessário garantir que estes troquem dados entre si. Mas, como este sistema normalmente é usado em contextos muito específicos, é possíve definir apenas um engine e mantê-lo durante toda a execução do sistema. Num contexto mais histórico, o MySQL foi desenvolvido em 1995, sendo criado por uma companhia chamada MySQL AB. Mais tarde foi adquirido pela Oracle, sendo que esta nos dias de hoje está muito ligada ao desenvolvimento de certos engines, algo que até se pode reparar na semelhança entre o sistema da Oracle e o MySQL. O MySQL é muito usado em contextos de aplicações web e tem um papel central nas implementações que usam LAMP (Linux, Apache, MySQL e PHP). Mesmo assim, com a criação de engines mais profissionais e robustos, como é o caso do NDB Cluster, é possível encontrar o MySQL hoje em projectos de grande dimensão, como a Wikipedia, Google (excluíndo as pesquisas, que usam um sistema próprio, o GFS), Facebook, Twitter, entre outros. Outra das grandes vantagens do MySQL é o seu suporte a programadores. O MySQL pode ser facilmente integrado com programas pois oferece uma vasta API para diferentes linguagens de programação. Também pode correr em diversas plataformas, desde sistemas Linux, Windows, Mac OS, a sistemas mais específicas como o Novell NetWare, OpenBSD, Solaris, entre outros. Uma das principais limitações do MySQL é o facto de não suportar todas as features do standard SQL. Essas features encontram-se espalhadas pelos diferentes engines.

5 2. Armazenamento e file structure 2.1 Buffer Management O InnoDB possui uma buffer pool para fazer cache a dados e índices em memória. Esta pool é uma variante do algoritmo LRU (least recent used) e tratada como se uma lista fosse. A lista está dividida em duas partes, uma em que temos blocos young que são os mais usados e recentes, e a outra onde temos blocos old que são, recentes, menos usados e candidatos a serem eliminados do buffer. O buffer reserva ⅜ do espaço disponível para os blocos antigos e o resto para os novos. Na inserção, se o buffer estiver cheio, o bloco menos usado é eliminado, e depois insere o novo no meio da lista. É no meio porque é o ponto onde está a cauda da lista dos mais usados e a cabeça da lista dos menos usados. Para ler um bloco, o InnoDB põe um bloco no meio para ser usado por uma query ou ser resultado de um read-ahead. No caso aceder a um bloco old, se for necessário na altura, o bloco é movido para a cabeça dos blocos mais usados, mas se for um read-ahead, pode chegar a ser excluído antes de ser usado. 2.2 Tablespace O InnoDB guarda a informação da base de dados em estruturas chamadas Tablespaces. Um tablespace é um ficheiro.ibd que tem determinada informação acerca de uma tabela, que têm uma capacidade de 16KB, que estão organizadas em extents de 1MB, e estão compostas por segmentos que são ficheiros que estão na tablespace (Dados, Data dictionary, Rollback Segment, Dois segmentos para cada índice e DoubleWrite buffer) Por definição, o InnoDB gera tablespace para cada tabela, permitindo assim uma optimização do I/O, do espaço em disco e nos backups. Isso pode ser alterado com a opção innodb_file_per_table para desactivar, ficando a informação de todas as tabelas num system tablespace e isso pode trazer problemas é difícil de gerir e ocupa muito espaço em disco. Quando um segmento aumenta, é necessário expandir para 32 páginas para garantir sequencialidade, até a um máximo de 4 vezes. Sintaxe da criação: CREATE TABLESPACE tablespace_name ADD DATAFILE 'file_name' USE LOGFILE GROUP logfile_group [EXTENT_SIZE [=] extent_size] [INITIAL_SIZE [=] initial_size] [AUTOEXTEND_SIZE [=] autoextend_size] [MAX_SIZE [=] max_size] [NODEGROUP [=] nodegroup_id] [WAIT] [COMMENT [=] comment_text] ENGINE [=] engine_name 2.3 Estrutura dos registos

6 O InnoDB, por definição, estrutura os tuplos em modo Compact, mas tem a opção Redundant para fins de compatibilidade com versões antigas do MySQL (as antigas usavam Redundant). Essa alteração pode ser feita com o atributo opcional row_format, e para consultar o formato dos tuplos, basta fazer SHOW_TABLE_STATUS. Ao usar o Compact, ganha-se espaço à custa de mais utilização CPU. Um índice tem cabeçalhos de 5 bytes (pode ter um header de tamanho variável antes), o tamanho variável é um vector de bits que conta do número de colunas NULL e que ocupa ceil(n/8) bytes. Para campos com comprimento variável, o header tem comprimento de uma coluna em 1 ou 2 bytes, e em caso de overflow ou o comprimento máximo exceder 255 bytes e o actual exceder 127 bytes, necessita de 2 bytes. Outra propriedade interessante é que caso uma tabela não tenha chaves primárias, cada registo de clustered index também terá um campo com o nome rowid com 6 bytes. Os records no InnoDB tem tamanho variável e não permite a organização de records em multitable clustering. 2.4 Partição A partição em MySQL permite que os dados de uma tabela sejam parcelados em tabelas individuais por forma a optimizar a execução. Há 4 tipos de partição: Range, List, Hash e Key. A range permite distribuir os registos pelas diferentes tabelas com base em restrições aos valores da coluna, por exemplo: PARTITION BY RANGE (person_age) ( PARTITION p0 VALUES LESS THAN (18), PARTITION p1 VALUES LESS THAN (25), PARTITION p2 VALUES LESS THAN (40) ); A list permite distribuir os registos pelas diferentes tabelas com base numa lista de valores definida. Por exemplo: PARTITION BY LIST(store_id) ( PARTITION pnorth VALUES IN (3,5,6,9,17), PARTITION peast VALUES IN (1,2,10,11,19,20), PARTITION pwest VALUES IN (4,12,13,14,18), PARTITION pcentral VALUES IN (7,8,15,16) ); A hash distribuir os registos pelas diferentes tabelas mas de uma forma mais inteligente porque as distribuições são feitas com base no reminiscente (remainder) da divisão. Há também a linear hashing que é um hash que usa um algoritmo linear de potências de 2. PARTITION BY HASH(store_id) PARTITIONS 4;

7 A Key é semelhante à hash, só que é para chaves primárias. Há também a linear key que é a Key mas usa um algoritmo linear de potências de 2. PARTITION BY KEY() PARTITIONS 4; Podemos criar partições dentro de partições, os chamados subpartições. Exemplo: CREATE TABLE ts ( id INT, purchased DATE) PARTITION BY RANGE( YEAR(purchased) ) SUBPARTITION BY HASH (TO_DAYS(purchased) ) SUBPARTITIONS 2 ( PARTITION p0 VALUES LESS THAN (1990), PARTITION p1 VALUES LESS THAN (2000), PARTITION p2 VALUES LESS THAN MAXVALUE ); 2.5 Comparação com o Oracle O Oracle e MySQL usam tablespaces, só que no Oracle as tablespaces armazenam colectivamente todos os dados do banco de dados, ao contrário do MySQL, que podemos guardar uma tablespace para cada tabela. Tanto o MySQL como o Oracle, usam a técnica de LRU nos buffers, mas as políticas de gestão são diferentes. A estrutura dos registos no Oracle é diferente da MySQL. O Oracle suporta partições tal como o MySQL, excepto partições em Key e subpartições.

8 3. Indexação e hashing A utilização de índices torna a execução da tabela mais eficiente, sem ter a necessidade de iterar um a um os tuplos e seleccionar aqueles que têm um determinado atributo. Um índice cria uma colecção dos elementos associados ao atributo a pesquisar e percorre iterando essa colecção. 3.1 Estruturas de dados O MySQL suporta B-Trees, R-Trees e Hash como estruturas de dados. As B-trees são usadas pelo InnoDB para guardar índices numa página com tamanho máximo de 16KB. Elas são preenchidas entre ½ a 15/16 da capacidade, permitindo que 1/16 possa ser usado para inserções ou actualizações que se façam aos tuplos. No caso de não se conseguir preencher a página mais do que ½, vai contrair a árvore de índice para a libertar. Opcionalmente, pode-se definir o tamanho dela usando o innodb_page_size (16k, 8k ou 4k). As R-Trees são usadas exclusivamente pelo MyISAM para Spatial Indexes. 3.2 Tipos de Índice O InnoDB suporta vários tipos de índice: clustered, secundário, hash adaptivo (falado mais à frente), FULLTEXT, multicoluna, bitmap e unique. No MySQL, para criarmos um índice, temos a seguinte sintaxe: CREATE [UNIQUE FULLTEXT SPATIAL] INDEX index_name [index_type] ON tbl_name (index_col_name,...) [index_option] index_col_name: col_name [(length)] [ASC DESC] index_type: USING {BTREE HASH} index_option: KEY_BLOCK_SIZE [=] value index_type WITH PARSER parser_name COMMENT 'string' Podemos criar um índice ao criar e/ou alterar uma tabela. CREATE TABLE actores( id_actor int not null auto_increment, nome varchar(35) not null, index using HASH (id_actor)

9 ) engine=innodb; Índices clustered Qualquer tabela InnoDB tem um índice clustered onde são guardados os dados dos tuplos. Quando definimos uma primary key na tabela, o InnoDB usa essa key como um clustered index. Para o caso de não ser definido uma chave primária, o MySQL procura o índice UNIQUE desde que as colunas tenham NOT NULL e que o InnoDB use-o como clustered index. Em último caso, o InnoDB gera um clustered index oculta numa coluna que guarda os ID s desse tuplos. Aceder a um tuplo a partir do índice clustered é rápido porque o index search reencaminha directamente para a página com todos os dados do tuplo Índice secundário Outros índices que não sejam o índice clustered, são índices secundários. Cada tuplo de um índice secundário contém as colunas da chave primária do tuplo, como também as colunas especificadas para o índice secundário. Neste caso, usa a chave primária para encontrar o tuplo no índice clustered. Recomenda-se a utilização de chaves primárias pequenas Índices FULLTEXT Os FULLTEXT indexes servem para o InnoDB processar queries que pesquise determinado valor numa determinada coluna que tanto pode ser VAR, CHAR ou TEXT. Elas podem ser criadas usando o FULLTEXT no CREATE INDEX. Por exemplo: CREATE TABLE articles ( id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY, title VARCHAR(200), body TEXT, FULLTEXT (title,body) ) ENGINE=InnoDB; Para pesquisas com o SELECT, usamos: MATCH (col1,col2,...) AGAINST (expr[search_modifier]) search_modifier: { IN NATURAL LANGUAGE MODE IN NATURAL LANGUAGE MODE WITH QUERY EXPANSION IN BOOLEAN MODE WITH QUERY EXPANSION } Podemos então ver que existem vários tipos de search_modifier. Um exemplo em que temos a tabela articles com os seguintes tuplos:

10 id title body 1 MySQL Tutorial DBMS stands for DataBase... 2 How To Use MySQL Well After you went through a... 3 Optimizing MySQL In this tutorial we will show MySQL Tricks 1. Never run mysqld as root MySQL vs. YourSQL In the following database comparison... 6 MySQL Security When configured properly, MySQL Natural Language Independentemente do tamanho das letras, efectua a procura da forma natural, ou seja, procura tuplos em que apareça no body a palavra pretendida. Por exemplo: SELECT * FROM articles WHERE MATCH (title,body) AGAINST ('database' IN NATURAL LANGUAGE MODE); Iremos ter: id title body 1 MySQL Tutorial DBMS stands for DataBase... 5 MySQL vs. YourSQL In the following database comparison Query Expansion Usado para o caso das pesquisas serem com termos pequenos. São feitas duas pesquisas para um dado atributo de procura. O atributo de procura da segunda pesquisa é a concatenação dos resultados da primeira pesquisa para dado atributo com alguns dos tuplos relevantes da primeira pesquisa. Por exemplo: SELECT * FROM articles WHERE MATCH (title,body) AGAINST ('database' WITH QUERY EXPANSION); Teremos:

11 id title body 5 MySQL vs. YourSQL In the following database comparison... 1 MySQL Tutorial DBMS stands for DataBase... 3 Optimizing MySQL In this tutorial we will show... 6 MySQL Security When configured properly, MySQL... 2 How To Use MySQL Well After you went through a MySQL Tricks 1. Never run mysqld as root A primeira pesquisa retornou os dois primeiros tuplos associados à palavra database. Sabendo que existe a palavra MySQL em title presente nos dois tuplos, é efectuada uma segunda pesquisa à tabela com essa palavra. No fim, o resultado é a concatenação. Query Expansion também funciona em conjunto com o Natural Language, bastando usar IN NATURAL LANGUAGE MODE WITH QUERY EXPANSION Boolean Podemos limitar uma procura, impondo para cada atributo um caracter que seja interpretado como um valor booleano. O + representa um atributo a estar contido na pesquisa, o - representa um atributo a ser descartado da pesquisa. Por exemplo: SELECT * FROM articles WHERE MATCH (title,body) AGAINST ('+MySQL -YourSQL' IN BOOLEAN MODE); Esta query devolve os tuplos que contenham MySQL, mas não o YourSQL. id title body 1 MySQL Tutorial DBMS stands for DataBase... 2 How To Use MySQL Well After you went through a... 3 Optimizing MySQL In this tutorial we will show MySQL Tricks 1. Never run mysqld as root MySQL Security When configured properly, MySQL Índices Multi-Coluna

12 É possível criar índices multi-coluna para perguntas que obriguem a que seja necessário percorrer mais do que uma coluna. Para que ela seja mais rápida, basta indicar a ordem correcta das colunas no índice. Vamos supor que temos: CREATE TABLE test ( id INT NOT NULL, last_name CHAR(30) NOT NULL, first_name CHAR(30) NOT NULL, PRIMARY KEY (id), INDEX name (last_name,first_name) ); O name é um índice formado pelo last_name e first_name. Para aproveitar assim a boa utilização do índice, podemos fazer lookups em querys como por exemplo: SELECT * FROM test WHERE last_name='widenius'; SELECT * FROM test WHERE last_name='widenius' AND first_name='michael'; Porque para o ultimo caso, procura pelo last_name no índice, se encontrar depois procura pelo first_name, o que está de acordo com a ordem das colunas do índice definido. Mas atenção que o contrário: SELECT * FROM test WHERE first_name='michael'; SELECT * FROM test WHERE last_name='widenius' OR first_name='michael'; No primeiro caso requer uma pesquisa pelo first_name, o que obriga a que o índice não seja utilizado Índice Bitmap Infelizmente, o MySQL não suporta índices Bitmap, mas existe algo semelhante (index_merge) que através de uma query, vai buscar tuplos que respeitem cada condição imposta, e no fim são juntos para formar o resultado Índice Unique Um índice UNIQUE cria uma condição tal que todos os valores no índice sejam distintos entre si. Se se adicionar um tuplo novo com uma chave existente noutro tuplo, dá erro. Para o caso do InnoDB, um índice UNIQUE permite adicionar múltiplos NULL em colunas que possam conter NULL. 3.3 Hashing O InnoDB suporta Hashing. Já foi visto que é utilizado nas partições, para permitir que a distribuição dos dados da tabela seja equilibrada de acordo com o número de partições.

13 É possível fazer hashing a mais do que um atributo, mas torna o processamento de queries mais lento. Uma hash index é construída sobre um índice secundário existente no InnoDB, que é organizado com uma estrutura B-Tree. E ela pode ser parcial, que o índice B-Tree não necessita de ser armazenada na buffer pool Índices de Hash Adaptivo O Adaptive hash index (índice de hash adaptivo) é uma optimização do InnoDB que aumenta performance nos lookups com = e IN, construindo uma hash index em memória. Essa funcionalidade é controlada pelo comando innodb_adaptive_hash_index e traz vantagens para alguns workloads porque a memória usada pela hash index é reservada para a buffer pool. Para desactivar, --skip-innodb_adaptive_hash_index no startup do servidor Hashing dinâmico Suporta hashing dinâmico para melhor gestão da Heap que é guardada em memória. As tabelas heaps são rápidas, mas voláteis (em caso de crash). Por default no MySQL, está activo, mas pode ser desactivado com --disable-autorehash. 3.4 Comparação com o Oracle O Oracle suporta os seguintes índices: Bitmap (enquanto que o MySQL na realidade simula isso com o index_merge). Unique. Multi-column index. De fora, fica indexação FULLTEXT. O Oracle não suporta Hash por trazerem desvantagens, logo não suporta também Hashing dinâmico, nem índice adaptivo de hashing.

14 4. Processamento e optimização de queries 4.1. Optimizações Optimizações Básicas Optimizações da cláusula where: Remoção de parêntesis desnecessários: Por exemplo: ((a AND b) AND c OR (((a AND b) AND (c AND d)))) fica (a AND b AND c) OR (a AND b AND c AND d) Substituição de atributos por constantes, se definidas na cláusula: Por exemplo: (a < b AND b = c) AND a = 5 fica 5 < b AND b=c AND a=5 Remoção de condições constantes (para auxiliar o ponto anterior) Por exemplo: (b >= 5 AND b=5) OR (b=6 AND 5=5) OR (b=7 AND 5=6) fica b = 5 OR b = 6 Expressões constantes utilizadas por índices são avaliadas uma única vez Algumas expressões constantes inválidas são detectadas pelo MySQL, e selects que incluam tais condições não retornam uma única linha, imediatamente. Por exemplo: select * from t where 2+2=5 é detectado imediatamente como IMPOSSIBLE WHERE. Se não houver GROUP BY ou funções de agregação, a cláusula HAVING é juntada com a cláusula WHERE JOIN é simplesmente implementado no WHERE, com condições adicionais As tabelas constantes são as primeiras a ser lidas. Tabelas constantes são: Tabelas vazias ou com apenas um tuplo; Tabelas que são utilizadas em WHERE de maneira em que haja um índice UNIQUE ou PRIMARY KEY, em que todas as partes desse índice são comparados com expressões constantes e definidos como NOT NULL. Por exemplo: select * from t where t.primary_key=1; select * from t1,t2 where t1.primary_key=1 and t2.primary_key=t1.id; O optimizador utiliza o melhor índice das tabelas a juntar, a menos que considere que existe uma maneira mais eficiente de fazer a junção. A melhor ordem de junção de tabelas é encontrada experimentando todas as possibilidades. No entanto, se todas as colunas no ORDER BY ou GROUP BY vierem da mesma tabela, essa tabela é preferível como sendo a primeira da junção Optimizações da cláusula LIMIT row_count:

15 Se o número de tuplos a seleccionar for pequeno, então o MySQL utiliza índices em vez de full table scans; Se se utilizar a cláusula LIMIT com ORDER BY, o MySQL termina a ordenação assim que tiver as row_count primeiras linhas do resultado. Se a ordenação for feita utilizando um índice, a operação é muito rápida. Caso contrário, terá que ser feitoa uma ordenação posterior: nesse caso, executa-se a query e ordenam-se todos ou quase todos os tuplos do resultado, até se encontrarem os primeiros row_count items. A partir desse momento, o MySQL aborta a execução da query e devolve o resultado. Ao utilizar a cláusula LIMIT em conjunto com DISTINCT, o MySQL pára assim que encontra os primeiros row_count tuplos do resultado (uma vez que o DISTINCT leva a uma ordenação do resultado). Em alguns casos, o GROUP BY pode ser resolvido ao ler a chave de ordenação por ordem (ou fazendo uma ordenação pela chave) e calculando sumários da informação até que o valor da chave mude. Neste caso, LIMIT row_count não calcula valores desnecessários do GROUP BY. LIMIT 0 retorna o conjunto vazio imediatamente. Assim que o servidor tenha enviado row_count tuplos ao cliente, aborta a menos que se esteja a utilizar SQL_CALC_FOUND_ROWS. Quando o servidor utiliza tabelas temporárias para resolver a pergunta, utiliza a cláusula LIMIT row_count para calcular quanto espaço será necessário. O optimizador lida com queries do tipo SELECT col1, FROM single_table ORDER BY non_indexed_column [DESC] LIMIT [M,]N; de uma maneira mais eficiente, utilizando um buffer com tamanho igual a sort_buffer_size. Se os elementos a serem ordenados para lim tuplo~s são pequenos o suficiente para caber no sort buffer (M+N tuplos), o servidor pode fazer a ordenação em memória, utilizando o sort buffer como uma fila de prioridades. Percorre a tabela, inserindo ordenadamente na fila as colunas de cada linha seleccionada. Se a fila estiver cheia, retira-se a última linha da fila. Retorna-se as N primeiras linhas da fila. Se M foi especificado, saltam-se as M primeiras linhas e retornam-se as N linhas subsequentes Optimizações da cláusula GROUP BY Há dois algoritmos utilizados para a implementação do GROUP BY: Loose Index Scan: índice (B-Tree ou outro) utilizado directamente para devolver os grupos de colunas. É possível fazer isto devido à ordenação das chaves em certas estruturas de indexação, como a referida acima. Estas propriedades permitem que se visualizem grupos de índices sem ter que satisfazer as condições de todas as chaves na cláusula WHERE. Quando a cláusula WHERE não existe, o algoritmo lê os grupos de chaves que são necessários. No entanto, há restrições para se aplicar este algoritmo: A query tem de ser feita sobre uma só tabela; Os nomes das colunas na cláusula devem formar um prefixo do índice;

16 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 que ser um índice e usado na cláusula GROUP BY; Para as colunas que formam um índice, o valor da coluna tem que ser indexado totalmente. Tight Index Scan: Quando o algoritmo anterior não é possível de aplicar, é possível optimizar através de índices e evitar as tabelas temporárias. Este algoritmo pode ser feito através de Range Index Scan ou Full Index Scan. Normalmente aplica-se o Tight Index Scan quando se tem que ler todas as chaves que satisfazem as condições na cláusula WHERE ou quando se faz uma leitura sobre todos os índices da cláusula WHERE. Depois de aplicar o algoritmo, é executada a cláusula GROUP BY, mas com as chaves que satisfazem as condições. Para se utilizar este algoritmo, deve 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 de agrupamento. Caso se necessite de ordenação dentro do agrupamento, o MySQL evita fazê-lo utilizando os prefixos dos índices que devolvem logo as chaves ordenadas Optimizações da Data Manipulation Language Optimizações da operação INSERT O modo como se inserem dados no MYSQL pode ter um impacto bastante forte na performance. Assim, podem ser feitas várias optimizações a esse nível: Em vez de fazer vários INSERTs, é mais eficiente fazer um único INSERT que insira directamente todos os valores; Quando se está a ler uma tabela a partir de um ficheiro de texto, é bastante mais eficiente usar o comando LOAD DATA INFILE; Apenas se insere o valor de um campo quando difere do valor por omissão, pois o MySQL perderia tempo no parsing dessse valor Optimizações da operação UPDATE Exactamente as mesmas do INSERT, só que com o overhead adicional da escrita Optimizações da operação DELETE O tempo necessário para eliminar uma row é directamente proporcional ao número de índices existentes (pois terá de ser feita uma remoção por cada índice que referencie a tabela). Para eliminar rows mais rapidamente pode-se aumentar a cache das chaves Optimizações de Índices A(s) chaves primárias de uma tabela deve(m) ser a(s) coluna(s) utilizadas nas queries vitais e, portanto, deverão ser NOT NULL. Assim, será criado um índice associado, aumentando bastante a performance. Se uma tabela tiver várias colunas, e existem queries para diversas combinações de colunas, então é preferível mover as colunas menos usadas para novas pequenas tabelas, relacionadas

17 com a principal, de modo a que cada tabela tenha índices para aumentar a eficiência das pesquisas Optimizações de Tabelas InnoDB Quando o tamanho de uma tabela cresce bastante, dever-se-á usar o comando OPTIMIZE TABLE, para reogranizar e compactar o espaço da tabela. Ter PRIMARY KEY desperdiça imenso espaço em disco. É preferível ter um campo com AUTO INCREMENT. No entanto, as tabelas InnoDB têm todas chaves primárias atribuídas, portanto é necessário seleccionar as chaves primárias mais eficientes; Usar VARCHAR em vez de CHAR para guardar strings de tamanho variável, pois é mais eficiente. Deve-se declarar as colunas como NOT NULL, se possível, porque remove o overhead de verificar se cada valor é NULL ou não. É útil para a declaração de índices sobre essas colunas. Se existirem queries usadas com frequência em tabelas que não são actualizadas frequentemente, convém activar a query cache Optimização Index Merge Utilizado para queries que envolvam vários range scans, em que junta index scans de vários índices. Esta junção de resultados pode produzir uniões e intersecções de conjuntos de resultados. Index Merge Intersection Access: algoritmo utilizado quando a cláusula WHERE foi convertida em várias condições de intervalo com AND, que respeitem uma das seguintes condições: Todos os índices estão igualados a uma constante e todos estão separados por AND; Qualquer condição de intervalo de uma primary key de uma tabela INNODB Index Merge Union Access: exactamente igual ao anterior, excepto na operação apresentada no WHERE, que é OR em vez de AND. Index Merge Sort-Union Access: utilizado quando a cláusula WHERE é convertida em condições de intervalo utilizando combinações de OR, mas em que não é possível utilizar o algoritmo Index Merge Union Access Optimização Left/Right Join A LEFT JOIN B: Para se aplicar esta optimização, sabe-se que: a tabela B está dependente de A e de 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 o modo de recolher as rows da tabela B; Todas as optimizações de junção standard são feitas, excepto que uma tabela é só lida depois de todas aquelas de que depende. (se houver uma dependência circular, é lançado um erro) As optimizações de WHERE normais são efectuadas.

18 Se há uma row em A que satisfaça a condição de junção mas não haja nenhuma row em B que satisfaça a condição de junção, é gerada uma row B extra cujas colunas estão todas a NULL. Se for utilizado o LEFT JOIN para procurar registos que não existam em nenhuma tabela, e na cláusula WHERE se tem col_name IS NULL, em que uma coluna está difinida 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. A RIGHT JOIN B: Análogo ao anterior, só que com os papéis das tabelas invertidos Optimização (Block) Nested Loop Join Os algoritmos são os mesmos que foram dados nas aulas teóricas. Para o BLOCK NESTED LOOP, existe um buffer alocado para cada junção, que tem tamanho igual a join_buffer_size, que é uma variável de sistema. Um buffer nunca é alocado na primeira tabela. Numa determinada junção, nem todos os registos são guardados no buffer: só aqueles que obedecem à condição de junção Planos de Execução de Perguntas O MySQL permite que se consulte o plano de execução de uma determinada query através do comando EXPLAIN. Na sua essência, o comando para tal é: EXPLAIN [EXTENDED] <query> Resultado do comando O comando devolve uma linha por cada comando executado na cláusula SELECT, e as suas colunas incluem: id: identificador do select; select_type: tipo do select que está a ser efectuado; table: nome da tabela a que corresponde a linha do EXPLAIN; partitions: as partições correspondentes à tabela em questão (se esta estier particionada); type: o tipo da junção possible_keys: qual o índice que o MySQL pode escolher para encontrar s registos da tabela. Pode ser null, se não houver índices relevantes para a selecção; key: o índice que foi efectivamente escolhido para a selecção; key_len: o tamanho da chave escolhida; ref: as colunas comparadas com o índice; rows: estimativa do número de linhas a examinar; filtered: estimativa do número de linhas filtradas pela condição de selecção (esta coluna é apenas devolvida se se utilizar a keyword EXTENDED); extra: contém informação adicional sobre o modo de processamento da query Listemos então os valores possíveis de select_type, como exemplo.

19 Tipos de selecções SIMPLE: não usa UNION nem subqueries PRIMARY: SELECT mais exterior UNION: segundo SELECT, ou posterior, de uma UNION DEPENDENT UNION: segundo SELECT, ou posterior, de uma UNION dependente de uma query exterior UNION RESULT: resultado de uma UNION SUBQUERY: Primeiro SELECT de uma subquery. DEPENDENT SUBQUERY: Primeiro SELECT numa subquery, que depende de uma outer query. DERIVED: Tabela derivada de SELECT (subquery numa cláusula FROM) MATERIALIZED: Subquery materializada. UNCACHEABLE SUBQUERY: Uma subquery cujo resultado não pode ser armazenado em cache e tem que ser reavaliado para cada linha da outer query. UNCACHEABLE UNION: Segundo select, ou posterior, de uma UNION que pertence a uma subquery que não pode ser guardada em cache. Para as colunas type e extra, existe mais uma série de valores possíveis, mas não serão listados de maneira exaustiva como tem sido feito até aqui. A coluna type indica qual foi a forma de processamento da junção. Por exemplo, pode aparecer informação a dizer que seria utilizado um índice fulltext, ou uma optimização index merge, ou até que seria verificada a árvore de índices. A coluna extra é interessante porque revela detalhes específicos sobre as optimizações. Por exemplo, é aí que se verifica que o MySQL detecta cláusulas WHERE e HAVING insatisfazíveis (isto é, que não seleccionam nenhum registo), através de valores como IMPOSSIBLE WHERE, IMPOSSIBLE HAVING. USING INDEX, entre outros. Apresenta-se abaixo um exemplo, com a base de dados Mondial. Observa-se que se utiliza um simples select, e que o analisador da query percebe que a query devolve o conjunto vazio (aparecendo tal dedução no campo Extra), dado que a condição da query é sempre falsa. Este primeiro exemplo foi feito utilizando a base de dados Mondial.

20 Fig.4.1 Repare-se que no Extra seleccionado, na figura abaixo, há vários algoritmos que estão a ser listados, nomeadamente o facto de se utilizar o where para limitar o conjunto de resultados, e o facto de estar a ser usado o algoritmo Block Nested Loop. Fig Manipulação dos Planos: Index Hints O MySQL suporta hints de optimização, mas apenas ao nível da selecção dos índices. A sintaxe utilizada para tal é: tbl_name [[AS] alias] [index_hint_list]

21 index_hint_list: index_hint [, index_hint] index_hint: {USE IGNORE FORCE} {INDEX KEY}[{FOR {JOIN ORDER BY GROUP BY }}] index_list: index_name [, index_name] USE INDEX indica ao MySQL para utilizar um determinado índice. IGNORE INDEX impede a utilização de um ou mais índices. FORCE INDEX obriga a considerar que um table-scan é muito dispendioso, e só deverá ser utilizado se não houver maneira absolutamente nenhuma de executar a query utilizando os índices fornecidos. A cláusula FOR permite definir o âmbito em que a hint deve ser aplicada. FOR JOIN afecta a utilização de índices nas junções, FOR ORDER BY afecta a utiização de índices nos ORDER BY e FOR GROUP BY faz o mesmo nas operações de agregação. Se não for especificado um FOR, a hint aplicar-se-á a qualquer um dos casos. Para referir o índice associado à chave primária da tabela, utiliza-se o nome PRIMARY. Como se pode ver na porção de gramática apresentada acima, é possível ter várias hints para uma mesma query. No entanto, não se pode usar FORCE INDEX e USE INDEX para a mesma tabela, levantando um erro no MySQL (uma vez que as hints entram em conflito), como neste exemplo: SELECT * FROM t1 USE INDEX FOR JOIN (i1) FORCE INDEX FOR JOIN (i2); Para as cláusulas USE INDEX e IGNORE INDEX, o USE INDEX é aplicado primeiro, e depois é aplicado o IGNORE INDEX sobre o resultado. Note-se que, apesar de ser possível colocar hints em comandos UPDATE, estas não têm qualquer efeito. É possível especificar vários índices na mesma query, e o mesmo índice em várias hints. Por exemplo, SELECT * FROM t1 USE INDEX (i1) IGNORE INDEX FOR ORDER BY (i2) ORDER BY a; SELECT * FROM t1 USE INDEX (i1) USE INDEX (i1,i1); Estimativas Para aproximar o custo de execução de uma query, normalmente considera-se que o número de seeks a disco é o factor crucial. Em tabelas pequenas é possível encontrar um registo com apenas um seek, pois o registo tem elevada probabilidade de estar em cache. No entanto, em tabelas maiores, é possível que haja mais disk seeks, e para tal

22 é possível estimar o número de acessos, assumindo que se está a utilizar índices de árvore B+, usando a fórmula log nro s n seeks log 2 indexblocklength indexlength datapointerlength O InnoDB-MySQL usa blocos para índices com 1024 bytes e data pointers de 4 bytes. Há apenas um decréscimo na performance da query quando os dados começam a ser demasiado grandes para ficar em cache, quer no sistema operativo ou no MySQL, dando origem a um número elevado de seeks. Para controlar este problema, é possível afectar uma variável, innodb_buffer_pool_size, que controla o tamanho máximo que é permitido guardar em cache. Alguns dos valores utilizados na fórmula podem ser calculados directamente sem percorrer as tabelas, uma vez que existe uma tabela de sistema, information_schema.statistics, que contém uma série de informações relativas a todas as bases de dados existentes no sistema. Essa tabela está aqui apresentada em baixo, e possui vários campos. Esta tabela contém alguns campos, como o esquema da base de dados, o nome da tabela e os índices associados. Inclui também a cardinalidade das tabelas, como se verá:

23 De acordo com a tabela apresentada, a tabela borders tem cardinalidade 320, ou seja, 320 tuplos. Se efectuarmos a operação select count(*) from borders... o resultado também é 320. Na tabela em questão (mondial.borders), não tinham sido efectuadas alterações e, por isso, a estimativa da base de dados é exactamente igual ao número de tuplos existentes na tabela. No entanto, se tal não fosse o caso, seria

24 possível recalcular as estatísticas da tabela usando ANALYZE TABLE <table-name> (neste caso, borders). É possível também calcular as estatísticas com o comando SHOW TABLE STATUS. Note-se a quantidade de estatísticas relevantes que guarda.: o Engine em que está guardada a tabela, o número de rows, o tamanho médio de cada row, o comprimento dos dados, entre outros. É possível também ver o checksum, data de criação, actualização e verificação da tabela Customização de Estatísticas O MySQL não permite controlar directamente o modo como calcula as estatísticas. A única forma que se tem para afectar as estatísticas é alterando um parâmetro, o número de sample pages utilizado para estimar a cardinalidade de um índice : esse parâmetro tem valor por omissão 8. O aumento deste valor pode diminuir a performance do optimizador, mas aumentar a sua precisão, enquanto que a sua diminuição provoca o efeito inverso Comparação com o Oracle No que toca aos algoritmos que são realmente implementados para o processamento de perguntas, e suas optimizações, o MySQL parece ser mais limitado do que o Oracle. Enquanto que o SGBD Oracle implementa variados tipos de junções, incluindo Merge e Hash, o MySQL implementa basicamente o Block Nested Loop Join que, apesar de funcionar para qualquer query, pode ser mais ineficiente nalguns casos. Para além disso, no entanto, implementa também uma estratégia de semi-join, para utilização em queries distribuídas. É possível também utilizar materialização de (sub)queries.

25 Os algoritmos de selecção são essencialmente os mesmos, como o Full Table Scan e o Index Scan. No entanto, o Oracle implementa um Index Fast Full Scan, que não é implementado pelo MySQL. Quanto às hints de selecção, o MySQL apenas permite especificar os índices a utilizar, enquanto que no Oracle é permitido escolher inclusive os algoritmos a utilizar para executar a query. Note-se que não foi possível determinar se o MySQL implementa algum algoritmo de processamento paralelo de queries, como o fragment-and-replicate ou o parallel sort.

26 5. Gestão de transações e controlo de concorrência Uma transação consiste num conjunto de operações que podem ser executadas de forma atómica, ou seja, como se fossem uma só. Se alguma dessas operações falhar, então toda a transação irá falhar. Com este modelo de transações é possível implementar algumas das propriedades ACID num SGBD. No MySQL, as transações começam com BEGIN WORK e terminam ou com COMMIT ou ROLLBACK, caso tenha sucesso ou não. O MySQL suporta tanto transações locais como transações distribuídas através do uso de XA Transactions. De notar que o suporte a transações no MySQL só é feito em tabelas de InnoDB, que é um storage engine para o MySQL. Como este sistema foi adquirido pela Oracle (se bem que é distribuído via GPL), é normal que muitas das operações de controlo de transações sejam semelhantes às usadas no Oracle. Tal como no Oracle, para se testar as transações com algum controlo é necessário desactivar o AUTOCOMMIT, que faz commit após cada operação Níveis de isolamento Em ambientes com muita concorrência torna-se difícil de manter o isolamento (que corresponde a uma propriedade ACID, que permite que transações executem sem que se aprecebam que estão a partilhar a base de dados com outras transações), pois pode levar a deadlocks. Isto ocorre porque as transações competem entre si para executarem e os recursos a que acedem têm de ser trancados, usando locks. Assim, de forma a oferecer uma melhor performance, o MySQL oferece alguns níveis de isolamento, oferecendo assim um trade-off entre correcção dos dados e rapidez. Esses níveis são: Serializable Repeatable Read Read Committed Read Uncommitted Estes níveis funcionam como os que foram estudados ao longo do semestre. No nível de serializable todas as transações são isoladas, pois são executadas de uma forma serializada, ou seja, uma depois da outra. Este nível não tem concorrência. No nível de repeatable read permite que as leituras leiam sempre o mesmo valor. Ou seja, não podem ler dados que foram modificados e ainda não foram committed. Uma transação que leia um valor irá ler sempre esse valor até terminar. No nível read committed, a transacção só irá ler valores committed. Isto é feito através de locks de escrita e leitura, no qual os leitores esperam que o escritor acabe, de forma a poderem ler os dados. Previne dirty reads. No nível read uncommitted as transações

27 podem ler qualquer valor, mesmo que este não seja committed. É o nível mais fraco de isolamento, pois não garante nada. O nível por defeito estabelecido pelo MySQL é o de repeatable read. A variável tx_isolation é uma variável do servidor onde está guardado o nível de isolamento. Este nível pode ser mudado, bastando fazer: A instrução SET TRANSACTION ISOLATION LEVEL <nível> faz exactamente o mesmo que a instrução em Oracle, sendo a instrução a mesma Níveis de locking O InnoDB suporta o modelo standard de row level locking, ou seja quando se pretende aceder a um recurso, em vez de fazer lock à tabela toda. Este esquema suporta mais concorrência que o modelo de lock à tabela porque múltiplas transações podem estar a fazer operações simultâneas na mesma tabela, desde que sejam em rows diferentes. Para aumentar ainda mais a concorrência foi criado para o InnoDB dois tipos de locks diferentes: locks de leitura, chamados de shared locks e locks de escrita, chamados exclusive locks. Estes locks funcionam da mesma maneira que os do standard, que foram estudados ao longo do semestre. Quando uma transação necessita de um lock, seja ele de escrita ou de leitura, se já existir uma transação com esse lock, então a transação que pede o lock espera. Outro modelo suportado pelo InnoDB é o modelo de múltipla granularidade. Este modelo corresponde ao que foi estudado durante ao semestre e ao que é definido no standard. Ou seja, existem 4 tipos de locks: intention shared, intention exclusive, shared e exclusive. Os recursos estão organizados numa árvore e cada transação começa por fazer intention lock na raiz, do tipo que pretende. Quando chega ao recurso faz shared ou exclusive lock. Ao usar intentions é possível uma transação detectar logo na raiz se o recurso que pretende está ou não a ser usado, podendo abortar mais cedo, caso seja necessário. As intentions e o shared lock permitem concorrência. O único que causa bloqueios (e potencialmente deadlocks) é o exclusive lock. Um exemplo disto é:

28 Aqui cria-se uma tabela usando o motor InnoDB. Insere-se um tuplo nessa tabela. E depois começa-se uma transação onde se adquire um shared lock para leitura. Atenção que a transação não foi terminada. Agora se fizermos outra transação: Aqui a operação de DELETE irá bloquear, pois requer um lock exclusivo mas como esse lock entra em conflito com o shared lock da transação anterior, esta espera até que a outra faça commit. Esta situação ainda poderia resultar num deadlock. Suponhamos então que agora a primeira transação queria apagar o tuplo que escreveu. Ao tentar fazer isso iria originar um deadlock porque a segunda transação já terá feito um intention exclusive lock na raiz. A primeira transação ao ver isso apercebe-se que irá existir conflito e como tem um lock partilhado desse recurso, detecta-se o deadlock. Ao acontecer isto, a primeira transação é abortada e liberta o shared lock, permitindo assim que a segunda transação avance e apague o tuplo Phantom Problems Estes problemas ocorrem quando uma determinada operação SQL obtém dois resultados diferentes quando é executada duas vezes seguidas. Exemplos disto são os select com funções de agregação (avg, sum, etc.). Para evitar isto, o InnoDB do MySQL usa um mecanismo chamado next-key locking, que combina index-row locking, que corresponde a fazer lock num rowid (equivalente ao row level locking) e gap locking, que corresponde a fazer lock ao espaço entre dois índices na tabela. Isto é feito à medida que se navega na tabela para adquirir locks. Ele irá adquirir locks para os

29 índices que se encontram na tabela e para o espaço entre índices anterior ao índice que está a processar. Ou seja, suponhamos que a tabela tem 4 tuplos, com índice 10, 11, 13, 20, respectivamente. Para fazer lock, ele irá tentar adquirir um shared lock desde o valor mais baixo possível até ao índice 10 (o que irá prevenir escritas antes do índice 10), no índice 11, no espaço entre o índice 11 e 13, no índice 13, no espaço entre 13 e 20, e no índice 20. Depois para impedir escritas no fim da tabela adquire também um lock desde o índice 20 até ao índice máximo possível na tabela Deadlocks O InnoDB detecta deadlocks automaticamente e faz rollback a uma ou mais transações de forma a quebrar o deadlock. O InnoDB tenta escolher as transações mais pequenas para fazer rollback. Quando é feito um rollback completo, todos os locks que a transação possuía são libertados. Uma forma de tornar a detecção de deadlocks e os seus rollbacks menos prejudiciais é ter uma transação que é possível de reiniciar após fazer rollback. Assim, este problema não passa de um simples tente mais tarde. Claro que se for uma transação pequena, a possibilidade de ocorrer deadlocks é mais reduzida. O esquema de locks e de isolamento pode afectar também os deadlocks. Se usarmos read committed, é possível reduzir os deadlocks, pois garante-se que os valores que irá ler são valores estáveis na base de dados e como o InnoDB usa shared locks para leituras, não há possibilidade de haver deadlocks com leituras concorrentes. As escritas não influenciam isto, porque o read committed faz leituras a partir de uma snapshot. Como última tentativa de se impedir deadlocks, o InnoDB implementa um esquema de table locks, que permite trancar uma tabela inteira. Este modelo de locks deve ser usado com cautela pois impede a concorrência na mesma tabela Processos de recuperação O InnoDB trata da recuperação de forma semelhante à estuda nas aulas. Ele possui um log, chamado redo log, onde estão registadas as operações efectuadas. Ao iniciar após um crash, ele consulta esse log e faz rollback a todas as transações não terminadas. Também faz um purge (explicado na secção 6.7) a todos os nós marcados. Dependendo do tamanho do log e do número de operações a anular, esta recuperação pode levar mais ou menos tempo. Para reduzir estes tempos é conveniente fazer backups incrementais, que consiste em gravar a BD para suporte mais permanente (fitas magnéticas, discos externos, etc) e criar checkpoints nos logs. Todas estas operações terão de ser feitas manualmente, pois o MySQL não oferece muitas ferramentas que o façam de forma automática.

30 5.6. Tratamentos de erros no InnoDB O InnoDB neste aspecto difere um pouco do standard SQL. Ou seja, em vez de fazer rollback a uma instrução inteira, o InnoDB pode só fazer rollback à parte que deu o erro. Se o erro for mais grave pode então fazer rollback à transacção toda. Por exemplo, em caso de deadlocks, o InnoDB faz rollback à transacção que originou esse deadlock mas, se ocorrer um timeout de um lock, o InnoDB só faz rollback à instrução que pediu esse lock. Para ajudar a identificar qual o tratamento a dar a cada erro, o InnoDB tem uma tabela de erros, onde cada erro tem associada a si uma rotina de tratamento (algo semelhante aos sistemas operativos e os seus mecanismos de tratamento de interrupções). Algumas rotinas podem libertar locks se o problema for de deadlocks. Outras simplesmente aumentam buffers e reiniciam a instrução que deu origem ao erro. A esta tabela de erros, o InnoDB usa ainda as tabelas de erros dos sistemas operativos, tal como erros de I/O, erros de acesso a memória, etc. Estes erros e o seu tratamento divergem de SO para SO Multi-versões O InnoDB é por si só, um sistema multi-versões, pois mantém versões antigas, para lidar com concorrência e rollbacks. Isto é guardado numa estrutura chamada segmento de rollback (que tem uma implementação semelhante no Oracle). Esta informação é usada para fazer undo s a instruções ou rollbacks. Também é usado para garantir leituras consistentes aos dados. O InnoDB para manter estas versões cria campos em cada tuplo. Um desses campos diz respeito ao ID da transacção que inseriu ou alterou o tuplo. Outro campo diz respeito ao apontador para o undo log, onde está o valor que estava antes do valor actual. Em caso de rollback, esse valor será usado para restaurar o estado anterior da BD. Os undo logs estão dividos em dois: undo log de insert e undo log de update. Os de insert são apenas necessário para restabelecer valores em caso de rollback e podem ser descartados logo que a transacção faça commit. Os de update são mantidos para garantir leituras consistentes, sendo que quando as transações que usam este log deixarem de o usar (ou seja, terminem), esse log pode ser descartado. É portanto conveniente que as transações não sejam muito longas, pois fazem com que os logs cresçam muito, aumentando o overhead nas tabelas. Devido a estes logs, a operação de remoção não é efectuada logo. O que o InnoDB faz é colocar uns bits de marcação no tuplo e, enquanto houver transações que dependem dos logs desse tuplo, ele não é removido. Quando já não existem referências para esses logs é feito um purge à tabela, que remove os tuplos marcados como apagados e sem logs. Se este purge for feito com grandes intervalos de tempo, pode levar a um crescimento enorme das tabelas, devido a dead rows. Por isso, o InnoDB permite-nos atrasar operações até que seja feito o purge, sendo que este será feito mais periódicamente, senão geraria atrasos nas escritas Savepoints e rollbacks para savepoints O InnoDB suporta as instruções do SQL para tratamento de savepoints. São elas SAVEPOINT, ROLLBACK_TO_SAVEPOINT e RELEASE_SAVEPOINT. A instrução SAVEPOINT cria um novo savepoint para a transacção actual. O ROLLBACK_TO_SAVEPOINT, tal como o nome indica, faz rollback à transacção para o savepoint, sem a terminar. As modificações feitas na BD são removidas mas os locks não são libertados. A instrução RELEASE_SAVEPOINT apaga um savepoint.

31 Os savepoints funcionam basicamente como pontos temporários, onde uma transacção pode retornar, caso veja que está a ir por um caminho errado. São muito úteis pois podem ajudar a prevenir rollbacks, o que em transações longas pode ser muito útil. Ao fazer-se commit ou rollback (sem indicar que é para um savepoint), todos os savepoints criados por uma transacção são apagados Nested Transactions Embora o MySQL não suporte Nested Transactions, com a introdução de savepoints (secção 6.8) no InnoDB, é possível criar algo semelhante a Nested Transactions, num esquema mais baixo nível. Suponhamos o seguinte exemplo: Neste exemplo pode ver-se que foram feitas duas operações na mesma transacção, como se fossem transações aninhadas. Isto é conseguido através do uso de rollbacks para savepoints,

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

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

A compreensão do mecanismo de transações é essencial, sempre que a

A compreensão do mecanismo de transações é essencial, sempre que a Transações A compreensão do mecanismo de transações é essencial, sempre que a base de dados d servir várias clientes simultaneamente. Em SQL é possível definir explicitamente os limites de uma transação.

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

Tópicos Avançados de Bases de Dados Instituto Politécnico da Guarda, Escola Superior de Tecnologia e Gestão, 2005/2006

Tópicos Avançados de Bases de Dados Instituto Politécnico da Guarda, Escola Superior de Tecnologia e Gestão, 2005/2006 Programa de TABD 2004/2005 Componente teórica Tópicos Avançados de Bases de Dados Revisão e complemento de bases de dados relacionais Revisão de conceitos básicos Transacções e controlo de concorrência

Leia mais

Armazenamento e Estruturas de Indexação em Oracle, MySQL e PostgreSQL. Sistemas de Base Dados (2011-2012)

Armazenamento e Estruturas de Indexação em Oracle, MySQL e PostgreSQL. Sistemas de Base Dados (2011-2012) Armazenamento e Estruturas de Indexação em Oracle, MySQL e PostgreSQL Sistemas de Base Dados (2011-2012) text Grupo: G03 37900 Ricardo António de Oliveira Torres 37899 Jaquilino Lopes Silva 36812 Fernando

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

Grupo 14 Márcio Sousa (41074) Filipe Milheiro (41338) João Marques (40354)

Grupo 14 Márcio Sousa (41074) Filipe Milheiro (41338) João Marques (40354) MySql Análise de Sistema de Gestão de Base de Dados Grupo 14 Márcio Sousa (41074) Filipe Milheiro (41338) João Marques (40354) Índice Índice... 1 1. Introdução... 4 1.1 Introdução histórica e aplicabilidade

Leia mais

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING http://www.uniriotec.br/~tanaka/tin0036 tanaka@uniriotec.br Bancos de Dados Distribuídos Processamento de Transações Ambiente com SGBD Distribuído Transações

Leia mais

Relatório de análise do Sistema de Gestão de Base de Dados

Relatório de análise do Sistema de Gestão de Base de Dados Departamento de Informática Relatório de análise do Sistema de Gestão de Base de Dados G02 Mestrado em Engenharia Informática Sistemas de Base de Dados - 2010/2011 André Simões ( n o 34920 ) Miguel Alves

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

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

Controle de Concorrência. Banco de Dados II Profa. Késsia R. C. Marchi

Controle de Concorrência. Banco de Dados II Profa. Késsia R. C. Marchi Controle de Concorrência Banco de Dados II Profa. Késsia R. C. Marchi Transação Transação é uma unidade lógica de trabalho, envolvendo diversas operações de bancos dados. C. J. Date Uma transação inicia-se,

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

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

Bases de Dados. Parte IX: Organização Física dos Dados

Bases de Dados. Parte IX: Organização Física dos Dados Bases de Dados Parte IX Organização Física dos Dados Unidades de Medida da Informação A unidade fundamental é o byte. byte corresponde a 8 bits e cada bit permite representar ou um 0 ou um. Kilobyte (Kbyte

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

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

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

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

ROTEIRO. A Linguagem SQL (I parte) CEFET.PHB - PI Prof. Jefferson Silva. As partes da linguagem SQL. A Linguagem de Definição de Dados (SQL-DDL)

ROTEIRO. A Linguagem SQL (I parte) CEFET.PHB - PI Prof. Jefferson Silva. As partes da linguagem SQL. A Linguagem de Definição de Dados (SQL-DDL) CEFET.PHB - PI Prof. Jefferson Silva SQL (MySql) ROTEIRO I PARTE - INTRODUÇÃO AO SQL COMANDOS E SUAS PARTES DA LINGUAGEM SQL II PARTE ADMINSTRAÇÃO DE BANCO DE DADOS UTILIZANDO MYSQL PRINCIPAIS INSTRUÇÕES

Leia mais

CONTROLE DE CONCORRÊNCIA EM BANCO DE DADOS: Estudo de Caso Microsoft SQL Server 2008

CONTROLE DE CONCORRÊNCIA EM BANCO DE DADOS: Estudo de Caso Microsoft SQL Server 2008 CONTROLE DE CONCORRÊNCIA EM BANCO DE DADOS: Estudo de Caso Microsoft SQL Server 2008 GERALDA SILVIA DE VASCONCELOS JARDIM 1 IREMAR NUNES DE LIMA 2 Resumo: Este artigo descreve a importância do mecanismo

Leia mais

Gonçalo Amador Ricardo Alexandre. Bases de Dados Distribuídas

Gonçalo Amador Ricardo Alexandre. Bases de Dados Distribuídas Sistemas Distribuidos e Tolerância a Falhas Gonçalo Amador Ricardo Alexandre Departamento de Informática Universidade da Beira Interior Bases de Dados Distribuídas 1 Modelos de Bases de Dados 2 Conceitos

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

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

PHP INTEGRAÇÃO COM MYSQL PARTE 1

PHP INTEGRAÇÃO COM MYSQL PARTE 1 INTRODUÇÃO PHP INTEGRAÇÃO COM MYSQL PARTE 1 Leonardo Pereira leonardo@estudandoti.com.br Facebook: leongamerti http://www.estudandoti.com.br Informações que precisam ser manipuladas com mais segurança

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

CONCORRÊNCIA. 1. Introdução. Recursos exclusivos. Não necessita controle. Abundância de recursos compartilhados. Controle necessário mas mínimo

CONCORRÊNCIA. 1. Introdução. Recursos exclusivos. Não necessita controle. Abundância de recursos compartilhados. Controle necessário mas mínimo CONCORRÊNCIA 1. Introdução Recursos exclusivos Não necessita controle Abundância de recursos compartilhados Controle necessário mas mínimo Harmonia, provavelmente não haverá conflito Recursos disputados

Leia mais

Controle de transações em SQL

Controle de transações em SQL Transações Controle de transações em SQL Uma transação é implicitamente iniciada quando ocorre uma operação que modifica o banco de dados (INSERT, UPDATE ou DELETE). Uma transação pode terminar normalmente

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

Sistemas de Bases de Dados

Sistemas de Bases de Dados Sistemas de Bases de Dados Carlos Passos nº 32387 Docente: Prof. José Júlio Alferes Índice 1. INTRODUÇÃO... 3 1.1. INTRODUÇÃO HISTÓRICA E APLICABILIDADE DO SISTEMA ESTUDADO... 4 1.2. NOTAS SOBRE INSTALAÇÃO

Leia mais

Armazenamento de Dados e Indexação em PostgreSQL e MySQL

Armazenamento de Dados e Indexação em PostgreSQL e MySQL Armazenamento de Dados e Indexação em PostgreSQL e MySQL Tiago Almeida 36656 André Machado 37658 3 de Dezembro, 2011 Conteúdo 1 PostgreSQL 2 1.1 Armazenamento.......................... 2 1.1.1 Armazenamento

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

Sistema de Base de Dados Distribuída

Sistema de Base de Dados Distribuída Base de Dados Distribuídas Bases de Dados Heterogéneas e Homogéneas Armazenagem Distribuída de Dados Transacções Distribuídas Protocolos de Commit Processamento Distribuído de Consultas Controlo de Concorrência

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

PROCESSAMENTO E OPTIMIZAÇÃO DE PERGUNTAS

PROCESSAMENTO E OPTIMIZAÇÃO DE PERGUNTAS 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:

Leia mais

Arquitetura do MySQL. Capítulo 1. Arquitetura Lógica do MySQL

Arquitetura do MySQL. Capítulo 1. Arquitetura Lógica do MySQL Capítulo 1 Arquitetura do MySQL A arquitetura do MySQL é muito diferente da dos outros servidores de banco de dados e é útil para uma grande variedade de objetivos. MySQL não é perfeito, mas é flexível

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

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

DICIONÁRIOS. template class Par { public: K chave; T valor; Par():chave(),valor()

DICIONÁRIOS. template<class K,class T> class Par { public: K chave; T valor; Par():chave(),valor() DICIONÁRIOS Esta estrutura inclui-se nos chamados contentores associativos, que não são mais do que uma colecção de estruturas de tipo Par, com dois membros de dados (chave de pesquisa e valor associado),

Leia mais

Banco de Dados. Maurício Edgar Stivanello

Banco de Dados. Maurício Edgar Stivanello Banco de Dados Maurício Edgar Stivanello Agenda Conceitos Básicos SGBD Projeto de Banco de Dados SQL Ferramentas Exemplo Dado e Informação Dado Fato do mundo real que está registrado e possui um significado

Leia mais

Transações Seguras em Bancos de Dados (MySQL)

Transações Seguras em Bancos de Dados (MySQL) Transações Seguras em Bancos de Dados (MySQL) Índice Entendendo os storage engines do MySQL 5 1 As ferramentas 1 Mais algumas coisas que você deve saber 1 Com a mão na massa 2 Mais ferramentas Usando o

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

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

Bases de Dados Distribuídas

Bases de Dados Distribuídas Introdução Devido ao ambiente de grande competitividade em que as organizações de hoje têm que actuar, estas são forçadas a distribuir-se geograficamente, procurando as condições locais mais favoráveis

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

RESUMO CAPÍTULO 16 OVERVIEW OF TRANSACTION MANAGEMENT. Prof.: Geovane Magalhães Alunos: Gabriela G. Martins Edmar R. S. de Rezende

RESUMO CAPÍTULO 16 OVERVIEW OF TRANSACTION MANAGEMENT. Prof.: Geovane Magalhães Alunos: Gabriela G. Martins Edmar R. S. de Rezende RESUMO CAPÍTULO 16 OVERVIEW OF TRANSACTION MANAGEMENT Prof.: Geovane Magalhães Alunos: Gabriela G. Martins Edmar R. S. de Rezende ÍNDICE ANALÍTICO 16.1 AS PROPRIEDADES ACID... 3 16.1.1 CONSISTÊNCIA E ISOLAMENTO...

Leia mais

Uma Base de Dados é uma colecção de dados partilhados, interrelacionados e usados para múltiplos objectivos.

Uma Base de Dados é uma colecção de dados partilhados, interrelacionados e usados para múltiplos objectivos. 1. Introdução aos Sistemas de Bases de Dados Uma Base de Dados é uma colecção de dados partilhados, interrelacionados e usados para múltiplos objectivos. O conceito de base de dados faz hoje parte do nosso

Leia mais

BD Oracle. Licenciatura em Engenharia Informática e Computação. Bases de Dados 2003/04

BD Oracle. Licenciatura em Engenharia Informática e Computação. Bases de Dados 2003/04 BD Oracle SGBD Oracle Licenciatura em Engenharia Informática e Computação Bases de Dados 2003/04 BD Oracle Introdução aos SGBD Base de Dados Colecção de dados que descrevem alguma realidade Sistema de

Leia mais

BANCO DE DADOS CONCEITOS BÁSICOS

BANCO DE DADOS CONCEITOS BÁSICOS Universidade Federal da Paraíba UFPB Centro de Energias Alternativas e Renováveis - CEAR Departamento de Eng. Elétrica DEE BANCO DE DADOS CONCEITOS BÁSICOS Isaac Maia Pessoa Introdução O que é um BD? Operações

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

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

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

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

ADMINISTRAÇÃO DE BANCO DE DADOS

ADMINISTRAÇÃO DE BANCO DE DADOS ADMINISTRAÇÃO DE BANCO DE DADOS ARTEFATO 03 AT03 Diversos II Page 1 of 25 Indice EXEMPLOS COM GROUP BY E COM A CLÁUSULA HAVING - TOTALIZANDO DADOS... 3 GROUP BY... 3 Cláusula HAVING com GROUP BY... 5 ENTENDENDO

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

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

TRANSAÇÕES. Considerando que estes comandos fazem parte de uma TRANSAÇÃO (veremos como indicar isso):

TRANSAÇÕES. Considerando que estes comandos fazem parte de uma TRANSAÇÃO (veremos como indicar isso): TRANSAÇÕES 1. Visão Geral Uma transação é uma unidade lógica de trabalho (processamento) formada por um conjunto de comandos SQL cujo objetivo é preservar a integridade e a consistência dos dados. Ao final

Leia mais

Bases de Dados. Lab 1: Introdução ao ambiente. Figura 1. Base de dados de exemplo

Bases de Dados. Lab 1: Introdução ao ambiente. Figura 1. Base de dados de exemplo Departamento de Engenharia Informática 2014/2015 Bases de Dados Lab 1: Introdução ao ambiente 1º semestre O ficheiro bank.sql contém um conjunto de instruções SQL para criar a base de dados de exemplo

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

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

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

Banco de Dados I 2007. Módulo V: Indexação em Banco de Dados. (Aulas 4) Clodis Boscarioli

Banco de Dados I 2007. Módulo V: Indexação em Banco de Dados. (Aulas 4) Clodis Boscarioli Banco de Dados I 2007 Módulo V: Indexação em Banco de Dados (Aulas 4) Clodis Boscarioli Agenda: Indexação em SQL; Vantagens e Custo dos Índices; Indexação no PostgreSQL; Dicas Práticas. Índice em SQL Sintaxe:

Leia mais

Crash recovery é similar ao instance recovery, onde o primeiro referencia ambientes de instância exclusiva e o segundo ambientes parallel server.

Crash recovery é similar ao instance recovery, onde o primeiro referencia ambientes de instância exclusiva e o segundo ambientes parallel server. Recover no Oracle O backup e recuperação de dados em um SGBD é de grande importância para a manutenção dos dados. Dando continuidade a nossos artigos, apresentamos abaixo formas diferentes de se fazer

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

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

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

Unidade 5 Armazenamento e Indexação

Unidade 5 Armazenamento e Indexação Unidade 5 Armazenamento e Indexação Engenharia de Computação / Engenharia de Produção Banco de Dados Prof. Maria das Graças da Silva Teixeira Material base: Banco de Dados, 2009.2, prof. Otacílio José

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

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

Fundamentos do Sistema Gerenciador de Banco de Dados

Fundamentos do Sistema Gerenciador de Banco de Dados Fundamentos do Sistema Gerenciador de Banco de Dados Cláudio Luís V. Oliveira Janeiro de 2010 Definição "Um sistema cujo objetivo principal é gerenciar o acesso, a correta manutenção e a integridade dos

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

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

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

Gerenciamento de um Sistema de

Gerenciamento de um Sistema de SBD Gerenciamento de um Sistema de Banco de Dados Prof. Michel Nobre Muza ua michel.muza@ifsc.edu.br Prof. Marcos Antonio Viana Nascimento Por que é importante: Motivação Participar na organização e no

Leia mais

Dicas de Projeto Lógico Relacional

Dicas de Projeto Lógico Relacional Dicas de Projeto Lógico Relacional O que deve ser especificado? mapeamento do esquema conceitual definição das tabelas e chaves justificativas de mapeamento (se necessário) restrições de integridade (RIs)

Leia mais

Cap. 3 Organização de Ficheiros e Indexação

Cap. 3 Organização de Ficheiros e Indexação Cap. 3 Organização de Ficheiros e Indexação If you don t find it in the index, look very carefully through the entire catalogue. -- Sears, Roebuck, and Co., Consumer s Guide, 1897 Abel J.P. Gomes Bibliografia:

Leia mais

Trabalhando com MySQL: Uma Introdução

Trabalhando com MySQL: Uma Introdução Trabalhando com MySQL: Uma Introdução 1. A linguagem PHP A linguagem PHP é uma linguagem de programação criada especialmente para o uso em páginas Web. Mas nem por isso ela não pode deixar de ser usada

Leia mais

Noções de Processamento de Transações, Controle de Concorrência e Recuperação de Falhas

Noções de Processamento de Transações, Controle de Concorrência e Recuperação de Falhas Noções de Processamento de, e Banco de Dados I Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Departamento de Computação DECOM Transação

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

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

ADMINISTRAÇÃO DE BANCO DE DADOS

ADMINISTRAÇÃO DE BANCO DE DADOS ADMINISTRAÇÃO DE BANCO DE DADOS ARTEFATO 06 AT06 Índices 1 Indice INTRODUÇÃO... 3 CLUSTERED INDICES... 4 NONCLUSTERED INDICES... 5 TRANSACT-SQL AND INDICES... 6 COMPOSITE INDEX... 8 ALTERING INDICES...

Leia mais

Sistemas Operativos I

Sistemas Operativos I Gestão da Memória Luis Lino Ferreira / Maria João Viamonte Fevereiro de 2006 Gestão da Memória Gestão de memória? Porquê? Atribuição de instruções e dados à memória Endereços lógicos e físicos Overlays

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

A instância fica alocada na memória compartilhada (shared memory) e é a combinação do System Global Area (SGA) com os processos background Oracle.

A instância fica alocada na memória compartilhada (shared memory) e é a combinação do System Global Area (SGA) com os processos background Oracle. ESTRUTURAS DE ARMAZENAMENTO Instance Na instância são executados processos e espaços em memória, estes permitem ao Oracle cumprir com seu papel de manter a integridade, confidencialidade e disponibilidade

Leia mais

BANCO DE DADOS BANCO DE DADOS. Prof. Patrícia Lucas 3º Trimestre

BANCO DE DADOS BANCO DE DADOS. Prof. Patrícia Lucas 3º Trimestre BANCO DE DADOS BANCO DE DADOS Prof. Patrícia Lucas 3º Trimestre ROTEIRO PARA O 3º TRIMESTRE 1. O MySQL DDL SQL 1. Como funciona o MySQL 2. Como criar um banco de dados no MySQL 3. Como criar tabelas: comandos

Leia mais

Transações. Prof. Márcio Bueno. {bd2tarde,bd2noited}@marciobueno.com. Material do Prof. Paulo Pires

Transações. Prof. Márcio Bueno. {bd2tarde,bd2noited}@marciobueno.com. Material do Prof. Paulo Pires Transações Prof. Márcio Bueno {bd2tarde,bd2noited}@marciobueno.com Material do Prof. Paulo Pires Introdução a Transações SGBD sistema de processamento de operações de acesso ao BD SGBDs são em geral multi-usuários

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

Relatório do Trabalho de Sistemas de Bases de Dados. Dezembro 2011 GRUPO G11 NUNO GOMES (36720) RICARDO MESTRE (35066) ANTÓNIO MOTA (33801)

Relatório do Trabalho de Sistemas de Bases de Dados. Dezembro 2011 GRUPO G11 NUNO GOMES (36720) RICARDO MESTRE (35066) ANTÓNIO MOTA (33801) DEPARTAMENTO DE INFORMÁTICA Mestrado em Engenharia Informática ARMAZENAMENTO E ESTRUTURAS DE INDEXAÇÃO Relatório do Trabalho de Sistemas de Bases de Dados Dezembro 2011 GRUPO G11 NUNO GOMES (36720) RICARDO

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

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

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

SQL - Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL

SQL - Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL SQL - Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL Criar uma base de dados (criar um banco de dados) No mysql: create database locadora; No postgresql: createdb locadora Criar

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

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

Armazenamento e Estruturas de Indexação

Armazenamento e Estruturas de Indexação Departamento de Informática Data: 3 de Dezembro de 2011 Grupo: 16 Armazenamento e Estruturas de Indexação Trabalho Final Sistemas de Base de Dados João Barbosa Nº38060 João Santos Nº35104 Tânia Leitão

Leia mais

RANGE-HASH e RANGE-LIST

RANGE-HASH e RANGE-LIST RANGE-HASH e RANGE-LIST O COMPOSITE PARTITION é um método de particionamento composto, unindo os três métodos discutidos anteriormente. Como os métodos Range, Hash e List Partition. Existem dois tipos

Leia mais

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Programação com acesso a BD Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br 1 Modelos de Dados, Esquemas e Instâncias 2 Modelos de Dados, Esquemas e Instâncias Modelo de dados: Conjunto de conceitos

Leia mais

Bases de Dados II 6638: BSc in Information Systems and Technologies. Cap. 1 Arquitectura de Sistemas de Bases de Dados. Module Introduction

Bases de Dados II 6638: BSc in Information Systems and Technologies. Cap. 1 Arquitectura de Sistemas de Bases de Dados. Module Introduction Bases de Dados II 6638: BSc in Information Systems and Technologies Cap. 1 Module Introduction Objectivos O propósito e a origem da arquitectura de base de dados a três níveis. O conteúdo dos níveis externo,

Leia mais

Programação SQL. Introdução

Programação SQL. Introdução Introdução Principais estruturas duma Base de Dados: Uma BD relacional é constituída por diversas estruturas (ou objectos ) de informação. Podemos destacar: Database: designa a própria BD; Table/Tabela:

Leia mais