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

CategoriasOracle

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;

CategoriasASM

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]

CategoriasOracle 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.

CategoriasOracle

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

Categorias12c

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

CategoriasUncategorized

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

CategoriasRMAN