sexta-feira, 31 de agosto de 2012

Locks – Sybase IQ

Para vericar os Objetos com lock no Banco de dados SYBASE IQ, utilizamos a seguinte procedure:

sp_iqlocks ([connection,] [[owner.] table_name] max_locks,] [sort_order])

Name Type Descrição

connection

Integer

Retorna os bloqueis do ID da conexão. O padrão é zero, que retorna informações sobre todas as conexões.

owner.table_name

char(128)

Nome da tabela. Com esta opção, a procedure retorna informações sobre bloqueios somente da tabela. O padrão é NULL, que retorna informações sobre todas as tabelas do banco de dados.

max_locks

Integer

Número máximo de bloqueios que devem ser exibidos. O padrão é 0, que retorna todas as informações de bloqueio.

sort_order

char(1)

Ordem de retorno dos bloqueios:
Tipo C por conexão (padrão)
Tipo T por table_name

 

Ao ser executada a procedure de acordo com os parametros acima podemos analisar as seguintes informações:

Coluna Tipo Descrição

conn_name

VARCHAR(128)

Nome da conexão atual

conn_id

INTEGER

ID da conexão com lock

user_id

CHAR(128)

Usuário causador do lock

table_type

CHAR(6)

O tipo da tabela:

  • BASE – para tabela
  • GLBTMP – para tabela temporária Global
  • MVIEW – para materialized view

creator

VARCHAR(128)

Owner da tabela

table_name

VARCHAR(128)

Nome da tabela com Lock

index_id

INTEGER

ID do indice

lock_class

CHAR(8)

Tipo do Lock.

  • S – Share
  • SW – Share and Write
  • EW – exclusive and Write
  • E – exclusive
  • P – Phantom
  • A – Antiphantom
  • W – Write
  • T – The lock is with respect to a sequencial scan
  • * – the lock is with respect to all scans
  • nnn – Index number; the lock is with respect to a particular index

lock_duration

 

CHAR(11)

Duração do bloqueio

lock_type

CHAR(9)

Identifica o lock (table, procedure,view)

row_identifier

UNSIGNED BIGINT

Identifica a linha

 

Exemplo a seguir foi executada a procedure sem a passagem de parametros, ou seja, neste caso serão utilizados os valores default:

sp_iqlocks
conn_name  conn_id  user_id  table_type  creator  table_name   =========  =======  =======  ==========  =======  ==========   con1       70187172 'mary'   BASE        DBA       t1         


index_id lock_class  lock_duration  lock_type  row_identifier
======== ==========  =============  =========  ==============
ASIQ_IDX Table       Position       Table      1
Fonte - http://infocenter.sybase.com
[]s

quarta-feira, 29 de agosto de 2012

