BUG parallel_servers_target

Hoje estava fazendo um upgrade da versão 11.2.0.1 para 11.0.2.3 no ambiente produtivo na empresa , quando me deparo bem no começo do upgrade com um ORA-600, segue:

Performing Pre Upgrade
UPGRADE_PROGRESS : 1%
UPGRADE_PROGRESS : 7%
Upgrading Oracle Server
UPGRADE_PROGRESS : 8%
ORA-00600: internal error code, arguments: [kspgip1], [101], [1773], [1], [parallel_max_servers], [], [], [], [], [], [], []
ORA-01078: failure in processing system parameters

ORA-00600: internal error code, arguments: [kspgip1], [101], [1773], [1], [parallel_max_servers], [], [], [], [], [], [], []
ORA-01078: failure in processing system parameters

Upgrade failed due to running the step “Upgrading Oracle Server”

Após dar uma olhada no metalink encontrei o seguinte nota BUG abaixo

Bug 13817347 – ORA-1078/OERI:kspgip1 with parallel_servers_target (Doc ID 13817347.8)

Neste BUG se diz respeito a não estar setado o parametro PARALLEL_MAX_SERVERS no spfile ou pfile, quando eu fazia um show parameter no parametro ele trazia com um valor default que o oracle assume, porém ele precisa que seja feito o set dele no spfile então apenas setar o parametro, segue:

alter system set parallel_servers_target=40;

alter system set parallel_max_servers=100;

Lembrando que para setar os parametros parallel_servers_target ele não pode ser superior que o parallel_max_servers.

Espero ter ajudado

Abraço

Categorias:Oracle

ORA-15204: database version is incompatible with diskgroup

Bom hoje eu vou falar sobre a compatibilidade atribuida ao ASM na versão 11g, que é a compatibilidade RDBMS e do ASM, segue:

– Compatibilidade do ASM do software(binários) instalado é a compatiblidade do software(ASM) para acessar os DG’s.
– Compatiblilidade RDBMS a compatibilidade definida para cada diskgroup que irá ser usado para cada banco.

Neste meu cenário tenho o ASM software na versão 11.2.0.3 e tenho um database na versão 10.2.0.4 aonde eu vou restaurar neste ambiente, se eu NÃO mudar a compatible do RDBMS do disk group irá gerar o erro abaixo:

ORA-19870: error reading backup piece /FULL_ONLINE_DB_ORCL_l1odoo8b/
ORA-19504: failed to create file “+DATAG”
ORA-17502: ksfdcre:4 Failed to create file +DATAG
ORA-15001: diskgroup “DATAG” does not exist or is not mounted
ORA-15204: database version 10.2.0.4.0 is incompatible with diskgroup DATAG

Verificando a compatibilidade, segue:

SELECT group_number, name, compatibility, database_compatibility FROM v$asm_diskgroup;

GROUP_NUMBER NAME COMPATIBILITY DATABASE_COMPATIBILITY
———— ——- ——————- ———————
13 DATAG 11.2.0.0.0 11.2.0.0.0

Bom neste caso eu alterei o atributo da compatibilidade do banco, segue:

ALTER DISKGROUP DATAG SET ATTRIBUTE ‘compatible.rdbms’ = ‘10.2.0.0.0’;

GROUP_NUMBER NAME COMPATIBILITY DATABASE_COMPATIBILITY
———— ——- ——————- ———————
13 DATAG 11.2.0.0.0 10.2.0.0.0

Segue como alterar o compatibilidade do ASM e RDBMS:

ALTER DISKGROUP data SET ATTRIBUTE ‘compatible.asm’ = ‘11.1’;
ALTER DISKGROUP data SET ATTRIBUTE ‘compatible.rdbms’ = ‘11.1’;

Verificar em qual versão esta o ASM e o RDBMS:

SELECT group_number, name, value FROM v$asm_attribute where name like ‘%compatible%’ ORDER BY group_number, name;

Categorias:ASM

DRIVER_IRQL_NOT_LESS_OR_EQUAL

Bom essa semana estava instalando e configurando um Oracle RAC 11gr2 em Windows 2008 R2, e no começo da instalação do grid infrustructure começou a gerar tela azul. Segue abaixo

