terça-feira, 16 de outubro de 2018

Testes de desempenho de I/O no Linux usando o comando dd



No Linux, o comando dd pode ser usado para medir o desempenho de I/O em disco utilizando escritas sequenciais. Este artigo fornecerá informações sobre quais parâmetros devem ser utilizados.


Noções básicas

dd pode ser usado para cópia de dados de baixo nível. Ao fazer isso, arquivos de dispositivos são acessados diretamente. Cuidado com o fato de que o uso incorreto do dd pode levar rapidamente à perda de dados. É recomendável executar as etapas descritas abaixo com muita atenção. Se o dd for utilizado incorretamente, o resultado será perda de dados.

Medindo o desempenho de gravação

Sistemas Operacionais modernos normalmente não gravam arquivos diretamente em sistemas de RAID ou discos rígidos. A memória temporaria que não está em uso no momento, será usada para armazenar em cache gravações e leituras.

Assim, essa medida de desempenho de I/O não será afetada por esses caches (memória temporaria),  o parâmetro oflag pode ser usado. Assim, os dois flags a seguir são interessantes (para detalhes, consulte dd --help e dd utilizando I/O direto ou sincronizado).

  • direct (utiliza I/O direto para dados)
  • dsync (utiliza I/O sincronizado para dados)
  • sync (da mema forma, mas também para metadados)
Para medir o desempenho de gravação, os dados a serem escritos devem ser lidos de /dev/zero e depois gravados em um RAID, disco rígido ou uma partição vazia (usando algo como of=/dev/sda para o primeiro disco rígido, ou of=/dev/sda2 para uma segunda partição no primeiro disco rígido. Se isso não for possível, uma file system normal pode ser utilizada (usando algo como of=/root/teste.img). Por razões de segurança se não tiverem certeza do que estão fazendo, faça os testes em um arquivo dentro da file system. No meu caso vou fazer os testes em discos raw e file system para comparação. O desempenho de gravação obtido nos testes com arquivos em file system será um pouco mais lento (porque os metadados também serão gravados no sistema de arquivo).

Importante: Ao gravar em um dispositivo (algo como /dev/sda), os dados armazenados serão perdidos. Por essa razão, escolha um RAID, disco ou partição vazia.

Nos meus testes estarei utilizando o seguinte equipamento: 
  • HP EliteBook 8460w
    • 8 GiB de RAM
    • sda (SSD)
    • sdb (SATA)
Observação:
  • Quando usar if=/dev/zero and bs=1G, o Linux precisará de 1GiB de espaço livre em memoria RAM. Se o seu ambiente de teste não tiver memória livre o suficiente, utilize um valor menor para o parâmetro bs (algo como 512MiB).
  • A fim de obter resultados mais próximos da realidade do nosso dia-a-dia, recomendo realizar os testes descritos varias vezes (tres a dez vezes, por exemplo). Ao fazer isso poderá detectar variações isoladas. Tais variações isoladas pode incluir jobs no cron, interrupções ou condições gerais devido ao processamento paralelo, o que pode afetar gravemente o desempenho. Um exemplo ao extremo, para esclarecermos essa questão, seria um job executando uma store procedure onde a mesma poderia estar fazendo muitos inserts em um banco de dados. 
HP Elite Book 8460w

Neste exemplo, nosso teste vai escrever um arquivo em /tmp , sendo a file system um XFS e SATA 5400 RPM.

1 GiB será escrito no arquivo /tmp/teste.img, primeiro com o cache ativado

merlin:/ # hdparm -W1 /dev/sdb

/dev/sdb:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
merlin:/ # dd if=/dev/zero of=/tmp/teste.img bs=1G count=1 oflag=direct
1+0 registros de entrada
1+0 registros de saída
1073741824 bytes (1,1 GB, 1,0 GiB) copiados, 9,96763 s, 108 MB/s
merlin:/ # 

agora com o cache desativado

merlin:/ # hdparm -W0 /dev/sdb

/dev/sdb:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
merlin:/ # dd if=/dev/zero of=/tmp/teste.img bs=1G count=1 oflag=direct
1+0 registros de entrada
1+0 registros de saída
1073741824 bytes (1,1 GB, 1,0 GiB) copiados, 10,0717 s, 107 MB/s
merlin:/ # 

Nesse teste vamos ver a latência, 512 bytes serão escritos 1000 vezes, primeiro com o cache desativado.

merlin:/ # hdparm -W0 /dev/sdb

/dev/sdb:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
merlin:/ # dd if=/dev/zero of=/tmp/teste.img bs=512 count=1000 oflag=direct
1000+0 registros de entrada
1000+0 registros de saída
512000 bytes (512 kB, 500 KiB) copiados, 11,7722 s, 43,5 kB/s
merlin:/ # 

agora com o cache ativado

merlin:/ # hdparm -W1 /dev/sdv

/dev/sdb:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
merlin:/ # dd if=/dev/zero of=/tmp/teste.img bs=512 count=1000 oflag=direct
1000+0 registros de entrada
1000+0 registros de saída
512000 bytes (512 kB, 500 KiB) copiados, 0,0947568 s, 5,4 MB/s
merlin:/ # 

Agora teste feito no disco SSD

cache ativado
merlin:/ # hdparm -W1 /dev/sda

/dev/sda:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
merlin:/ # dd if=/dev/zero of=/opt/teste.img bs=1G count=1 oflag=direct
1+0 registros de entrada
1+0 registros de saída
1073741824 bytes (1,1 GB, 1,0 GiB) copiados, 2,09522 s, 512 MB/s

merlin:/ # 

 cache desativado
merlin:/ # hdparm -W0 /dev/sda

/dev/sda:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
merlin:/ # dd if=/dev/zero of=/opt/teste.img bs=1G count=1 oflag=direct
1+0 registros de entrada
1+0 registros de saída

1073741824 bytes (1,1 GB, 1,0 GiB) copiados, 2,11989 s, 507 MB/s

Latencia, cache ativado
merlin:/ # hdparm -W1 /dev/sda

/dev/sda:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
merlin:/ # dd if=/dev/zero of=/opt/teste.img bs=512 count=1000 oflag=direct
1000+0 registros de entrada
1000+0 registros de saída
512000 bytes (512 kB, 500 KiB) copiados, 0,0521671 s, 9,8 MB/s

merlin:/ # 

Latência, cache desativado
merlin:/ # hdparm -W0 /dev/sda

/dev/sda:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)
merlin:/ # dd if=/dev/zero of=/opt/teste.img bs=512 count=1000 oflag=direct
1000+0 registros de entrada
1000+0 registros de saída
512000 bytes (512 kB, 500 KiB) copiados, 1,29057 s, 397 kB/s

