- Este tópico contém 12 respostas, 4 vozes e foi atualizado pela última vez 12 anos, 6 meses atrás por
Marcos Braga.
-
AutorPosts
-
26 de outubro de 2012 às 6:55 am #104697
Vivaldo Neto
ParticipanteBoa noite moçada.
Alguém poderia me falar realmente qual a diferença de usar tablespaces com auto-extend ou sem auto-extend?
Sempre configuro com auto-extend mais nao sei qual q diferença, pontos fracos e pontos fortes e manutenção.
Abraços
26 de outubro de 2012 às 2:24 pm #104699rman
Participante@vivaldo
A opção auto-extend define quanto o datafile pode crescer de forma automática, é possível também definir o tamanho do incremento. Com o auto-extend o datafile é alocado conforme a necessidade.
26 de outubro de 2012 às 7:43 pm #104700Vivaldo Neto
Participante@rman
Estas opções eu ja conheço, eu fico em duvida é se é melhor colocar em automático ou quando o datafile encher eu ter que criar outro.
E quais são as melhores praticas (desempenho, manutenção etc)
26 de outubro de 2012 às 8:03 pm #104701rman
Participante@vivaldo
Eu prefiro trabalhar com datafile de 10 GB, então eu já deixo alocado, não utilizando o auto-extend. Eu configurei o Enterprise Manager para enviar email caso chegue próximo do limite. Creio que toda vez que encher o datafile e alocar o incremento até chegar o limite isso deva prejudicar o desempenho, por isso já deixo alocado, o fato negativo é que isso já consome espaço em disco, se isso não for problema creio que seja melhor.
26 de outubro de 2012 às 8:51 pm #104702Fábio Prado
Participante@vivaldo,
A opção auto-extend, como o @rman já havia informado, permite configurar o auto-incremento de um tablespace, que será aplicado quando ele encher.
Cada empresa tem uma política para gerenciar os tablespaces. O @rman, por exemplo, prefere configurar um tablespace para o tamanho de 10g e desabilitar o auto-incremento. Eu gosto de configurar auto-incremento ou autoextend e definir tamanho máximo do tablespace para facilitar manutenção e não disperdiçar espaço em disco não utilizado. Essas tarefas devem ser bem planejadas para evitar problemas futuros. Se por exemplo vc tem uma estimativa que um sistema vai crescer até 100 GB em 5 anos, crie o tablespace com tamanho máximo de 100 gB e um auto-incremento que seja disparado 1 vez por semana ou 1 vez por mês, ou seja, se os dados do sistema aumentam 100 mb por semana, configure o auto-incremento para 100 MB. Jamais configure um autoextend com um valor muito pequeno, tipo 1 kb, pois se vc fizer isso, vc terá sobrecarga no autoincremento do tablespace e seu sistema que utiliza este tablespace ficará uma carroça (já vi isso acontecer em uma empresa em que trabalhei).
Espero ter ajudado.
[]s
Fábio Prado
http://www.fabioprado.net29 de outubro de 2012 às 5:48 am #104710Vivaldo Neto
Participante@rman, @fbifabio
Ótima colocação a de vc´s, eu utilizo 10GB de data file inicial e 10GB de auto-incremento, porem alguns dba´s que conversei me disseram que nao é saudável utilizar auto-incremento pois isso gera segmentos no data file, mas não entendi bem o que ele quiz dizer, por isso a minha duvida.
Mas como vc´s falaram que nao tem diferença entre auto-incremento e criação de datafile manual, e que o gargalo seria na criação do auto-incremento, vou continuar o mesmo processo que sigo utilizando o auto-incremento ja que a maioria das instalações o espaço disponível é grande.
Se alguém tem alguma consideração a fazer, estamos abertos a essa discussão.
29 de outubro de 2012 às 3:03 pm #104711rman
Participante@vivaldo
Você disse que o tamanho inicial do datafile é de 10 gb e o incremento também é de 10 gb, isso quer dizer que quando o datafile atingir 10 gb será alocado mais 10 gb de forma automática, ou seja, provavelmente no horário de produção. Isso já aconteceu?
Eu já fiz alocação de 10 gb de datafile durante o horário de produção, e posso te dizer que o resultado foi retenção do banco durante todo o processo. Pode ter certeza que o usuário final vai sentir a lentidão…
Outra pergunta, qual é o limite máximo do datafile que você definiu?
29 de outubro de 2012 às 4:02 pm #104712Vivaldo Neto
Participante@rman
Isso ainda nao aconteceu comigo, porque as bases são pequenas, e coloquei o datafile como ilimitado, ja que o armazenamento que sugiro é de no minimo 1TB.
Então como você disse a um gargalo seria na hora do incremento, mas teria como eu otimizar este processo pra fazer fora do horário de produção??
29 de outubro de 2012 às 4:10 pm #104713rman
Participante@vivaldo
Quando você usa auto-extend não é possível saber quando o incremento irá ocorrer, mas provavelmente vai ser no horário de produção, pois é no momento que o datafile chegar a 100%. Por isso eu não uso o auto-extend, o que eu faço é monitorar o crescimento e quando estiver próximo é feito a criação do novo datafile, desta forma você pode planejar e fazer fora do horário de produção.
Só uma observação, o ilimitado que você definiu na verdade é limitado a 32 gb. Quando o datafile chegar a 32 gb não será mais possível aumentar, você terá que criar um novo datafile.
31 de outubro de 2012 às 10:53 pm #104733Vivaldo Neto
Participante@rman,
Entendi como funciona, valeu pela dica, vou começar a analisar melhor as instalações para verificar qual se encaixa emlhor em cada cenario.
14 de novembro de 2012 às 2:23 pm #104777Marcos Braga
ParticipanteOlá Pessoal,
Vou deixar algumas experiências para incrementar a conversa que está boa.
Levem sempre em consideração, antes de definir auto-extend, os limite do tamanho do datafile no S.O., e também é importante pensar em Backup & Recover usando RMAN.
Para isso, mostro a seguinte explanação.
- O limite de um datafile depende de duas coisas:
- Arquitetura do S.O.: 32 ou 64bits
- Tipo da tablespace: bigfile ou smallfile
No ítem 1, se o S.O. tem 32 bits e, dependendo do tipo de formatação do seu H.D., por exemplo: NTFS suporta arquivos de até 4TB (se não me engano), enquanto que um FAT32, que, se lembro bem, tem um limite por arquivo de 4GB; já as arquiteturas de 64bits possuem um limite bem maior por arquivo. Portanto, para esse ítem é importante saber e levar em consideração qual é o tipo de arquitetura, formatação E, se está usando Storage (para o qual os limites possuem outro controle).
Já no ítem 2, se sua tablespace é smallfile, cada datafile possui um limite de 4194303 blocos. Se multiplicarmos esse número por blocos de 8K, que é o padrão usado, teremos datafiles de mais ou menos 32GB; leva-se em consideração também que smallfile possui outro limite que é o número de datafiles por tablespace que pode ser alocado que é 1022 datafiles. E para a tablespace bigfile o limite é de 4294967295 blocos, que multiplicado por blocos de 8K, teremos datafiles de mais ou menos 8TB, levando-se em consideração que em uma tablespace bigfile só pode comportar um datafile.
Isso dá um pouco para pensar e fazer umas contas. Essas informações podem ser encontradas no seguinte documento Oracle para maiores detalhes técnicos.
http://docs.oracle.com/cd/B28359_01/ser … tm#i287915
Há também um documento no Support Oracle, ID 804733.1, que possui mais informações a respeito, e também alguns comentários sobre os limites do S.O. Oracle Linux.
Quanto ao Backup & Recover usando RMAN, deve-se levar em consideração que:
- Smallfile com arquivos pequenos é possível criar vários canais de backup, sendo possível agilizar um processo de backup;
- Bigfile, que possui somente um datafile, independente do número de canais do RMAN, e pelo menos até a versão 10, cada canal faz backup de 1 datafile, portanto, se o datafile for enorme, ele demorará bastante para finalizar, pois estará sendo executado em somente um canal do RMAN.
Creio que esses “parâmetros” dão um pouco mais a pensar.
Sucesso a todos.
[]s
Braga15 de novembro de 2012 às 1:15 am #104788Fábio Prado
Participante@braga,
Muito bom seus comentários, só gostaria de acrescentar uma informação. No 11G é possível quebrar o backup dos bigfiles em arquivos menores, através da palavra-chave SECTION onde vc define o tamanho de cada parte dos datafiles (big ou small) e faz o backup em múltiplos canais também, utilizando paralelismo para reduzir o tempo de backup. Resumindo… BIGFILE TABLESPACES já não é mais problema para backups no 11G.
[]s
Fábio Prado
http://www.fabioprado.net16 de novembro de 2012 às 1:47 am #104791Marcos Braga
Participante[quote=”fbifabio”:oaac3sc3]@braga,
Muito bom seus comentários, só gostaria de acrescentar uma informação. No 11G é possível quebrar o backup dos bigfiles em arquivos menores, através da palavra-chave SECTION onde vc define o tamanho de cada parte dos datafiles (big ou small) e faz o backup em múltiplos canais também, utilizando paralelismo para reduzir o tempo de backup. Resumindo… BIGFILE TABLESPACES já não é mais problema para backups no 11G.
[]s
Fábio Prado
http://www.fabioprado.net[/quote%5DOpa Fábio, muito bom saber dessa atualização do RMAN.
[]s
Braga -
AutorPosts
- Você deve fazer login para responder a este tópico.