Menu de navegação

[C-S-RParticipante]

Ola, boa tarde a todos.

Quando estava ouvindo o ultimo Café com GPO referente a piores praticas notei que falaram de criar a TBS_DATA e TBS_INDEX. Que nesse caso nao existe ganho de performace.

Eis que minha duvida veio. Caso as tablespaces estejam em Discos distintos.
Existe o ganho de performace? É relevante esse ganho? Nesse caso é uma boa pratica?

Abraços
Cesar

Obs. Muito bom o Café com GPO

[Marcio68AlmeidaParticipante]

Quando está em ASM ou em Storage não há ganho de performance, apenas facilita a administração, no meu ponto de vista, já que ainda não ouvi o café com GPO a esse respeito.
Se você colocar em discos distintos existe um pequeno ganho de performance sim, pois as gravações serão simultâneas.

[vieriParticipante]

Já vivenciei uma situação aonde uma tabela com 15 índices,
estremamente acessada estavam em uma mesma tbps de dados,
fiz um rebuild para uma tbps única para estes 15idx e o ganho de i/o foi notado visualmente em qq ferramenta gráfica. E detalhe a instância possui
ASM no storage e memos assim tive ganhos.
Portanto sou a favor de tacar tudo dentro de uma tbps como diz o portilho no GPO, porêm as tabelas mto acessada e com mto dml colocar em tbps diferentes SIM !

Minha opnião é manter em tbps diferentes por questão de organização
e por performance caso a tabela seja muito HOT.

[]s

[Marcio68AlmeidaParticipante]

Vieri,
Quando você faz um rebuild dos índices, certamente há um ganho imediato, já que as fragmentações deixam de existir e as referências ficam “limpas”…
Estando dentro de uma storage, a menos que sejam em grupos diferentes, não vejo por que haveria melhora de performance, o mesmo para ASM em um raid.
Mas, a organização sempre sugere melhoras… 🙂

[vieriParticipante]

Perfeito Márcio.

mas nesse caso eu já havia feito o rebuild “simples”
sem passar a tbps. e não obtive ganhos;

Qdo criei uma nova tbps e “rebuildei” nela, que eu obtive o ganho.

Era uma tabela muito problemática com muitos relacionamentos,
block’s, 15idx e muito acessada e com mto dml, tudo de ruim.

Mas certamente quando “rebuildei” para nova tbps crie ela
em um diskgroup para índices, antes estava no mesmo diskgroup da tabela.

Acredito que em casos extremos, como foi o meu, teremos ganho de i/o sim mesmo neste tipo de ambiente.

Posso está errado, mas principalmente em sistemas de WIS,ERP,BI aonde temos muitos “tabelões”, vale a pena colocar os IDX’s em diskgroups diferentes.

diferentes.

[Rodrigo AlmeidaParticipante]

Olá Pessoal,

Vou dar a minha opinião sobre o caso, eu também adoto ainda a utilização da separação de tablespaces por segmentos, seja para índices, dados e LOBs.

Por alguns motivos:

1) BALANCEAMENTO DE I/O

Pode existir sim excesso de I/O quando se tem índices e tabelas em mesma tablespace, por motivos de excesso de DMLs e DDLs, mesmo que instruções DMLs seja feito leituras em segmentos diferentes, pode ocorrer “hot blocks” no disco, que pode lhe atrapalhar em performance e aumentar os números de wait para os wait session como db file sequencial read, log sync e etc…

Tudo isso pode ser influênciado por alguns motivos, como:

1) Tipo de RAID utilizado
2) Se foi criado 1, 2 ou N volumes para os discos
3) Tipo de FileSystem utilizado
4) Valor de RPM dos discos
5) Tamanho de cada disco, ou seja, quanto maior a capacidade do disco, mais lento ele fica!
6) Utilização de diversos arquivos simultaneamente em um único lugar, exemplo: tu tem tabelas e índices que são essencias a aplicação, que seus datafiles estejam juntos com REDO LOGS, ARCHIVES, TRACES e etc… consequentemente, vai ter GARGALO DE I/O (Mas isso é mais um erro de arquitetura de banco de dados).

7) Se determinadas aplicações sãoa cessadas por MILHARES de usuários, consequentemente vai ter os HOT BLOCKS, e caso isso ocorra, seu hit cache pode diminuir e consguemente, ter discos trabalhando mais e outros menos, devido as quantidades de acesso vindos da aplicação.

Outros pontos que acho importante.

2) Recuperação

Se eu tenho uma tablespace única com DADOS e ÌNDICES, e consequentemente, eu perder algum datafile, eu posso parar completamente a aplicação sem excessão.

