Menu de navegação

[jp_centecParticipante]

#Oracle 10g
#Solaris 8
#sparcv9

Olá a todos, primeiramente parabéns pelo ótimo forum.

Minha questão e a seguinte:

Foi necessário aqui na empresa atualizar uma base de teste com a base de produção de um cliente. O problema é que não havia mais espaço em disco no servidor, como se trata de um projeto, não foi autorizada a compra de mais disco para o servidor. No entanto a necessidade precisava ser atendida de qualquer maneira(coisas de empresa, não interessa se não tem como fazer, apenas faça).

A minha idéia então foi aproveitar o disco de um servidor linux(asianux 2.0). Montei um servidor NFS no linux e parti para montar a partição no solaris, me deparei com alguns problemas que foram sanados com os parâmetros corretos no mount, por último tive um erro na hora de criar os datafiles(que infelizmente não lembro a mensagem)algo que dizia que o arquivo estava ocupado. Resolvi esse problema com mais um parâmetro no muont, o llock.

Até aí tudo bem, porém meu banco caiu 2 vezes com a seguinte mensagem no alert:

ORA-27062 message 27062 not found; No message file for product=RDBMS, facility=ORA
DBW0: terminating instance due to error 27062
Instance terminated by DBW0, pid = 23079

Em um ato meio desesperado eu passei o parâmetro db_writer_processes para 2, e desde de anteontem, eu não tive mais problemas.

A pergunta é:

O que eu fiz tem fundamento ou eu estou tendo sorte?

[Rodrigo AlmeidaParticipante]

JP,

A solução que você adotou “teoricamente” poderia ser realizado sem problemas, porém, em utilizar o NFS para armazenar e acessar os datafiles terá problemas logo de início, como:

1) PERFORMANCE

Todo o acesso que o banco de dados irá realizar e outras operações, terá o problema de lentidão por não ser LOCAL. Mesmo que as máquinas estejam com um cross-over.

2) RECUPERAÇÃO

Esse tipo de solução tem que ter em mente que está correndo risco mais cedo ou mais tarde de problemas de perder o datafile, exemplo, quando o banco de dados tentar fazer um checkpoint nesses datafiles e o NFS não estiver disponivel, ou a máquina que hospeda cair. Não terá um status muito bom nos datafiles da tablespace.

3) Administração

A administração dessa tablespace vai ser problemática, até mesmo para as suas operações de backup, pois senão tem espaço em disco, deve mandar diretamente para FITA ou outro servidor, e terá um tempo maior.

E outra, deixar sobre o NFS nunca é muito confiável.

Sobre os errors que apareceu para ti e os parâmetros adicionados. O Oracle pode ser comportar de maneira estranha nesse tipo de configuração, eu sei que existe um evento que pode ser configurado na instância que permite um “melhor” trabalho da instância com acesso de datafiles por NFS. Isso pode lhe proteger um pouco. Preciso pesquisar o evento correto.

Sobre os DBWrite, bom, é como dito acima, por não ser LOCAL, o background pode levar algum tempo para acessar esse datafile, não somente o DBW, outros como CKPT, GLWR, SMON e PMON pode trazer problemas também… pode ser agora ou uma questão de tempo.

Depende muito também do comportamento da aplicação, I/O, a finalidade da tablespace e etc…

Abraços,.
Rodrigo Almeida

[vieriParticipante]

Dica!

mantenha isso apenas enquanto durar o projeto.

Acho que vc fez das tripas coração, eu simplemente passaria a colocação da empresa para os integrantes do projeto, o problema é da empresa e
deles, pensa bem se vc precisa fazer uma obra e o sujeito não compra, os materias adequados, vc vai construir de qualquer maneira sujeito a cair o muro o telhado, a qq momento, e mais ou menos assim que irá ocorrer com o Oracle.Ta arriscado dps desse trabalho todo que vc teve vc perder o banco por algum motivo e ainda colocarem a culpa em vc que fez um bom trabalho! apesar de não-padrão.

Provavelmente o Oracle terá um esforço extra para administrar
o overhead disso, não vejo problemas em aumentar os parâmetro
que envolvam background e processes.

[]s

[jp_centecParticipante]

Obrigado pelas resposta.

Rodrigo, a performance e a recuperação não me preocupa muito pois se trata de uma base de testes, já administração, essa sim é suada e ingloria como já pude perceber.

Vieri, a ideia é exatamente essa. O que tira meu sono, é, quanto esse projeto vai durar. Por que como o Rodrigo disse, eu não posso me descuidar nem um segundo da máquina que tem o NFS rodando.

A única coisa que eu pude fazer para me garantir foi mandar um e-mail do porteiro ao presidente, relatando a situação.

Tirando as soluções obvias, que são trocar o servidor ou colocar mais disco na máquina, passa pela cabeça de vocês outra solução para esse caso.

Obrigado mais uma vez.

João Paulo Lopes – DBA

[David SiqueiraParticipante]

Cara como essa base veio de um local externo (cliente) eu checaria por exemplo se elas não estão superdimensionadas, ou seja, ocupando mais espaço do que precisam, e se é uma base de TESTE apenas, ela não precisa de toda a carga de dados, a não ser que seja para fins de homologação e testes de TEMPO de execução de determinados procedimentos, caso essas opções sejam negativas, sugiro que você deize apenas uns 3 meses de dados das tabelas do sistema, é claro que para tal vc terá que carregar primeira mente todo o DUMP, porém possa ser que depois dessa “ENXUGADA” na base o espaço seja compativel com o que você tem disponivel no seu server.
Não sei de todo o seu problema , mais isso seria uma possibilidade que eu tentaria com certeza.

Abraço.

David

[jp_centecParticipante]

Fala David, na verdade esse estudo já está ocorrendo, meu primeiro questionamento nesse caso foi “Mas precisa trazer TUDO isso?” E a resposta foi: Inicialmente sim. Me restou rezar para que um belo corte possa ser feito.
Eu já trabalhei para eliminar ao máximo as fragmentações nas outros datafiles que compõem o banco, afim de maximizar o espaço em disco, mesmo assim a coisa tá feia. Ainda ficaram faltando 15G de espaço.

Valeu pela atenção e desculpem por trazer alguns problemas de negócio para um forum técnico, mas isso faz parte da profissão.

João Paulo Lopes – DBA

[Rodrigo AlmeidaParticipante]

João,

Como o david disse, tu pode realizar algumas tarefas:

1) Realizar um resize para um valor menor do atual.
2) Deixar no NOARCHIVELOG.
3) Colocar a opção de COMPRESS nas tabelas.
4) Matar os índices inapropriados.
5) Verificar se existe tabela TEMPORARIA e dropar!
6) Se o tempo de dados está muito grande no banco, pode realizar QUERY EXPORT das tabelas eliminando os valores mais antigos e deixando o posição apenas de 6 meses para cá.

Abraços,

Rodrigo Almeida

[Autor]

Posts