merlin:/ # 

quinta-feira, 11 de outubro de 2018

Exportar e Importar usuarios SAMBA (pdbedit)

Para manter uma copia de segurança dos usuarios SAMBA.
Exportar
pdbedit -e smbpasswd:/home/amilcar/samba_backup.bak
Importar
pdbedit -i smbpasswd:/home/amilcar/samba_backup.bak

ou 

pdbedit -e tdbsam:/home/amilcar/samba_backup.bak

quinta-feira, 27 de setembro de 2018

Exemplos com o comando sed

Alterar padrão de data em arquivos 

exemplo de um arquivo texto


11|16952|1|0|065277493000408|7739|3|944783|1|729904|93.03|93.03|1.65|7.60|1.53|7.07|1862519|1|0|30/10/2017 00:17:50|56|
11|16953|1|0|065277493000408|7737|3|944540|1|729902|88.98|88.98|1.65|7.60|1.46|6.77|1862517|1|0|30/10/2017 00:17:47|56|

sed -E 's,([0-9]{2})/([0-9]{2})/([0-9]{4}),\3-\2-\1,g' frete.csv > frete.unl

resultado:


11|16952|1|0|065277493000408|7739|3|944783|1|729904|93.03|93.03|1.65|7.60|1.53|7.07|1862519|1|0|2017-10-30 00:17:50|56| 11|16953|1|0|065277493000408|7737|3|944540|1|729902|88.98|88.98|1.65|7.60|1.46|6.77|1862517|1|0|2017-10-30 00:17:47|56|

quinta-feira, 14 de junho de 2018

Os três principais Shells do Unix