Boas práticas ao escrever uma Procedure - SQL Server

  1. Utilize recuo/endentação adequada, pois terá melhor legibilidade melhorando seu entendimento futuro e de outras pessoas
  2. Escreva os comentários apropriados entre as lógicas para que assim, os outros possam entender rapidamente.
  3. Escreva todas as palavras-chave do SQL Server em CAPS. Por exemplo SELECT, FROM e CREATE.
  4. Procure nomear suas procedures com um nome intuitivo ao processo que ela executa
  5. Declare todas as variáveis no início da procedure
  6. Verifique o uso de variáveis desnecessárias, pois elas ocupam espaço na memória, tente reutiliza-las dentro do código
  7. Não utilizar as iniciais SP_XXX em suas procedures. Utilize como inicial Pr_XXX pois ficará mais fácil identificar suas procedures entre as nativas do Sql Server. Inclusive na própria documentação do Sql Server já diz - “Recomendamos fortemente que você não use o prefixo sp_ no nome de procedimento. Este prefixo é usado pelo SQL Server para designar procedimentos armazenados de sistema. “
  8. Defina o SET NOCOUNT ON  no início do procedimento armazenado para evitar a mensagem desnecessária, como número de linhas afetadas pelo SQL Server.
  9. Tente fazer uso de tabelas temporárias com moderação, pois elas ocupam espaço no TempDB, além disso procedimento armazenados geralmente utilizam plano de execução em Cache, com o uso de tabelas temporárias é forçada uma nova compilação.
  10. Nunca traga todas as colunas de uma consulta (SELECT *)  a não ser que for realmente necessário, use apenas colunas específicas que serão utilizadas no resultado.
  11. Tente evitar o cursor no procedimento armazenado, ele consome mais memória. Tente utilizar a variável de tabela e while loop para iterar o conjunto de resultados da consulta.
  12. Nos parâmetros de entrada da procedure, defina os types com os mesmos tamanhos e tipos das tabelas. Por exemplo, Nome Char(10) na tabela, mas você declara Nome Char(25) na procedure.
  13. Use a instrução catch Try corretamente no procedimento armazenado para lidar com os erros em tempo de execução.
  14. Se o retorno da procedure for uma única coluna/linha, prefira utilizar parâmetros de saída na procedure.
  15. Evite utilização de sub-queries ao invés disso utilize inner join
  16. Em condições de verificação de existência (exists) utilize Select top 1
  17. Em consultas  (SELECT * FROM TbProduto where id = @id) para que seu plano de execução seja reaproveitado deve ser utilizado conforme exemplo anterior, mas você estiver usando uma consulta SQL como “SELECT * FROM Tbproduto where id = "+ @ eid, dessa forma não será reutizado o plano
  18. Use o ORDER BY e DISTINCT, TOP somente quando for necessário.
  19. Verifique a necessidade de índices entre colunas de tabelas grandes que realizam joins ou filtros por essas colunas
  20. Verifique se as colunas que compõem os joins utilizam datatypes diferentes, um deles será convertido para o outro. O datatype convertido é o hierarquicamente inferior. O otimizador não consegue escolher um índice na coluna que é convertida.

[]s

segunda-feira, 27 de agosto de 2012

DeadLock – Como identificar - Oracle

 

Para verificar problemas de bloqueio em seu banco de dados, deve seguir os passos abaixo:

1. Para verificar qual a sessão que esta realizando o bloqueio, execute o select abaixo:

select sid, serial#, username, command, lockwait, osuser from v$session where lockwait is not null

2. Identificado a sessão podemos mata-la para que o bloqueio seja liberado, para isso substitua no script abaixo a sid e serial# coletados na consulta acima

alter system kill session 'sid, serial#';

Obs: Lembrando que para isso você deverá ter privilégios

3. Encontrar qual o SQL esta causando o bloqueio

select sql_text from v$sqltext where (address,hash_value) in (select sql_address,sql_hash_value from v$session where lockwait is not null) order by address, hash_value, piece

4. Ok, aprendemos a identificar e a eliminar o a sessão que estava realizando o bloqueio em nosso banco de dados e ainda a identificar a consulta/comando que estava executando o bloqueio. Agora vamos simular um caso real:

Primeiros vamos criar uma tabela e popular com alguns registros:

CREATE TABLE TbProduto (NmProduto VARCHAR(100) NOT NULL, VrPreco NUMERIC(10,2) NOT NULL);

INSERT INTO TbProduto (NmProduto, VrPreco) VALUES ('Tenis',100.50);

INSERT INTO TbProduto (NmProduto, VrPreco) VALUES ('Sapato',90.50);

INSERT INTO TbProduto (NmProduto, VrPreco) VALUES ('Chinelo',20.50);

COMMIT;

Agora em uma sessão vamos realizar um aumento no valor dos produtos em R$0.50:

UPDATE TbProduto

   SET VrPreco = VrPreco + 0.50;

3 rows updated

Não vamos commitar.

Abra uma outra sessão e vamos realizar a mesma atualização de valor, simulando uma situação em que 2 pessoas ao mesmo tempo tentou realizar o aumento do preço do produto.

UPDATE TbProduto

   SET VrPreco = VrPreco + 0.50;

Verificamos que nesse caso, não recebemos retorno de alteração dos 3 produtos, pois essa sessão esta esperando o commit da sessão anterior para realizar essa atualização, ou seja, nesse caso temos um DeadLock (onde 2 sessãos estão tentando atualizar os mesmos dados)

Não vamos commitar ainda.

