Terminar com o SELECT COUNT(*) FROM schema_name.table_name

Esta simples instrução ( SELECT COUNT(*) FROM schema_name.table_name) para tabelas de pequena dimensão não tem grande impacto, mas para tabelas grandes é muito prejudicial ao desempenho. Recomendo vivamente que não o utilizem nestas situações, porque para obter o número de linhas é realizado um full table scan à tabela em questão.

Apresento aqui algumas alternativas:

SQL Server BOX

/*******************************************************************************/

SQL Server 2000 e 2005
SP_MSTABLESPACE ‘schema_name.table_name’;

SQL Server 2005
SELECT TOTAL_ROWS = SUM(P_ST.ROW_COUNT)
FROM   SYS.DM_DB_PARTITION_STATS P_ST
WHERE  OBJECT_NAME(OBJECT_ID) = ‘table_name’
AND (INDEX_ID < 2);

/*******************************************************************************/

Oracle BOX

/*******************************************************************************/

SELECT OWNER,
TABLE_NAME,
NUM_ROWS
FROM DBA_TABLES
WHERE TABLE_NAME = ‘table_name’
AND OWNER = ‘schema_name; 

/*******************************************************************************/

Nota:É imprescindível que as tabelas possuam estatísticas actualizadas. Senão não há alternativa ao SELECT COUNT(*) FROM schema_name.table_name ou seus derivados. Ou há SELECT COUNT(1) FROM FROM schema_name.table_name ou seus derivados, escolha um campo que seja índex e not null.

João Paulino

Oracle Data Guard versus Microsoft SQL Server 2005 Database Mirroring

Coloco aqui um link para um artigo, que de um modo mais ou menos imparcial ( É da Oracle) compara duas propostas de funcionalidades de ”High Availability” distintas, mas como finalidades semelhantes. http://www.oracle.com/technology/deploy/availability/htdocs/DataGuardDatabaseMirroring.html

João Paulino

O que é que um DBA (Administrador de Base de Dados) necessita saber?

Em primeiro lugar e para realizar um bom trabalho, o DBA deverá saber o básico de Teoria de Base de Dados e não só dominar a teoria Relacional. Sem esta base fundamental, muitas situações de decisão de desenho e concepção, operações de manutenção e performance são impossíveis de realizar.  

 

Em segundo lugar, o DBA precisa de compreender o desenho do modelo de dados. Esta compreensão é o pilar central para o desenho e arquitectura na concepção de base de dados e na sua manutenção, não há melhor prática de performance do que um bom modelo de dados.

 

O DBA necessita saber sobre Armazenamento (Storage). É uma área onde os DBA’s devem intervir, mesmo existindo Consultores Especialistas em Armazenamento (Storage). É muito importante compreender os conceitos básicos de DAS, SAN, NAS e SSD, este conhecimento é importantíssimo pois os ficheiros das base de dados estarão sempre em disco e é necessário conhece-los bem…

 

Deverá conhecer o fornecedor da plataforma específica que implementou/utiliza, seja a IBM, a Microsoft ou a Oracle, pois todas elas indicam formas de realizar operações como manutenção ou melhoramentos e ajustes de performance, deverá o DBA entender como estas empresas abordam estes temas.

 

O DBA necessita conhecer e aplicar as melhores práticas de manutenção e ajustes de performance, este conhecimento deve combinar informação genérica e específica.

 

Na minha opinião o DBA deverá saber de programação, especialmente C/C++, e não estar limitado ao SQL e seus Dialectos.

 

O DBA deverá saber realizar algumas operações de administração de pelo menos um Sistema Operativo Servidor, especialmente sobre aquele que suporta ao SGBDR (Instância ou Instâncias e respectivos ficheiros) e conceitos básicos de Rede.

Muitos dos conhecimentos são genéricos tais como desenho de modelo de dados e outros mais específicos como os passos necessários para restaurar uma cópia de segurança.

 

João Paulino

Portátil/Iniciativa Magalhães

 
Portátil Magalhães
Portátil Magalhães

Para melhor acompanharem as notícias, discussões e o estado da nação relativamente ao Computador Magalhães aqui deixo links para um blog Portátil Magalhães http://www.portatilmagalhaes.com/ e para o sítio oficial que está muito pobre (uma única página com um vídeo promocional) http://www.iniciativa-magalhaes.com/

João Paulino

 

Dia a dia ou a rotina de um DBA Parte I (Database Administrator/ Administrador de Base de Dados)!!!

É comum ainda, em muitas empresas e especialmente nas empresas não tecnológicas nem de comunicações, o DBA ser recurso isolado e trabalhar sozinho sem pares iguais, o que origina preocupação relativamente à qualidade do seu trabalho, em particular se a natureza do negócio, empresa ou qualquer outro interveniente de “Peso” se opõe à utilização de chamadas “Boas Práticas” que tanto se ouve falar. A formação é essencial para consolidar conhecimentos e adquirir outros, trocar ideias e alinhar pelas melhores práticas.

 