Vou tirar um tempinho hoje para escrever um pouco sobre os 3 principais shells na maioria dos Sistemas Unix, hoje há algumas controversas pelo crescimento do Linux que utiliza o Bash Shell, porem o Bash não deixa de ser uma evolução do Bourne Shell que é um dos principais no qual vou comentar, mas vamos lá. Esses três Shell são:

  • Bourne Shell (AT&T shell)
  • C Shell (Berkeley shell)
  • Korn Shell ( Um superconjunto do Bourne Shell
Esses shells se comportam praticamente da mesma maneira quando executados de forma interativa, mas possuem algumas diferenças de sintaxe e eficiência quando usados como linguagens de scripts.

O Bourne Shell é o shell padrão na maioria dos Unix's,  muito utilizado para administrar o sistema. A maioria dos scripts de administração de sistema, como os scripts rc start / stop e shutdown são escritos em Bourne Shell, é o shell padrão também utilizado pelo root quando o sistema esta no estado de single mode. Esse Shell foi escrito pela AT&T e é conhecido por ser um shell consistente, compacto e rapido. O símbolo do prompt default do Bourne Shell é um sinal de dólar ($).

O C Shell foi desenvolvido em Berkeley e adicionou vários recursos, como o history de linha de comando, aliases, aritmética integrada, nome de arquivo completo, e controles de jobs. O C Shell tem algumas vantagens sobre o Bourne Shell na interactividade, mas os administradores preferem o Bourne Shell para scripts, porque os shells scripts do Bourne são mais simples e mais rápidos do que os mesmos scripts escritos no C Shell. O símbolo do prompt default do C Shell é um sinal de percentagem (%).

O Korn Shell é um superconjunto do Bourne Shell, escrito por David Korn na AT&T. Vários recursos foram adicionados a esse shell muito alem do C Shell. Os recursos do Korn Shell incluem um history evitável, aliases, funções, wildcards (curingas) de expressões regulares, aritmética incorporada, controle de Jobs, coprocessamento e recursos de debug. O Bourne Shell é quase totalmente compatível com o Korn Shell, portanto, programas do Bourne Shell rodarão normalmente nesse Shell. O símbolo do prompt default do Korn Shell é um sinal de dollar também ($).

No proximo post, vou descrever um pouco da historia do Shell.

quarta-feira, 13 de junho de 2018

Backup e Restore utilizando o I/O padrão (STDIO) - Informix

O Ontape permite utilizar o STDIO para operações físicas de backup e restore. Durante o backup, o ontape pode gravar dados no STDOUT. Durante o restore, o ontape pode ler o STDIN. O ontape utiliza pipes como um mecanismo de buffer de memória fornecido pelo sistema operacional para executar backup e restore utilizando o STDIO. As vantagens de utilizar o STDIO com o ontape são:
  • Nenhuma operação de leitura ou gravação para mídia de armazenamento é necessária (se você decidir direcionar diretamente os dados de  backup para uma operação de restauração).
  • Você pode usar os utilitários do sistema operacional para compactar os dados de backup antes do armazenamento.
  • Você pode enviar os dados de backup por meio de qualquer utilitário.
  • Você pode criar um servidor de banco de dados, restaurando imediatamente os dados em outro servidor, como configurar um servidor secundário (HDR) ou (RSS).
Configure o valor do parametro TAPEDEV como STDIO.

Os parâmetros de configuração TAPEBLK e TAPESIZE não são utilizados para fazer backup usando o STDIO. No entanto, o valor de TAPEBLK ainda é usado para a transferencia de dados entre o servidor de banco de dados e o processo ontape. O parametro TAPESIZE não é usado, porque a capacidade de STDIO é assumida como ilimitada.

O backup utilizando o STDIO é gravado diretamente no STDOUT. Portanto, o fluxo de dados precisa redirecionar para um arquivo. Caso contrario, o fluxo de dados sera enviado para a tela. Ao redirecionar o STDOUT para um arquivo, certifique-se que há espaço suficiente disponível no file system. Mensagens de erros e informações são gravadas no STDERR.

ontape -s -L 0 > /informix/backup/archive_L0


Executa o backup de nivel 0 utilizando o STDIO. O stdout do comando ontape é redirecionado para um arquivo chamado archive_L0 no diretório /informix/backup. O comando é o mesmo que o backup físico padrão ontape, exceto neste cenário, o sistema operacional manipula o fluxo de dados para o arquivo de saída.




ontape -s -L 0 | compress -c > /informix/backup/archive_L0

Executa backup de nivel 0, em que o comando ontape é redirecionado para um canal e os dados são compactados antes de serem gravados nos nomes de arquivos archive_L0 no diretorio /informix/backup.

O Backup e a restauração do lógico log não são compatíveis com o ontape usand o STDIO. No entanto, se houver backups de lógico logs padrao disponíveis, eles poderão ser restaurados usando o comando ontape -l após uma restauração fisico do ontape utilizando o STDIO. Alem disso, o salvamento de lógico logs não é possivel durante o processo de restauração. Portanto voce deve salvar manualmente todos os logs usando o comando ontape -S antes de executar uma restauração utilizando STDIO.

Durante a restauração padrão, o ontape imprime informações para stdout, mas com STDIO, as mensagens são omitidas. Da mesma forma, após restaurar um backup de nível 0,  o ontape solicita a restauração de backups de nível 1 e nível 2. Ma durante uma restauração para STDIO, esses prompts são omitidos. Em vez disso, o fluxo de entrada é varrido para mais dados. Se mais dados forem encontrados, o próximo nível de backup poderá ser restaurado. Portanto, todos os dados necessários devem fazer parte do fluxo de entrada para o comando de restauração, e os dados devem estar na ordem correta. 

cat /informix/backup/archive_L0 /informix/backup/archive_L1 | ontape -p

A função STDIO permite clonar um servidor de banco de dados Informix ou configurar rapidamente o HDR executando um backup simultâneo  para stdout e restaurando de stdin. Se o backup e restauração forem feitos apenas para duplicar um servidor de banco de dados Informix, use a opção -F para evitar que o archive seja salvo. Durante o backup e a restauração simultâneos, embora um backup seja feito, ele não pode ser restaurado posteriormente porque o backup não é salvo em um dispositivo de armazenamento; os dados de backup serão transferidos para outro sistema através de um pipe e, usando uma operação rsh, os dados serão imediatamente restaurados para outro sistema.

ontape -s -L 0 -F | rsh serverB "ontape -p"

O backup ontape nivel 0 é executado na maquina local. Os dados são canalizados para stdout em uma máquina remota chamada serverB usando o utilitário do sistema operacional rsh e uma restauração física é executada na máquina remota.
O Comando ontape ignora a opção -F se TAPEDEV não estiver configurado como STDIO. A opção ontape -F com a configuração STDIO significa que as informações do arquivo não são registradas nas paginas reservadas.

quarta-feira, 6 de junho de 2018

ORACLE - OPTIMIZER_INDEX_COST_ADJ

PROPRIEDADES, DESCRIÇÃO

Parameter type, integer
Default value, 100
Modifiable, ALTER SESSION - ALTER SYSTEM
Range of Values, 1 to 10000

OPTIMIZER_INDEX_COST_ADJ - permite ajustar o comportamento do otimizador para que a seleção do caminho de acesso seja mais ou menos amigável ao índice, ou seja, tornar o otimizador mais ou menos propenso a selecionar um caminho de acesso ao índice em uma varredura completa da tabela.

O padrão para esse parâmetro é 100%, no qual o otimizador avalia os caminhos de acesso ao índice no custo regular. Qualquer outro valor faz com que o otimizador avalie o caminho de acesso nessa porcentagem do custo regular. Por exemplo, uma configuração  de 50 faz com que o caminho de acesso ao índice pareça tao caro quanto o normal.

segunda-feira, 28 de maio de 2018

Status e informações sobre o Banco de Dados Oracle


conn sys/oracle as sysdba ou sqlplus sys/oracle as sysdba

Localizar o spfile

SHOW PARAMETER spfile;

no prompt do SO

vi /opt/oracle/product/12cR1/db/dbs/spfileajmsolutions.ora

Diferenciar o tipo de escopo com o SPFILE - SPFILE fica ativo somente em memória

SHOW PARAMETER db_cache_size;

ALTER SYSTEM SET db_cache_size=32m SCOPE=memory;

SHOW PARAMETER db_cache_size;

SHUTDOWN IMMEDIATE;

STARTUP;

SHOW PARAMETER db_cache_size

Diferenciar o tipo de escopo com o SPFILE - SPFILE fica ativo a partir do próximo startup


ALTER SYSTEM SET db_cache_size=32m SCOPE=spile;

SHOW PARAMETER db_cache_size;

SHUDOWN IMMEDIATE;

STARTUP;

SHOW PARAMETER db_cache_size;

Diferenciar o tipo de escopo com o SPFILE - BOTH (fica ativo na memória e a partir do proximo startup


ALTER SYSTEM SET db_cache_size=32m SCOPE=both;

SHOW PARAMETER db_cache_size;

SHUTDOWN IMMEDIATE;

STARTUP;

SHOW PARAMETER db_cache_size;

Alguns parâmetros necessitam de um SHUTDOWN


ALTER SYSTEM SET log_archive_start=true; /*(erro)*/

ALTER SYSTEM SET log_archive_start=true SCOPE=spfile;

ALTER SYSTEM SET sag_max_size=256m SCOPE=spfile;

SHUTDOWN IMMEDIATE;

STARTUP;

SHOW PARAMETER SGA_MAX_SIZE;

SHOW PARAMETER log_archive_start;

Verificar estados do Banco / Mudar os estados do banco

SHUTDOWN IMMEDIATE;

STARTUP NOMOUNT;

SELECT instance_name, host_name
FROM v$instance;

SELECT name, open_mode
FROM v$database; /*(erro)*/

STARTUP MOUNT; /*(erro)*/

ALTER DATABASE MOUNT;

SELECT name, open_mode
FROM v$database;

SELECT owner, table_name
FROM dba_tables
WHERE owner = 'AJMSOLUTIONS'; /*(erro)*/

ALTER DATABASE OPEN;

SELECT owner, table_name
FROM dba_tables
WHERE owner = 'AJMSOLUTIONS';

ALTER DATABASE MOUNT; /*(erro)*/

SHUTDOWN IMMEDIATE;

STARTUP MOUNT;

Subir o Banco como somente leitura


ALTER DATABASE OPEN READ ONLY;

CREATE TABLE teste (id number); /*(erro)/

SHUTDOWN IMMEDIATE;

STARTUP;

CREATE TABLE teste (id number);

Subir Banco em modo restrito 

conn sys/oracle as sysdba;

SHUTDOWN IMMEDIATE;

STARTUP RESTRICT;

abrir uma sessão com ajmsolutions /*(erro)*/

sqlplus ajmsolutions/ajmsolutions

SHUTDOWN IMMEDIATE;

STARTUP;

abrir 2 sessões uma com o sys e outra com o ajmsolutions
na sessão do sys

Matar sessão dos usuários

na sessão do sys

SELECT sid, serial#, username
FROM v$session
WHERE username IS NOT NULL;

ALTER SYSTEM KILL SESSION 'sid,serial#';

ir na sessão do ajmsolutions e tentar fazer alguma coisa


Para testar os vários tipos de shutdown

Abrir duas sessões uma com o SYS e outra como AJMSOLUTIONS

na sessão do SYS

SHUTDOWN;

---------------------------------------

na sessão do AJMSOLUTIONS

CREATE TABLE xpto (ID NUMBER);
INSERT INTO xpto (1);

COMMIT;

Observar o que acontece na sessão do SYS.

exit

---------------------------------------

na sessão SYS

STARTUP;

--------------------------------------

Abrir a sessão do AJMSOLUTIONS

--------------------------------------

na sessão do SYS

SHUTDOWN TRANSACTIONAL

---------------------------------------

na sessão do AJMSOLUTIONS

INSERT INTO XPTO VALUES (1);
COMMIT;

---------------------------------------
na sessão do SYS

Observar o que acontece na sessão do SYS

STARTUP;

SHUTDOWN ABORT;

STARTUP FORCE;

Arquivo de alerta / rastreamento

SHOW PARAMETER background_dump_dest   /* (arquivo de alerta/arquivo de rastreamento - processo de segundo plano) */

No Sistema Operacional

#> vi /opt/oracle/diag/rdbms/ajmsolutions/AJMSOLUTIONS/trace/alert_AJMSOLUTIONS.log

#> cd /opt/oracle/diag/rdbms/ajmsolutions/AJMSOLUTIONS/trace

#> ls -a

Listar todas as views de desempenho dinâmico


SELECT name
FROM v$fixed_table
WHERE name LIKE 'V$%'
ORDER BY 1;

Listar todas as views de dicionário de dados DBA_

SELECT object_name
FROM dba_objects
WHERE object_name LIKE 'DBA_%'
ORDER BY 1;

Listar todas views de dicionários de dados ALL_

SELECT object_name
FROM dba_objects
WHERE object_name LIKE 'ALL_%'
ORDER BY 1;

Listar todas as views de dicionário de dados USER_


SELECT object_name
FROM dba_objects
WHERE object_name LIKE 'USER_%'
ORDER BY 1;