Sistema de Arquivos: Instalar o Oracle no Solaris

Conclua os seguintes procedimentos antes de instalar o Oracle em um sistema Solaris:
1.Efetue login no sistema Solaris como raiz.

2.Assegure-se de que a definição dos parâmetros de kernel para o sistema atenda ou exceda os valores necessários para a instalação. Consulte o Oracle 8i Installation Guide para obter informações adicionais.

3.Crie pontos de montagem para utilizar com os bancos de dados do Oracle:
$ mkdir /u01
$ mkdir /u024.Inicie o utilitário admintool a partir de um console, utilizando o seguinte comando:
# admintool5.Na janela Admintool, clique em Procurar -> Grupos. A janela Admintool:Grupos é aberta.

6.Na janela Admintool:Grupos, clique em Editar -> Incluir. A janela Admintool:Incluir Grupo é aberta.

7.Crie dois grupos; um grupo de usuários chamado dba e um grupo de usuários chamado oinstall.

8.Na janela Admintool:Grupos, clique em Procurar -> Usuários. A janela Admintool:Usuários é aberta.

9.Utilize o admintool para criar um novo usuário chamado Oracle. Conclua as etapas a seguir para a nova conta de usuário.
a.Defina o Grupo Principal da conta como o grupo oinstall que você criou.
b.Defina o Grupo Secundário da conta como o grupo dba que você criou.
c.Assegure-se de que o botão de opções ao lado do campo Criar Diretório Inicial esteja selecionado. No campo Caminho, insira /export/home/oracle como o diretório inicial do usuário Oracle.
d.Defina o Shell de Login para /bin/sh.
O instalador do Oracle deve ser executado nesta conta. Essa conta será utilizada apenas para instalação e manutenção do Oracle.

10.Conecte-se ao sistema como o usuário Oracle:
# su - oracleExiba as definições da máscara do usuário para a conta Oracle.
$ umaskA máscara do usuário deve ser definida como 022. Se a máscara do usuário da conta não estiver definida como 022, defina-a com o seguinte comando:
$ umask 022Modifique também .profile para refletir a alteração.

11.Adicione o seguinte em /export/home/oracle/.profile para a conta Oracle:
◦Oracle 8i:
ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/8.1.7; export ORACLE_HOME
ORACLE_SID=or1; export ORACLE_SID
ORACLE_DOC=$ORACLE_HOME/doc; export ORACLE_DOC
ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data; export ORA_NLS33
PATH=$ORACLE_HOME/bin:/usr/bin:/usr/local/bin:/usr/ccs/bin:/usr/ucb:/usr/openwin/bin:.
◦Oracle 9i:
ORACLE_BASE=/u01/app/oracle; export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/9.2.0.0.0; export ORACLE_HOME
ORACLE_SID=or1; export ORACLE_SID
ORACLE_DOC=$ORACLE_HOME/doc; export ORACLE_DOC
ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data; export ORA_NLS33
PATH=$ORACLE_HOME/bin:/usr/bin:/usr/local/bin:/usr/ccs/bin:/usr/ucb:/usr/openwin/bin:.
Se você necessita de /usr/ucb em seu caminho de pesquisa, certifique-se de que ele seja listado após /usr/ccs/bin na definição PATH.

12.Crie o perfil utilizando o seguinte comando:
$ . ./.profileAgora você está pronto para começar a instalação do Oracle. Consulte a documentação apropriada do Oracle e instale o software. Após uma instalação bem-sucedida, retorne às instruções de configuração contidas nesta seção.

Solaris 10 Container: Uma visão geral em vídeo

Recuperando Bad Superblock

Quando um file system encontra-se danificado é possível restaura-lo, exceto se o file system for o root (/).

Quando isto acontece é necessário realizar um dos passos abaixo:

* Reinstalar o Sistema Operacional

* Boot da Rede ou CD-Rom

* Recriar o file system root (/) com newfs e restaurá-lo de um backup.

Determinando um bad superblock no file system / ou /usr.
De um CD local realizamos os passos abaixo.

