renombrando un PDB

Posted on por
Responder

Hoy vamos a ver una entrada sencilla para un problema bastante comun.
Supongamos que queremos renombrar un PDB
Tenemus :

  • Nombre origina: OLDNAME
  • Nombre nuevo : NEWNAME

Los pasos a segir son muy sencillos

alter session set container=OLDNAME;

-- reiniciamos en modo restrict
shutdown immediate;
startup open restrict;
--cambiamos nombre
alter pluggable database OLDNAME rename global_name to NEWNAME;

--comprobamos
show con_name;
show pdbs;

--reiniciamos normal
shutdown immediate;
startup;

--vemos el resultado
select name,open_mode from v$pdbs;

Com podeis ver, altamente sencillo

Creando una base de datos en modo silent

Posted on por
Responder

Hoy vamos a ver otra de estas entradas para dummies que nos ahorraran mucho trabajo.
Vamos a cer el contenido de un sell scritp . En nuestro caso la queremos en ASM y los nombres de los diskgroups no son los estabdares de DATA,REDO y FRA, sino que llevan el nombre del HOSTNAME delante.

Asi pues, nuestro script sera algo similar a

[bash]

#!/bin/bash
export ORACLE_SID=$1
HOST=`hostname -a`
export ORACLE_HOSTNAME=${HOST^^}
export ORA_INVENTORY=`cat /etc/oraInst.loc |grep inventory_loc |tr "=" " " |awk ‘{print $2}’`

dbca -silent -createDatabase \
-templateName General_Purpose.dbc \
-gdbname ${ORACLE_SID} -sid ${ORACLE_SID} -responseFile NO_VALUE \
-sysPassword SysPassword1 \
-systemPassword SysPassword1 \
-characterSet WE8ISO8859P1 \
-nationalCharacterSet AL16UTF16 \
-createAsContainerDatabase false \
-automaticMemoryManagement false \
-databaseType MULTIPURPOSE \
-automaticMemoryManagement false \
-storageType ASM \
-datafileDestination +${ORACLE_HOSTNAME}_DATA \
-totalMemory 2048 \
-redoLogFileSize 521 \
-emConfiguration NONE \
-initParams "control_file_record_keep_time=30, control_files=+${ORACLE_HOSTNAME}_DATA’, control_files=+${ORACLE_HOSTNAME}_FRA, db_create_file_dest=+${ORACLE_HOSTNAME}_DATA, db_create_online_log_dest_1=+${ORACLE_HOSTNAME}_REDO1,db_create_online_log_dest_2=+${ORACLE_HOSTNAME}_REDO2,db_recovery_file_dest=+${ORACLE_HOSTNAME}_FRA, db_recovery_file_dest_size=90G , recyclebin=’OFF’ ,sessions=300,proceses=150" \
-ignorePreReqs
[/bash]

Cambiar el partner agent en un OEM13

Posted on por
Responder

Hoy vamos a ver de manera sencilla como cambiar un partner agent en un OEM13.
Lo primero que debemos de tener en cuenta es ..

¿que es un partner agent?

Un partner agent es un agente al que se le asigna a propiedad de comprobar el estado de otro host, mediante esto lo que conseguimos es hacer mas rapido la deteccion del estado de un host.

Como sabemos cual es nuestro partner agent?

En el caso de tener definido un parner agent lo veremos en la ventana del OEM, pero , podemos comprobarlo tambien mediante la consulta SQL


set linesize 200
col 'Target Agent' format a50;
col 'Partner Agent' format a50;
select target_agent.target_name "Target Agent",
           partner_agent.target_name "Partner Agent"
      from
           sysman.EM_AGENT_BUDDY_MAP eabm,
                 sysman.mgmt_targets target_agent,
                 sysman.mgmt_targets partner_agent
      where
          eabm.buddy_target_guid = partner_agent.target_guid and
          eabm.agent_target_guid = target_agent.target_guid and
         target_agent.target_name like  'server.pamplona.name:3875';
	
	
		 Target Agent                                       Partner Agent
-------------------------------------------------- --------------------------------------------------
server.pamplona.name:3875                        oldpartnerpamplona.name:3875

COmo cambiamos nuestro partner agent

Supongamos que quremos cambiarlo de oldpartner a newpartner
Lo primero que tendremos que hacer es eliminar el antiguo

./emcli manage_agent_partnership -remove_agent_partnership -monitored_agent=server.pamplona.name:3875 -partner_agent=oldpartnerpamplona.name:3875
Manage Agent Partnership operation completed successfully

Tras esto, ejecutamos el comando para añadir el nuevo 

./emcli manage_agent_partnership -add_agent_partnership -monitored_agent=server.pamplona.name:3875 -partner_agent=newpartner.pamplona.name:3875
Manage Agent Partnership operation completed successfully

Con esto tendremos cambiado el agente

Mas informacion el la nota EM 12c, 13c: FAQs on Partner Agent / Buddy Agent / Real Time Monitoring (Doc ID 1952190.1)

Trabajando con Huge pages

Posted on por
Responder

A partir de OEL7 deberiammos de chekquear las transparent huge pages 

cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

Igualmente , deberiamos de tenerlo configurado en el grub 

sudo cat /boot/grub2/grub.cfg |grep trans
  set kernelopts="root=/dev/mapper/vg_main-lv_root ro console=tty0 no_timer_check biosdevname=0 rd.lvm.lv=vg_main/lv_root net.ifnames=0 transparent_hugepage=never "

Por el contrario, si no las hemos modificado ( situacion no deseada) , aparecera 

cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

A partir de ahi, para ver las disponibles solo hay que ejecutar 

test1$: grep Huge /proc/meminfo
AnonHugePages:    897024 kB
HugePages_Total:     220
HugePages_Free:      220
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

Esto nos indica que teemos 220 paginas de 2048 Kb
Lo que significa que el espacio dedicado sera

Gb = 220*2048/1024/1024

Mas informacion en :

DIA-49803: Purge not possible due to incompatible schema version.

Posted on por
Responder

Hoy vamos a ver una sencilla entrada que tiene que ver con el adrci ( Interprete de comandos ADR ).
El otro dia me encontre con que algunos de los automatismos de limpieza de logs fallaban con el eror DIA-49803: Purge not possible due to incompatible schema version

[oracle@testserver ~]$ adrci
ADRCI: Release 12.1.0.2.0 - Production on Thu Mar 16 09:34:45 2019
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
ADR base = "/u01/app/oracle/admin"
adrci> show homes
ADR Homes: 
diag/rdbms/test1/TEST1
diag/rdbms/test2/TEST2
adrci> purge -age 180 -type alert   
DIA-49803: Purge not possible due to incompatible schema version.

A que puede deberse esto ?
Si miramos en la documentacion de soporte de Oracle nos encontramos con algunos poibles bugs , como el bug Bug 27718599 o un efecto secundario del bug 28375106.
Pero, antes de meterse en berenjenales, lo mas sencillo es intentar migrar la version de los logs.

Como lo hacemos?

Algo tan sencillo como 

adrci> migrate schema
Schema migrated.

Tras la ejecucion de este sencillo comando, veremos como nuestros comandos vuelven a funcionar correctamente