Vamos abrir uma terceira sessão, é agora que vai inciar nossa análise. Primeiro vamos verificar quais as sessões que estão gerando o bloqueio:

select sid, serial#, username, command, lockwait, osuser from v$session where lockwait is not null

SID SERIAL# USERNAME COMMAND LOCKWAIT OSUSER
51 51 SYS 6 BE99CB98 nnh-PC\nnh

 

Vamos testar a consulta para identicar o comando que esta causando o bloqueio:

select sql_text from v$sqltext where (address,hash_value) in (select sql_address,sql_hash_value from v$session where lockwait is not null) order by address, hash_value, piece

SQL_TEXT
UPDATE TbProduto    SET VrPreco = VrPreco + 0.50

 

Agora vamos matar a sessão que esta causando bloqueio;

alter system kill session '51,51';

System altered

Fonte: http://psoug.org/reference/deadlocks.html 

[]s

segunda-feira, 20 de agosto de 2012

Identificar permissões de uma Role – Sql Server

 

Segue consulta:

select dp.NAME AS principal_name,
           dp.type_desc AS principal_type_desc,
           o.NAME AS object_name,
           p.permission_name,
           p.state_desc AS permission_state_desc
   from    sys.database_permissions p
   left    OUTER JOIN sys.all_objects o
   on     p.major_id = o.OBJECT_ID
   inner   JOIN sys.database_principals dp
   on     p.grantee_principal_id = dp.principal_id
order by principal_name

 

[]s

segunda-feira, 13 de agosto de 2012

Qual a diferença entre BLOB x CLOB - Oracle

Um BLOB (binary large object) é um tipo de dados Oracle que pode conter até 4 GB de dados binarios. BLOB são úteis para armazenar informação digital (por exemplo, imagens, áudio, vídeo).

Um CLOB (Character Large objeto) é um tipo de dados Oracle que pode conter até 4 GB de dados. CLOBs são úteis para armazenar texto.

Tipos de dados BLOB e CLOB são criados através da utilização do CREATE TABLE ou ALTER da mesma forma que são criados campos de outros tipos.

Exemplos:

BLOB:

CREATE TABLE DOMINA_BLOB (id NUMBER, doc BLOB);

INSERT INTO DOMINA_BLOB VALUES (1, EMPTY_BLOB());

CLOB:

CREATE TABLE DOMINA_CLOB(id NUMBER, doc CLOB);
INSERT INTO DOMINA_CLOB VALUES (1, 'some CLOB data');
[]s
 

Qual o tamanho da Transaction Log?

 

Podemos observar o tamanho do Transaction Log, em MB, e o quando, em percentual, está sendo utilizado do Transaction Log com o seguinte comando:

DBCC SQLPERF (LOGSPACE)

Exemplo do retorno:

Warnings: --->
  W (1): DBCC execution completed. If DBCC printed error messages, contact your system administrator.
         <---
Database Name                  Log Size (MB)     Log Space Used (%)     Status   
----------------------          ----------------      ---------------------      ---------
master                                    2,9921875         31,723237991333008     0        
tempdb                                1363,0546875      21,62744903564453      0        
msdb                                     42,9921875        16,172996520996094     0        
  

3 record(s) selected [Fetch MetaData: 15/ms] [Fetch Data: 47/ms]

[Executed: 13/08/12 10h32min44s BRT ] [Execution: 110/ms]

 

[]s

sexta-feira, 10 de agosto de 2012

Conceito do banco de dados NoSQL

NoSQL é um termo utilizado para definir um tipo de banco de dados que não segue normas de tabelas (schemas) determinadas previamente. Seu significado é (Not only SQL - Não só SQL) e vem do conceito de que o banco de dados não necessita de normalização e relacionamentos.

A computação na nuvem , análises sociais, performance na consulta/escrita, replicação e a necessidade cada vez maior de prover serviços escaláveis, estão fazendo com que sejam pensadas em soluções onde se necessitem oferecer escalabilidade horizontal. Bancos de dados NoSQL armazenam os dados com técnicas que visam atender a essa necessidade.