Lista do que penso serem as tarefas mais importantes de um DBA:

 

#1 – Backup/Cópias de Segurança à Realizar Cópias de Segurança dos Dados e Restauro dos mesmos. Deverá se possível ter uma cópia diária de segurança completa dos dados, se tal não for possível deverá no mínimo ser semanal e não deverão ser esquecidos o Transaction log (activando e configurando o Log Shipping) no caso do SQL Server, os Redo Logs (activando e configurando archive log mode) no caso do Oracle. Estes deverão ser alvo de backup num intervalo compreendido entre os 5 e os 30 minutos. Não existem muitas situações que originem o despedimento de um DBA, mas não existir uma cópia de segurança efectiva e actualizada da base de dados é uma das situações que pode levar ao seu despedimento.

 

#2 – House Keeping/Remoção de Dados Antigos e/ou Desnecessários e outras tarefas não menos importantes à. Um DBA deverá gastar entre 30 a 60 minutos do seu horário de trabalho para esta operação, deverá planificar, produzir documentação e scripts para a sua efectivação. É uma  boa prática verificar se as instâncias estão em bom estado de performance, 20 a 30 minutos antes dos utilizadores se ligarem às Bases de Dados e aplicações ou Integração de Aplicações Corporativas (EAI) iniciarem solicitações às Base de Dados. Deverão ser verificados as actividades nocturnas, emails, alertas e notificações. É importante manter-se actualizado lendo fóruns, blogs, revistas da especialidade e livros técnicos. Não permita que lhe neguem este tempo de sanidade mental, que deverá ser uma rotina e não ocasional. No caso de se encontrar num grande projecto ou vários ou em momentos de muito stress, poderá ser tentado a não cumprir esta rotina, não o faça porque é este o caminho a seguir.

#3 – Best Practices/Melhores Práticas à. Caso possua a um determinado ambiente em que pareça que as melhores práticas não encaixam, deverá convencer e mostrar ao negócio que a sua aplicação faz sentido e é muito útil, no entanto deve ter em atenção a realidade e as necessidades de determinadas áreas, departamentos, empresas e negócios, nas quais não é possível implementar a totalidade das boas práticas.

(Continua…)

João Paulino

A verdade vem sempre ao de cima – 70% das Empresas falha os SLAs

 

 Possuir e não possuir um SLA acordado

Possuir e não possuir um SLA acordado

 
 Pode parecer caricato, mas é verdade que cerca de 70% das empresas falha os SLAs e deve-se essencialmente ao facto das expectativas do negócio estar muito acima das capacidades das TI (engloba comunicações, software, hardware e recurso humanos), que origina a falha no cumprimento dos SLA. Podemos imaginar então os valores de não cumprimentos dos OLA (Nota: OLA não esta relacionada com a conhecida marca de gelados e congelados). Aqui coloco a definição de alguns dos termos mais utilizados nesta componente das TI.

Availability: Capacidade que determinado componente ou serviço tem de executar sua função em certo momento ou por um tempo definido.

Countermeasures: Acções realizadas para prevenir ou reduzir os efeitos de um risco identificado.

Critical Business Functions: Partes críticas dum processo empresarial suportado por um serviço de TI.

End-to-End Service: Todos os componentes de infra-estrutura de TI necessários para entregar um serviço de TI.

High Availability: Método utilizado pata minimizar ou mascarar falhas em componentes de TI.

Incident Life Cycle: Ciclo de vida de um incidente que envolve a ocorrência do incidente, detecção do incidente, diagnóstico da causa da falha, a reparação da falha e recuperação e restauro do serviço.

Maintainability: É a actividade de manter ou restabelecer um componente (software/hardware) da infra-estrutura de TI em um estado operacional.

Operating Level Agreement (OLA): Um acordo interno que apoia as exigências de um SLA.

Risk Management: Processo de identificação e implementação de actividades com a finalidade de reduzir os riscos activos a um nível considerado aceitável.

Reliability: Ausência de falhas em componente ou serviço em determinado período de tempo.

Serviceability: Acordos com fornecedor de serviços de TI para fornecer e manter serviços e componentes de TI.

Service Level Agreement (SLA): Acordo escrito que documenta os níveis exigidos por determinado serviço, firmado entre o fornecedor do serviço (Empresa ou Departamento de TI) e a organização ou terceiros.

Service Outages: O mesmo que Downtime.

João Paulino

Downtime: Período de tempo que um serviço se encontra sem funcionar, com relação ao acordo de funcionamento determinado nos SLAs.