ok boot -s cdrom

Através da rede de um install server

ok boot -s net

Após, desmonte o file system danificado se o mesmo não for o / ou /usr.

# umount /opt
# newfs -N /dev/rdsk/c0t3d0s7
/dev/rdsk/c0t3d0s7: 163944 sectors in 506 cylinders of 9 tracks, 36 sectors
83.9MB in 32 cyl groups (16 c/g, 2.65MB/g, 1216 i/g)
super-block backups (for fsck -b #) at:
32, 5264, 10496, 15728, 20960, 26192, 31424, 36656, 41888,
47120, 52352, 57584, 62816, 68048, 73280, 78512, 82976, 88208,
93440, 98672, 103904, 109136, 114368, 119600, 124832, 130064, 135296,
140528, 145760, 150992, 156224, 161456,
# fsck -F ufs -o b=5264 /dev/rdsk/c0t3d0s7
Alternate superblock location: 5264.
** /dev/rdsk/c0t3d0s7
** Last Mounted on
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
36 files, 867 used, 75712 free (16 frags, 9462 blocks, 0.0% fragmentation)
/dev/rdsk/c0t3d0s7 FILE SYSTEM STATE SET TO OKAY

***** FILE SYSTEM WAS MODIFIED *****
#

OBS.: Outras opções para o fsck:

fsck -m

verifica se um file system pode ser montado

fsck -y

assume como “yes” para todos os reparos

fsck -n

assume como “no” para todos os reparos

fsck -o p

preens file system, repara todas inconsistências esperadas, mas retorna ao prompt se um sério problema for encontrado.

Gerênciando swap

Para criar-mos uma nova partição raw swap, após criado o device (type swap), adicione a seguinte entrada em /etc/vsftap

/dev/dsk/c0t1d0s0 - - swap - no -

Depois habilitando a nova partição

# swap -a /dev/desk/c0t1d0s0

Pode adicionar uma novo área de swap através de um arquivo de swap.

# mkfile 250m /opt/myswapfile
# swap -a /opt/myswapfile
# echo “/dev/dsk/c0t1d0s0 - - swap - no -” >> /etc/vsftab

Desativando um

swap space

# swap -d /opt/myswapfile

Exibindo informações mais detalhadas da área de swap.

# swap -s
total: 402456k bytes allocated + 97104k reserved = 499560k used, 1643728k available

Neste momento verificamos que o uso real da swap é de 499560k, onde 97104k estão reservados para uso futuro e 402456k é a utilização real no momento.
O espaço livre é de 1643728k.

Para obter detalhes individuais de cada device.

# swap -l
swapfile dev swaplo blocks free
/dev/md/dsk/d20 85,20 16 4202672 3489392

Onde swapfile indica device ou arquivo de swap, a coluna deve informa o maior e menor número para o device e 0 quando for arquivo.
Em blocks temos o tamanho total da swap (blocos de 512 bytes). Finalizando em free é a quantidade de espaço livre na área de swap também em blocos de 512 bytes.

Troubleshooting snmpdx

Há pouco tempo encontrei o seguinte log no /var/adm/messages em alguns servidores Solaris 8, fazendo com que o file system /var chega-se em 100% várias vezes.

May 5 21:01:05 sserver8 /usr/lib/snmp/snmpdx: [ID 702911 daemon.error] session_open() failed for a pdu received from localhost.55659
May 5 21:01:05 sserver8 /usr/lib/snmp/snmpdx: [ID 702911 daemon.error] community_check();bad community from localhost

Realizei os seguintes procedimentos.

* Verifiquei o /etc/hosts, em busca de entradas duplicadas.

127.0.0.1 localhost

10.0.0.11 sserver8

* Alterei as seguintes linhas abaixo no arquivo /etc/snmp/conf/snmpd.conf.

system-group-read-community S89priv

trap-community S89priv

managers localhost snmpman

* Depois realizei a seguinte configuração em /etc/snmp/conf/snmpdx.acl

acl = {

{

communities = public

access = read-only

managers = *

}

}

Nota: S89priv é o nome da comunidade

* Após isto é necessário realizar um restart do serviço

/etc/rc3.d/S76snmpdx stop

/etc/rc3.d/S76snmpdx start

E por fim você irá constatar que as mensagens de erro não mais ocorrem.

tail -f /var/adm/messages.

Espero que a dica tenha sido útil.

Usando UFS Snapshots

Backup é realizado enquanto o file system está montado, onde criamos um read-only file system (imagem de um file system temporário) destinado para operações de backup.

Criando um USF Snapshot, com limite de 500M para o arquivo backing-store

# fssnap -F ufs -o maxsize=500m,bs=/scratch/usr.back.file /export/home
/dev/fssnap/1

Listanto snapshot currente

# /usr/lib/fs/ufs/fssnap -i
Snapshot number : 0
Block Device : /dev/fssnap/0
Raw Device : /dev/rfssnap/0
Mount point : /export/home
Device state : idle
Backing store path : /var/tmp/bs.file
Backing store size : 0 KB
Maximum backing store size : Unlimited
Snapshot create time : Wed Aug 29 15:22:06 2001
Copy-on-write granularity : 32 KB

Para exibir a informação de um determinado file system, basta

# /usr/lib/fs/ufs/fssnap -i /usr

Excluindo um UFS snapshot

# fssnap -i
0 / 1 /usr
# fssnap -d /usr
Deleted snapshot 1.
# rm /scratch/usr.back.file

Realizando backup de um USF snapshot

Para backup full:

# ufsdump 0ucf /dev/rmt/0 /dev/rfssnap/1

Verificando o backup

# ufsrestore tf /dev/rmt/0

Para backup incremental:

# ufsdump 1ufN /dev/rmt/0 /dev/rdsk/c0t1d0s0 `fssnap -F ufs -o raw,bs=/export/scratch,unlink /dev/rdsk/c0t1d0s0`

Verificando o backup

# ufsrestore ta /dev/rmt/0

Realizando backup com tar

# mount -F ufs -o ro /dev/fssnap/1 /backups
# tar cvf /dev/rmt/0 /backups

Consumo elevado de CPU

O principal foco deste artigo é obter informações sobre uma sessão no Oracle que esta consumindo muito recurso de CPU no sistema operacional em ambiente UNIX.

O DBA que tiver conhecimentos em UNIX/Linux estará mais à-vontade devido aos termos técnicos e as ferramentas utilizadas. É fundamental deixar claro que este artigo é somente uma das ações que podem ser tomadas para o processo de tuning de um Banco de Dados e SO. Tuning de sistema operacional é um assunto muito complexo e ao longo do tempo colocarei mais artigos sobre outras matérias.

Quando você tem um banco de dados Oracle em ambiente Windows, existe a restrição quando é necessário fazer o tuning relacionado ao sistema operacional porque somente é possível visualizar um processo oracle.exe e não os threads que ele inicia. Com as ferramentas padrão do Windows não é possível ir muito a fundo no que esta acontecendo com um processo. Isso não acontece em ambientes UNIX/Linux devido às diversas ferramentas já disponíveis por padrão. Algumas delas em: Solaris – sar (sar 2 100), prstat –T, vmstat 2 100, iostat 2 100 Linux – top AIX – topas, top Os principais para CPU são sar, prstat, top e topas. Para determinar se as CPU’s em um sistema esta carregada, pode-se utilizar no Solaris o sar 2 100. O resultado é o seguinte:

SunOS 5.9 Generic_118558-28 sun4u 01/12/2007
11:21:11 %usr %sys %wio %idle
11:21:13 64 24 6 5
11:21:15 55 17 25 3

A coluna IDLE significa que a maquina esta somente 3% ociosa, logo esta bem carregada. Em ambientes com top, é possível visualizar este campo IDLE na barra superior de detalhes. A interpretação é a mesma do sar. Quanto maior o IDLE mais ociosa a máquina esta. Agora que sabemos que a maquina esta muito carregada, devemos identificar quais processos estão consumindo um maior numero de CPU. Para isso podemos utilizar ou o prstat, top ou topas, dependendo do SO. No caso do Solaris, temos como exemplo o prstat –T:

PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
11238 oracle 58M 48M sleep 0 0 0:36:49 42% oracle
13459 oracle 76M 1031M sleep 29 0 0:01:45 6.7% oracle
111239 oracle 690M 660M sleep 35 0 0:11:39 4.0% oracle
116328 oracle 1076M 1029M sleep 59 0 0:00:00 0.4% oracle
12052 oracle 687M 650M sleep 59 0 0:06:15 0.3% oracle

Neste caso temos um processo consumindo 42%. Em alguns casos é comum a carga da máquina esta bem alta, mas nenhum processo com esta quantidade de uso de CPU. Pode acontecer vários processo de 6 ou 7% que acabam impactando na performance.Neste caso, utilizaremos como principal culpado pelo alto consumo de CPU o processo 11238, dado pela coluna PID. Note que a coluna TIME também é de fundamental importância. Pode haver processos como no exemplo abaixo:
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
11238 oracle 62M 52M cpu2 0 0 0:39:10 9.8% oracle
11239 oracle 690M 660M sleep 49 0 1:11:52 8.9% oracle
12689 oracle 685M 658M sleep 59 0 0:44:51 0.5% oracle
2052 oracle 687M 650M sleep 59 0 0:06:17 0.5% oracle

Neste caso é melhor investigar primeiramente o processo 11239 porque seu tempo de processamento esta muito alto. Agora que já sabemos identificar se a maquina esta com processamento elevado e o processo conhecido como “Top CPU Consumer”, podemos investigá-los no banco.Vamos trabalhar com o PID 11238 para os exemplos a seguir.Utilizando o SQL*Plus, vamos primeiramente descobrir mais sobre esta sessão no banco de dados com a seguinte query:

SQL> SELECT SID, serial#, username, program, sql_hash_value, osuser,machine, taddr,lockwait, statusFROM v$sessionWHERE paddr = (SELECT addrFROM v$processWHERE spid = 11238);

Principais campos:
Sid = Utilizado para join com outras tabelas.
Sql_hash_value = Id da query que esta sendo executada Osuser,
machine = Ajuda na identificação de qual usuário esta conectado e consumindo recursos

.Note que a coluna spid da tabela v$process é o PID do SO. Agora que sabemos qual é a sessão no banco que esta consumindo mais recursos, é possível rastrear todo o restante da sessão. Para verificar a query que esta sendo executada pela sessão que mais esta consumindo CPU, execute a seguinte query:

SQL> select sql_text from v$sql Where hash_value = HASH_VALUE

Este parâmetro HASH_VALUE vem da query anterior executada para obter as informações sobre a sessão do usuário. É possível também obter os dados sobre a execução da query com a seguinte query:

SQL> select EXECUTIONS, LOADS, INVALIDATIONS, PARSE_CALLS, DISK_READS, BUFFER_GETS, ROWS_PROCESSED
From v$sql Where hash_value = HASH_VALUE;

Fique preocupado se algum destes campos vier com valor alto. Como já foi obtido a query, você agora pode fazer um explain para verificar se algo precisa ser reescrito ou se é preciso criar algum índice. Uma das views mais importantes do banco para realizar tuning é a v$session_wait.

Eu não vou entrar em muitos detalhes de como utiliza de forma efetiva neste artigo, mas como foi obtido o SID na primeira query sobre os detalhes sessão, verifique qual “EVENT” esta ocorrendo para esta sessão. Pode ser bem eficiente. Segue exemplo:

SQL> select sid,event,p1,p2,p3 from v$session_wait where sid = SID;

Nem sempre a query/sessão que esta consumindo mais recursos de CPU é a responsável por problemas de desempenho no banco. Lembre-se de que um servidor de banco tem fatores muito importantes como acesso a memória e principalmente disco. Vamos ver isso nas próximas postagens