Menu de navegação

[ramasineParticipante]

Olá amigos,

Uma dúvida,

É recomendado termos no mesmo disco, datafiles de indices e dados, redologs e tambem os logs de archive?
Isso não vai me gerar uma contenção de disco? Comprometer de alguma forma a meu nível de escrita e leitura nesse cara?
Minimamente nos redos eu não os teria que multiplexar??

Tipo:

‘u06/oracle/oradata/xxx/redo03.log;
‘u06/oracle/oradata/xxx/redo02.log;
‘/u06/oracle/oradata/xxx/redo01.log;
‘/u06/oracle/oradata/xxx/temp01.dbf’
‘log_archive_dest=’/u06/oracle/oradata/xxx/archive’

Oracle 8.1.7.4 em Solaris

Agradeço qq indicação

Marcelo

[rmanParticipante]

@ramasine

Você trabalha com discos locais ou é storage?

[ramasineParticipante]

Storage….com politica de backup por BCV…

[rmanParticipante]

@ramasine

Bom, então estamos falando de storage, se é storage, existe um RAID. O RAID vai proporcionar desempenho e segurança, cada arquivo vai estar espalhado e replicado em vários discos. Pensando em desempenho o RAID vai cuidar disso, sobre a segurança, o seguro morreu de velho, então o ideal é trabalhar com várias partições.

Você pode adotar o seguinte modelo de partições:
– binario do oracle
– redo log + control file + datafile de undo, temp, sysaux, system e users
– redo log + control file + datafile de dados
– redo log + control file + datafile de índices
– archive log
– backup

A partição de archive log e backup deve estar isolada do resto, afinal, se estiver junto e você perder a partição, como fará o restore/recovery?

Realmente multiplexar redo log e control file é fundamental, isso evita dores de cabeça, as vezes um simples cp resolveria tudo se estivesse multiplexado.

[Victor ArmbrustMestre]

Pessoal,

Essa pergunta veio em um momento bastante oportuno. Olha que interessante essa discussão iniciada pelo Fábio Prado: http://www.fabioprado.net/2012/07/perfo … rados.html

O legal que tem comentários de outros especialistas da área…

Confiram lá, é bastante interessante.

Mas lembrem: Quando se fala em armazenamento (no caso Storage via FC ou iSCSI) existem outros pontos a se observar, até porquê serão LUNs compostas de vários discos, que terão seu I/O distribuído. Não se pode pensar apenas em FILESYSTEMS ou TABELAS x ÍNDICES. Fiquem atentos!!

Abss
Victor

[Regis AraujoParticipante]

Ola Senhores.. bom dia..!!

Somente complementando o que todos já disseram..

A situação de separar indices e dados em muitos casos vai do DBA.. eu especialmente sou a favor do que o Victor disse, usar tablespace de INDICES com blocos de 16k ou 32k.. mas lembrando que se for usar blocos diferentes para indices devera também alterar os parametros db_16k_cache_size para blocks de 16k e o db_32k_cache_size para blocos de 32ks…

Também pode-se separar os REDOS e ARCHIVES em discos mais rapidos.. outro quesito é o tipo de RAID usar.. 5 ou 10.. eu prefiro RAID 10.. mas há muita gente que prefere RAID 5.

São tantos fatores.. que creio que daria um otimo tema para qualquer café com GPO.. Cada um falando de suas experiências nestes quesitos..

Este é um assunto que me chama muito a atenção e que me agrada muito..

Muitos profissionais de TI acham que DBA só precisa saber de banco, mas o que eles não entendem é que o banco é (HARDWARE+SOFTWARE), envolve toda a infra-estrutura que está diretamente ou indiretamente ligado ao servidor.. Até a decisão de usar ou não JUMBO-FRAME em alguns switchs que trafegam os backups é um quesito para se levar em conta…

Bom.. como eu disse.. é um otimo tema para um forum especifico…

Abraços..!

[ramasineParticipante]

Obrigado pela ajuda de todos!
E concordo em gênero, número e grau contigo, o tema vale mesmo um Café com GPO!!!

[Fábio PradoParticipante]

Pessoal, há 2 meses atrás migrei Bds de produção de 10G para 11G, em máquinas novas, mudando também de armazenamento em disco para storage. Os datafiles e archives estão sendo armazenados em LUNs na storage com RAID 5. Como os discos dos servidores ficariam subutilizados, definimos a gravação dos redo logs, control files e datafiles dos tablespaces TEMP e UNDO nos discos locais, que já estavam configurados com RAID 1!

Pelo que eu andei pesquisando, acredito que existe uma possibilidade de eu ter um desempenho melhor separando dados e logs em storage e disco local, mas nao foi por este motivo principal que fizemos a separação!

Gostaria de ouvir tbém a opinião de DBAs mais experientes a respeito desta separação! Aí Victor/Portilho, é com vcs!

[]s

[Victor ArmbrustMestre]

Bom,
Eu não costumo usar discos locais para NADA (exceto Binários – $ORACLE_HOME, $GRID_HOME, etc). Nem acredito que essa seja recomendação. Nunca vi nada relacionado a isso em documentação Oracle, pelo contrário, sempre defendendo a teoria de usar storage dedicado, e preferencialmente com RAID 0+1 (ou RAID 10).