Imagem

Procurando algumas notas no metalink encontrei uma que informa que há um bug quando você tem mais que 64 processadores atribuído a maquina, a oracle pede para que instale com menos ou igual a 32 processadores e aplique o patch depois de instalado volte a quantidade de processadores que estava antes.

Bom diante deste cenário apenas desabilitei o Hyper-threading aonde que ele simula dois processadores com apenas 1 processador e a maquina ficou com 32 processadores e instalei normalmente sem tela azul apliquei o patch voltei e habilitei novamente o Hyper-threading com sucesso. Segue nota da oracle:

Windows: Can not Install Clusterware on x64 with More Than 32 Processors/Cores/Threads [ID 1177387.1]

Categorias:Oracle RAC

ORA-01102: cannot mount database in EXCLUSIVE mode

Bom este mês montei um ambiente produção que está em cluster HP-UX, aonde tenho 4 maquinas e 1 de HA(High Avaibility) e em alguns testes que estavamos fazendo de bootar as maquinas com todos os recursos ativos começou gerar erro no fail back na maquina de produção, segue:

 

SQL*Plus: Release 11.2.0.3.0 Production on Wed Jul 3 19:18:22 2013

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Connected to an idle instance.

SYS@PRD > ORACLE instance started.

Total System Global Area|2.5789E+10|bytes
Fixed Size | 2194576|bytes
Variable Size |4294968176|bytes
Database Buffers |2.1475E+10|bytes
Redo Buffers | 16969728|bytes
ORA-01102: cannot mount database in EXCLUSIVE mode
SYS@PRD > Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

Este erro foi devido que não foi abaixado o oracle de forma limpa e realmente simplesmente fizemos um halt do servidor com todos os serviços do SO, Grid e Database ativos, bom o pacote do SO migrou para o HA com sucesso.

Bom no FailBack gerou o erro acima, pesquisando no metalink descobri que ele gera um arquivo no ORACLE_HOME/dbs/lkSID quando o banco inicia e cria este arquivo nele fica como sendo usado por todos os processos principais do banco dbwriter,smon,pmon entre outros, na queda da maquina sem abaixar o banco corretamente o erro acima foi reportado, não havia processos em uso pelo arquivo, então apenas renomei ele e subi o banco novamente com sucesso.

Database Startup Fails with ORA-1102 and ORA-9968 [ID 160395.1]

OERR:

01102, 00000, “cannot mount database in EXCLUSIVE mode”
// *Cause: Some other instance has the database mounted exclusive or shared.
// *Action: Shutdown other instance or mount in a compatible mode.

Categorias:Oracle

Erros ao instalar o 12c GI

Bom estava começando a instalar o Grid infrustruture 12c e bem no começo da instalação já gerou o erro abaixo

PRVF-002: Could not retrieve local nodename

Bom dei uma olhada no meu hosts, e vi que o nome do servidor não estava lá apenas o localhost, então apenas inseri ele no /etc/hosts ficando desta maneira:

[root@hodb12c ~]# hostname
hodb12c.localdomain
[root@hodb12c ~]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
192.168.56.101 hodb12c.localdomain
[root@hodb12c ~]#

Para motivo de curiosidade o Grid infrustrutute 12c pede 4gb de memória RAM.

Abraço

Categorias:12c

Liberando um diretório local do servidor para acesso via HTTP

Hoje um programador pediu um dump de dois schemas de um banco de dados de produção e pediu para que colocasse em algum lugar publico para abaixar, porém empresa em que trabalho, não possui servidor de FTP ou algo parecido com isso, então utilizei o Python aonde que você consegue utilizar alguns modulos do tipo HTTP Server utilizando a porta 8000 que vem configurado como default, em linux geralmente já vem instalado a versão 2 porém segue o site se o seu não tiver:

http://www.python.org/download/

Há 2 modulos HTTP:

– BaseHTTPServer: cria um servidor de HTTP.
– SimpleHTTPServer: cria no diretório local e diretórios subsequentes.