O NoSQL surgiu dessa necessidade, ou seja, oferecer performance superior e de uma alta escalabilidade. Os bancos de dados relacionais existentes atualmente, possuem restrições a isso, sendo necessária a distribuição vertical de servidores, ou seja, quanto mais dados, mais memória e mais disco. O NoSQL oferece a facilidade na distribuição horizontal, que em resumo é, mais dados, mais servidores, não necessariamente de alta performance. Um grande utilizador desse conceito é o Google, que usa computadores de pequeno e médio porte para a distribuição dos dados sendo essa forma muito mais eficiente e econômica.

No entanto, o banco de dados NoSQL não têm como objetivo substituir os bancos de dados relacionais, mas apenas propor algumas soluções que em determinados cenários são mais adequadas ou quanto as ferramentas de banco de dados tradicionais não são suficientes ou adequados às necessidades específicas, tais como: baixa latência, grandes volumes de dados, escalabilidade ou estruturas em que as conexões entre os dados são tão importantes quanto o próprio dado.

NoSql é um banco de dados não normalizado, que se refere ao banco de dados não seguir uma estrutura de colunas, chaves e tipos definidos previamente. No caso dos bancos NoSQL, toda a a informação necessária estará agrupada no mesmo registro, ou seja, em vez de você ter o relacionamento entre várias tabelas para formar uma informação, ela estará em sua totalidade no mesmo registro.

Tipos de banco de dados NoSql

  • Key/Value Store - Esse é o tipo de banco de dados NoSQL fornecem uma chave eficiente para mapear os valores existentes, o conceito dele é uma chave e um valor para essa chave. Ele é o que aguenta mais carga de dados. Esses tipos de bancos de dados são o que tem a maior escalabilidade.
  • Wide Columns Store - Estes são também chamados de bancos de dados orientados a registro. Similar aos bancos de dados relacionais, é um banco de dados grande constituído por várias tabelas, cada uma contendo um conjunto de linhas endereçáveis. Cada linha consiste de um conjunto de valores que são considerados colunas. Fortemente inspirados pelo BigTable, do Google, eles suportam várias linhas e colunas, além de permitir subcolunas.
  • Document Store - Esses bancos de dados se concentram em armazenamento e acesso otimizado em documentos em vez de linhas ou registros, são Baseado em documentos XML ou JSON, podem ser localizados pelo seu id único ou por qualquer registro que tenha no documento. Alguns bancos de dados de documentos fornecem RDBMS.
  • Graph Store - Com uma complexibilidade maior, esses bancos de dados guardam objetos, e não registros como os outros tipos de NoSQL. A busca desses itens é feita pela navegação desses objetos.Além disso, eles enfatizam alto desempenho para acesso a dados associativo, evitando a necessidade de junção.Uma característica que o Graph DBs possuem é a capacidade de um valor do campo armazenar o ID de outra entidade.
  • Column Oriented Store - Esses são bancos de dados relacionais, porém apresentam características do NoSQL. A principal diferença deles é que os dados são armazenados em colunas, ajudando na escalabilidade.

Fontes: http://imasters.com.br - http://www.devmedia.com.br - http://www.fxplabs.com.br - http://www.nosqlbr.com.br

[]s

quarta-feira, 8 de agosto de 2012

Etapas da mineração de Dados

  1. Entender o problema – fase inicial do projeto, tem como objetivo principal identificar as metas através da analise da problemática
  2. Entender e identificar os dados – Nesta fase temos a extração de dados e análise
  3. Preparação ou transformação dos dados – Criação de processos de extração, limpeza e transformação dos dados para utilização dos algoritmos de mineração de dados
  4. Modelagem do problema – seleção dos algoritmos a serem utilizadas para o processamento das informações. Alguns algoritmos necessitam de um formato especializado do dados o que pode ocorrer o retorna para fase anteriores para que o processo de extração ou transformação sejam adaptados.
  5. Avaliação do Modelo – Avaliar os modelos gerados com a visão do problema validando as regras ou possíveis falhas.
  6. Publicação do Modelo – Tornar a informação acessível para tomada de decisão através de uma ferramenta específica ou até mesmo um relatório.

[]s