Porém, se tenho separado, algumas “TELAS” (funcionalidades) podem parar, porém, outras podem continuar trabalhando normalmente, exemplo, RELATORIOS usam índice, então podem dar problemas, porém, processos de carga da aplicação ou até mesmo de inclusão, necessáriamente não fica com problemas devido a sua separação.

Outro coisa importante, se eu perco índice, apenas com suas DDL eu posso reconstruir-las, se estiver junto, vou perder tempo na recuperação do banco, pois eles não estar naquele datafile gigante!!!

E vem outra pergunta, tu prefere perder um datafile de 2GB ou de 16GB?

Quanto tempo vou levar para restaurar da minha vida DLT/LTO?
QUanto tempo de recuperação para a tablespace?
Quanto de archive será necessário?
Vou ter espaço em disco para todos os archives necessários?

Essa questão de Recuperação, não é uma regra, e sim um bom senso do DBA na hora de criar o banco de dados e saber responder as perguntas acima.

3) Organização

Como o Marcio disse, Você ter tablespaces para índice, dados e LOBs, torna a administração mais fácil e simples. Mais organizada.

LEMBRETE!

Tudo isso é apenas meu ponto de vista, e que sim, VARIA MUITO DE UM AMBIENTE PARA OUTRO! Você DBA tem que saber como a sua aplicação se comporta para conseguir fazer a arquitetura correta.

Existem sim aplicações menores que podem ter sem problemas uma única tablespace para todos os seus segmentos.

Conheço um grande Banco mnundial, que tem uma instância de 8GB e uma base de 270GB, onde existem 12 aplicações com diversos funcionalidades e objetivos executando junto, e nesse caso, foi criado apenas uma tablespace para cada aplicação com o nome dela. Ficando tudo junto. E funciona que é uma beleza. Por serem aplicativos não
necessita de tanto I/O dos discos.

Abraços,
Rodrigo Almeida

[David SiqueiraParticipante]

Meu ponto de vista é bem parecido com o do Alphamek, tendo em vista que ainda recorro as vezes aos ´documentos da Oracle dobre a Padronização OFA tentanto justificar ou dismistificar algumas coisas que eles dizem, mais os argumentos são bem fundamentados, afinal foram engenheiros que construiram essa padronização em conjunto com uma equipe forte de técnicos.

Eu mesmo já tive problemas por manter tudo junto numa mesma Tbs a muito tempo , pois precisei reorganizar o banco e acabei gerando um tremendo problema na época. Mais efim são apenas pontos de vista.

Abraço á todos

P.S.: Bom bate bola, poderia até virar um tema de BLOG ou Café com GPO, arquitetura Oracle.

[C-S-RParticipante]

Opa,

Muito obrigado pela ajuda de vcs todos.

Pela conclusão que pude tirar que é um assunto bem delicado e precisar ser tratado caso a caso. Não existe uma regra fixa.

A duvida surgiu porque estavamos fazendo testes de performace e resolvemos separar Index e Data em discos diferentes.
Senao me engano foi efetuado um teste com 5 Tbs de dados e 5 de index divididos em 5 ou 6 discos.

Mas muito obrigado pelas informações.
Irei continuar a pesquisar sobre o assunto e sempre que possivel efetuar os testes.

vlw Galera

[Rodrigo AlmeidaParticipante]

Cesar,

Depois que foi feito a separação, qual foi os resultados obtidos?

Melhorou ou Pioro?

Abraços,

Rodrigo Almeida

[C-S-RParticipante]

Opa,

Então depois das alterações tivemos ganho de performace sim.

Porém foram feitas varias alterações.

Antes tinhamos 1 Tbs dados e outra index no mesmo disco
Quando foram feitos os testes de performace, foram separados os index dos dados mas tb separamos as tabelas, ex parte contabil, parte de cadastro, parte de mercado e etc.

Então essas alterações foram feitas para obter melhora de performace.

A empresa que trabalho na verdade e de desenvolvimento de software, então esses testes foram feitos para informações para os clientes que possuem o software.

Minha duvida era mais para saber se compesava continuar com a separar dados e index ou separar mais as tabelas por segmento.

Bom nao sei se conseguiu entender minha explicações mas é isso rsrs

[David SiqueiraParticipante]

Não sei como foi feito teu processo de separação desses objetos por módulos, mais se foram feitos MOVE TABLES e REBUILD’s com certeza foram eliminadas as fragmentações existentes nos objetos, só com isso o ganho de performance já é significativo com certeza.

Mas enfim, se teu problema foi sanada isso é o mais importante, caso tu tenha mais informações sobre o processo de mudança que vocês fizeram, post aqui depois pra ficar como base de dados para quem tiver esse mesmo problema.

Abraço e boa sorte!!!!

[Autor]

Posts