Eu particularmente não acho que um disco local possa ter mais performance ou segurança que um RAID definido em um storage (A menos que este storage seja algum produto muito ruim). Com os maiores vendos do Mercado (EMC, NetAPP, HP, etc) sempre pode-se obter melhor performance e segurança, MAS CLARO, montando uma configuração de nº de discos, RAID, FC ou iSCSI, etc.. de modo compativel com a necessidade e workload de cada Database.

Talvez se persarmos em um Banco de 1Gb ou 10Gb pode ser uma solução aceitável, onde o backup é pequeno, a disponibilidade é baixa etc. Pensando em Bancos maiores e produtivos (900GB, 1TB, 10TB, 40TB, etc) isso seria EXTREMAMENTE inviável.. é sempre importante pensar nesse sentido…

Para quem tiver interesse de ler, segue um post relacionado à isso.

opção 1: https://profissionaloracle.com.br/blogs/ … -praticas/
opção 2: http://victor-dba.blogspot.com.br/2012/ … ticas.html

Abs
Victor

[Fábio PradoParticipante]

Victor,
Obrigado pela resposta… então agora vamos debater… rsrsrss

 No meu caso, não posso usar RAID 1+0 ou 0+1 no Storage pq o custo de armazenamento é muito alto nestes métodos de armazenamento. De acordo com o seu próprio artigo a gente tem uma perda de 50% de espaço de armazenamento , enquanto que no RAID 5, perde-se em média 20%. O motivo que me levou a usar RAID 5 foi o custo do armazenamento. Eu tive que optar por ele para garantir que a Storage tenha capacidade p/ armazenar os dados dos Bds que administro em uma projeção de até 5 anos. Se eu implementasse as outras opções comentadas, eu não conseguiria atender este pré-requisito. O motivo de eu colocar logfiles, controlfiles, archives e tablespaces de UNDO e TEMP em disco tbém foi o mesmo.

Outro ponto... pesquisando pela internet a gente pode encontrar vários artigos que comentam que separar os redologfiles e datafiles em discos diferentes podem melhorar a performance (veja por exemplo <a href="http://ora10g.com/7_4_redolog.html" />http://ora10g.com/7_4_redolog.html</a>), porém é possível notar que estes artigos não contemplam um cenário onde a gente tem um Storage para armazenar os arquivos do BD. Com um storage, a situação pode ser diferente, pois o storage tem RAID, cache e tecnologias de armazenamento mais avançadas que os discos locais de armazenamento de um servidor, porém será que mesmo com Storage, logicamente falando, para vc não faz sentido que separar os logs dos datafiles em outros discos (no meu caso, datafiles em storage e logs em discos locais do servidor) pode ter um pequeno ou mínimo ganho de performance? 

[]s

Fábio Prado
http://www.fabioprado.net

[Paulo ReisParticipante]

Prezados,

Levando em consideração storages como Netapp e 3Par, que particionam todos os discos em partes de 256MB ou 512MB para criar uma LUN e associar um volume a esta LUN, não vai importar se você criar um volume para cada redo/archive/data/index. O storage irá gravar os dados em todos os discos.
Desta forma, ficaria apenas a organização do banco e a velocidade da sua conexão com o Storage.

Para storages que criam volumes a partir de discos físicos específicos, aí sim seria interessante fazer a separação.
Separar 2 ou 3 discos para cada volume e fazer raid 1 ou 5 de acordo com a necessidade.
Assim sendo, separaríamos o IO de disco e melhoraríamos a performance do banco.

Pode-se utilizar também discos SSD em raid 1 para redo log e archive log. Já ajuda bastante.

[rmanParticipante]

@fbifabio

Minha opinião é a seguinte, se você possui um storage, não faz sentido se arriscar a trabalhar com discos locais, o storage é mais seguro e tem mais performance, o disco local pode morrer a qualquer momento. A morte do disco também pode acontecer no storage? Claro que pode, e isso acontece, mas o RAID oferece mais segurança, dependendo do storage, o disco morre e você nem percebe, pois o reparo é automático.

Logfiles, controlfiles, archives e tablespaces de UNDO e TEMP. Isso consome muito? Realmente não cabe no storage? Talvez a estrutura do storage precisa ver revista e dimensionada novamente.

O fato de dividir em várias partições está mais para segurança do que desempenho. Caso houver uma perda de partição, a perda vai ser menor, e mais fácil de recuperar.

[Victor ArmbrustMestre]

Fábião

Como a galera citou ai, e é a mesma opinião que eu já defendi ali atrás, o armazenamento em storage é mais eficiente devido a tudo que já explicado ali atrás.
Quando a usar RAID5, no seu cenário foi o que realmente deu pra fazer, legal, sem problemas. Usar disco local para armazenar parte do Database não é uma melhor prática, até pq se vc perder essa máquina, vai perder uma parte do seu Database.

Enfim, tem “n” maneiras de fazer esse ambiente, o legal é tentar deixar tudo no storage.

Victor

[Fábio PradoParticipante]

Valeu pessoal pelas respostas!

Vou avaliar tudo o que foi comentado aqui e fazer algumas alterações! Temos a flash recovery area em storage, vou mudar ela para ficar em disco local, pq ai sim consigo espaço para o nosso planejamento de armazenamento de dados para 5 anos! Infelizmente a nossa storage é pequena pq havia pouco investimento para comprar tudo o que precisamos armazenar!

[Autor]

Posts