Bom para mim utilizar o SimpleHTTPServer era o que eu precisava pois apenas queria disponibilizar esta area de dump para que fizessem os downloads, então apenas executar o comando abaixo no file system desejado, segue comando:

python -m SimpleHTTPServer

Fazendo assim irá disponibilizar este diretorio e subdiretorios para que possa acessar remotamente pelo protocolo HTTP, para acessar apenas utilizar o IP do servidor e a porta:

http://192.168.1.1:8000

Você pode alterar a porta também no proprio comando sem precisar alterar arquivos de configuração:

python -m SimpleHTTPServer 8888

Bom é isso.
Abraço

Categorias:Uncategorized

RMAN – Armazenamento de script no recovery catalog

Bom hoje surgiu um problema aqui na empresa aonde que a ferramenta que utilizamos é um interpretador de comandos e apenas aceita alguns comandos, caso utilize compressão ou algum parâmetro diferente do normal que backup database ele não consegue interpretar, então surgiu algumas opções em criar algum outro shell e fazer uma chamada para que o produto não interprete este outro arquivo ou utilizar o próprio RMAN para guardar os script e fazer a chamada por linha de comando, então vamos lá vou abordar como criar e utilizar Scripts que são gravados no catalogo do RMAN, sim são gravados no catalogo, caso você utilize o controlfile(nocatalog) este post não irá te ajudar.

Há 2 tipos de se guardar o Script no RMAN, segue:

1. Local Stored Script – Utilizado para executar apenas script salvos do banco do destino.
2. Global Stored Script – Script pode ser executado por qualquer banco registrado neste catalogo.

Fora que o script também aceita variaveis de substituição EXEMPLO &1 para o primeiro parametro &2 para o segundo parametro e assim por diante.

Então vamos lá, eu criei um script local mesmo para testar, começei pelo incremental que demorava menos para validar o script se funcionava:

CREATE SCRIPT BackupIncrementalOnline
COMMENT ‘Backup Incremental Online’
{
SET COMMAND ID TO ‘IncrementalOnline’;
ALLOCATE CHANNEL ch00 TYPE SBT_TAPE;
ALLOCATE CHANNEL ch01 TYPE SBT_TAPE;
CONFIGURE EXCLUDE FOR TABLESPACE TBS_REFERENCE;
CONFIGURE EXCLUDE FOR TABLESPACE TBS_REFERENCE_INDX;
CONFIGURE EXCLUDE FOR TABLESPACE TB_REPOS_ODI;
BACKUP INCREMENTAL LEVEL 1 SKIP INACCESSIBLE TAG RMAN_BACKUP_FULL FILESPERSET 50 (DATABASE INCLUDE CURRENT CONTROLFILE);
CONFIGURE EXCLUDE FOR TABLESPACE TBS_AGGREGATE CLEAR;
CONFIGURE EXCLUDE FOR TABLESPACE TBS_AGGREGATE_INDX CLEAR;
CONFIGURE EXCLUDE FOR TABLESPACE TBS_BASE CLEAR;
BACKUP SECTION SIZE 100G TABLESPACE TBS_AGGREGATE;
BACKUP SECTION SIZE 100G TABLESPACE TBS_AGGREGATE_INDX;
BACKUP SECTION SIZE 100G TABLESPACE TBS_BASE;
}

Bom não é necessário colocar o run{} na hora de guardar o script no RMAN, pois iremos utiliza-lo para chamar o script para sua execução, segue:

RUN {EXECUTE SCRIPT BackupIncrementalOnline;}

Listar os script armazenados no catalogo:

list script names;

list global script names;

Mostrar o conteúdo do script:

PRINT SCRIPT BackupIncrementalOnline;
PRINT GLOBAL SCRIPT BackupIncrementalOnline;

Para fazer um replace do script, apenas mudar o começo:

REPLACE SCRIPT BackupIncrementalOnline

{…..}

Replace global script BackupIncrementalOnline

{……}

Deletando os scripts

DELETE SCRIPT BackupIncrementalOnline;

DELETE GLOBAL SCRIPT BackupIncrementalOnline;

Bom é isso.

Abraço

Categorias:RMAN