renombrando un PDB

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

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]

Trabajando con Huge pages

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.

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

Errores psdgbt: bind csid (X) does not match session csid (YY)

Hoy vamos a ver una entrada rapida y sencilla que nos ayudara a evitar una cascada de errores en el alert.log

Es posible que, la reiniciar alguna e nuestras bases de datos que se encuentran bajo la monitorizacion de un Enterprise manager veamos que el alert.log de nuestra base de datos comienza a mostrar continuamente errores del tipo

Errors in file /u01/app/oracle/diag/rdbms/TEST_stby/TEST/trace/TEST_ora_743.trc:
Mon March 11 12:24:47 2019
Errors in file /u01/app/oracle/diag/rdbms/TEST_stby/TEST/trace/TEST_ora_743.trc:
Mon March 11 12:25:06 2019
Errors in file /u01/app/oracle/diag/rdbms/TEST_stby/TEST/trace/TEST_ora_743.trc:

Si comprobamos la traza podemos ver como se trata de errores del tipo

psdgbt: bind csid (1) does not match session csid (46)
psdgbt: session charset is XXX

Donde el charset variara en funcion de nuestra base de datos, veamos una de estas trazas

ORACLE_HOME = /u01/app/oracle/product/12.1.0/db
System name: Linux
Node name: test.pamplona.name
Release: 3.8.13-118.19.12.el6uek.x86_64
Version: #2 SMP Tue Oct 31 12:31:15 PDT 2017
Machine: x86_64
Instance name: TEST
Redo thread mounted by this instance: 1
Oracle process number: 32
Unix process pid: 743, image: oracle@test.pamplona.name

*** 2019-03-11 21:20:06.886
*** SESSION ID:(2.57596) 2019-03-11 21:20:06.886
*** CLIENT ID:() 2019-03-11 21:20:06.886
*** SERVICE NAME:() 2019-03-11 21:20:06.886
*** MODULE NAME:(emagent_SQL_oracle_database) 2019-03-11 21:20:06.886
*** CLIENT DRIVER:(jdbcthin) 2019-03-11 21:20:06.886
*** ACTION NAME:(ME$icc_dbs_age_last_backup) 2019-03-11 21:20:06.886

psdgbt: bind csid (1) does not match session csid (46)
psdgbt: session charset is WE8ISO8859P15

*** 2019-03-11 21:20:06.886
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=1, mask=0x0)
—– Error Stack Dump —–
—– Current SQL Statement for this session (sql_id=a0qc12302fzfk) —–
begin dbms_application_info.set_module(:1 , :2 ); end;

La solucion para este problema es muy muy sencila, simplemente, reinicia el agente del enterprise manager del servidor donde se encuentra ubicada la base de datos.

Como siempre, mas informacion en soporte de Oracle
Doc ID 956222.1