Oct 23, 2017

TRCANLZR (TRCA): SQL_TRACE/Event 10046 Trace File Analyzer

I want recommend you a tool very very useful for oracle traces analyzer, this tool is call: TRCANLZR (owner: Carlos Sierra, carlos.sierra@oracle.com). This tool allow you to summarize and describe trace files better than tkprof. It generates a HTML File with all information about the traces: top querys, top event waits, execution plans and much more:


Some Examples about the output after execution:




Full HTML Example about the output after execution traces analyzer:
In Metalink can see information about this tool in the note:
TRCANLZR (TRCA): SQL_TRACE/Event 10046 Trace File Analyzer - Tool for Interpreting Raw SQL Traces (Doc ID 224270.1)




The install tool is very simple:


1.- Uncompress the zip file.
2.- Enter the folder: trca/install
3.- Execute: sqlplus "/as sysdba" @tacreate.sql
This step is for create database schemas. The tool require a database instance.
4.- enter the folder diag/....trace/ (the folder where is located the database's alert log)
5.- In that directory copy the *.trc file what you will analyze.
6.- Go the folder trca/install
7.- Execute: sqlplus  "TRCANLZR/password_database" @trcanlzr.sql file_trace_to_analyzer.trc
8.- When the procesess finish, will be generated ZIP file on the folder trca\run


And open that zip file and you can see the HTML unique file with all results analyzer. (Example output: https://drive.google.com/uc?export=download&id=0B8Tjo6f10a1WbEVDaTBSNUpwd1E)


PD: For 9i trace files, you should to use this tool:
9i SQL Tuning Health Check Script SQLHC Doc ID 1366133.1


Link from author tool: https://carlos-sierra.net/2013/04/25/differences-between-tkprof-and-trace-analyzer-trcanlzr-trca/

Jun 10, 2017

Error 19405 al configurar nuevo nodo alwaysON sobre ambiente primario configurado como FailoverCluster


Hace pocos días tuve una problemática al añadir un nodo nuevo a un ambiente alwaysON existente. En mi cliente tengo una configuración de AlwaysON compuesta por una réplica primaria formada por un ambiente Failover Cluster de dos nodos, y como réplica secundaria tengo un nodo standalone dónde están las bases en modalidad lectura para que el cliente también lo ocupe como sistema de reporteria.

Ahora por necesidades del negocio para una prueba de DRP necesitábamos añadir un nodo secundario adicional al alwaysON (este nuevo nodo sería un standalone). Pero al añadir dicho nuevo nodo desde el wizzard de alwaysON apareció un error un poco extraño:

Naturalmente revisé lo que estaba mencionado ahí teniendo en cuenta que mi servicio sqlserver primario el cual estaba en realidad en un failover cluster no tuviera como nodo propietario al nuevo servidor standalone que estaba agregando al alwaysON. Al revisarlo desde el failover cluster manager efectivamente el servicio sqlserver no tenía seleccionado como owner al nuevo nodo:

Una vez que comprobé que el failover del servicio sqlserver en cluster  nunca podría ser pasado al nuevo nodo (que es lo que corresponde), me puse a revisar si no habría algún bug o error que me estuviese mostrando el GUI del failover manager. Por lo que desde consola powershell en el nodo primario del failover cluster consulté los posibles owner del servicio sqlserver  y en dicho caso si me mostró que mi nuevo nodo standalone de alwaysON estaba asignado como posible owner para el servicio lo cual está mal.
Comando: Get-ClusterOwnerNode –Resource “sql server”
El último nodo que termina con el nombre 136 no tiene que estar asignado como owner al servicio clusterizado de sqlserver. Esto es un bug ya que desde la herramienta  gráfica de failover cluster el nodo no aparece asignado, pero desde consola claramente se puede ver lo contrario (aún no encuentro ninguna nota que haga referencia formal a este error)
Ahora como esto no lo pude arreglar desde la interfaz gráfica del cluster administrator (porque el error se repetía nuevamente al agregar la réplica), me dispuse a solucionarlo desde la consola de comandos de powershell. Por lo cual eliminé el nuevo nodo standalone de la siguiente manera:
Comandos:
Get-ClusterOwnerNode –Resource “sql server” |Set-ClusterOwnerNode –Owners nodo1,nodo2

Como se podrá apreciar ahora los nodos preferentes para mi servicio de cluster solo aprecen los nodos antiguos y ya no mi nuevo nodo que termina con nombre 136. Posterior a eso ya no tuve problemas para añadir mi nueva replica standalone:

Espero que haya sido de utilidad.



May 26, 2017

Instalación de MongoDB


Hace poco también me tocó configurar un servicio de base de datos mongodb, un motor que al parecer ya se está comenzando a utilizar bastante. Les dejo algunos pasos a continuación:


Primero crearemos el usuario mongod (como usuario root):
mkdir /home/mongod
chown mongod:mongod /home/mongod
chmod 700  /home/mongod
adduser --system -d /home/mongod mongod
echo secu13re | passwd --stdin mongod
usermod -c 'mongod_database_not_delete' mongod
usermod -s /bin/bash mongod


Ahora nos convertiremos en usuario mongod que acabamos de crear
[root@bci-bluemixdbmongo01 /]# su - mongod
Last login: Fri May 26 11:33:04 CLT 2017 on pts/0

Como usuario mongod descomprimimos el archivo que hemos bajado del sitio web de mongo:

-bash-4.2$ cd /dbprdMongo/
-bash-4.2$ ls -ltr
total 80500
drwxrwx--- 4 mongod root       27 May 23 17:19 bd
-rwxrwxrwx 1 root   root 82431513 May 26 11:22 mongodb-linux-x86_64-rhel70-3.2.13.tgz
-bash-4.2$ tar xvfz mongodb-linux-x86_64-rhel70-3.2.13.tgz
mongodb-linux-x86_64-rhel70-3.2.13/README
mongodb-linux-x86_64-rhel70-3.2.13/THIRD-PARTY-NOTICES
mongodb-linux-x86_64-rhel70-3.2.13/MPL-2
mongodb-linux-x86_64-rhel70-3.2.13/GNU-AGPL-3.0
mongodb-linux-x86_64-rhel70-3.2.13/bin/mongodump
mongodb-linux-x86_64-rhel70-3.2.13/bin/mongorestore
mongodb-linux-x86_64-rhel70-3.2.13/bin/mongoexport
mongodb-linux-x86_64-rhel70-3.2.13/bin/mongoimport
mongodb-linux-x86_64-rhel70-3.2.13/bin/mongostat
mongodb-linux-x86_64-rhel70-3.2.13/bin/mongotop
mongodb-linux-x86_64-rhel70-3.2.13/bin/bsondump
mongodb-linux-x86_64-rhel70-3.2.13/bin/mongofiles
mongodb-linux-x86_64-rhel70-3.2.13/bin/mongooplog
mongodb-linux-x86_64-rhel70-3.2.13/bin/mongoperf
mongodb-linux-x86_64-rhel70-3.2.13/bin/mongosniff
mongodb-linux-x86_64-rhel70-3.2.13/bin/mongod
mongodb-linux-x86_64-rhel70-3.2.13/bin/mongos
mongodb-linux-x86_64-rhel70-3.2.13/bin/mongo



Crear link simbolico:
-bash-4.2$ ln -s /dbprdMongo/mongodb-linux-x86_64-rhel70-3.2.13 /dbprdMongo/mongodb
-bash-4.2$


Posteriormente añadir como root los siguientes privilegios para la carpeta que contendrá los datafiles y logfiles:
[root@bci-bluemixdbmongo01 dbprdMongo]# pwd
/dbprdMongo
[root@bci-bluemixdbmongo01 dbprdMongo]# chown -R mongod:root bd/
[root@bci-bluemixdbmongo01 dbprdMongo]# chmod -R 770 bd/
[root@bci-bluemixdbmongo01 dbprdMongo]#


Añadir lo siguiente al bash_profile del usuario mongod
export PATH=$PATH:/dbprdMongo/mongodb/bin


Se sugiere dejar el selinux deshabilitado
/etc/selinux/config con SELINUX=disabled.


Ahora se procederá a probar el servicio de mongodb

-bash-4.2$ /dbprdMongo/mongodb/bin/mongod --dbpath /dbprdMongo/bd
2017-05-26T11:57:45.852-0300 I CONTROL  [initandlisten] MongoDB starting : pid=2056 port=27017 dbpath=/dbprdMongo/bd 64-bit host=bci-bluemixdbmongo01
2017-05-26T11:57:45.852-0300 I CONTROL  [initandlisten] db version v3.2.13
2017-05-26T11:57:45.852-0300 I CONTROL  [initandlisten] git version: 23899209cad60aaafe114f6aea6cb83025ff51bc
2017-05-26T11:57:45.852-0300 I CONTROL  [initandlisten] OpenSSL version: OpenSSL 1.0.1e-fips 11 Feb 2013
2017-05-26T11:57:45.852-0300 I CONTROL  [initandlisten] allocator: tcmalloc
2017-05-26T11:57:45.852-0300 I CONTROL  [initandlisten] modules: none
2017-05-26T11:57:45.852-0300 I CONTROL  [initandlisten] build environment:
2017-05-26T11:57:45.852-0300 I CONTROL  [initandlisten]     distmod: rhel70
2017-05-26T11:57:45.852-0300 I CONTROL  [initandlisten]     distarch: x86_64
2017-05-26T11:57:45.852-0300 I CONTROL  [initandlisten]     target_arch: x86_64
2017-05-26T11:57:45.852-0300 I CONTROL  [initandlisten] options: { storage: { dbPath: "/dbprdMongo/bd" } }
2017-05-26T11:57:45.876-0300 I -        [initandlisten] Detected data files in /dbprdMongo/bd created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2017-05-26T11:57:45.876-0300 I STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=1G,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),checkpoint=(wait=60,log_size=2GB),statistics_log=(wait=0),
2017-05-26T11:57:46.147-0300 I CONTROL  [initandlisten]
2017-05-26T11:57:46.147-0300 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2017-05-26T11:57:46.147-0300 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2017-05-26T11:57:46.147-0300 I CONTROL  [initandlisten]
2017-05-26T11:57:46.147-0300 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2017-05-26T11:57:46.147-0300 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2017-05-26T11:57:46.147-0300 I CONTROL  [initandlisten]
2017-05-26T11:57:46.148-0300 I FTDC     [initandlisten] Initializing full-time diagnostic data capture with directory '/dbprdMongo/bd/diagnostic.data'
2017-05-26T11:57:46.148-0300 I NETWORK  [HostnameCanonicalizationWorker] Starting hostname canonicalization worker
2017-05-26T11:57:46.148-0300 I NETWORK  [initandlisten] waiting for connections on port 27017
^C2017-05-26T11:57:47.703-0300 I CONTROL  [signalProcessingThread] got signal 2 (Interrupt), will terminate after current cmd ends
2017-05-26T11:57:47.703-0300 I FTDC     [signalProcessingThread] Shutting down full-time diagnostic data capture
2017-05-26T11:57:47.705-0300 I CONTROL  [signalProcessingThread] now exiting
2017-05-26T11:57:47.705-0300 I NETWORK  [signalProcessingThread] shutdown: going to close listening sockets...
2017-05-26T11:57:47.705-0300 I NETWORK  [signalProcessingThread] closing listening socket: 5
2017-05-26T11:57:47.705-0300 I NETWORK  [signalProcessingThread] closing listening socket: 6
2017-05-26T11:57:47.705-0300 I NETWORK  [signalProcessingThread] removing socket file: /tmp/mongodb-27017.sock
2017-05-26T11:57:47.705-0300 I NETWORK  [signalProcessingThread] shutdown: going to flush diaglog...
2017-05-26T11:57:47.705-0300 I NETWORK  [signalProcessingThread] shutdown: going to close sockets...
2017-05-26T11:57:47.705-0300 I STORAGE  [signalProcessingThread] WiredTigerKVEngine shutting down
2017-05-26T11:57:47.754-0300 I STORAGE  [signalProcessingThread] shutdown: removing fs lock...
2017-05-26T11:57:47.755-0300 I CONTROL  [signalProcessingThread] dbexit:  rc: 0


Ahora se procera a crear la automatizaciòn del servicio (como usuario root)

Creamos el siguiente archivo:
vi /etc/systemd/system/mongod.service

Con el siguiente contenido:
[Unit]
Description=Mongo Database
After=network.target

[Service]
User=mongod
Group=mongod
ExecStart=/dbprdMongo/mongodb/bin/mongod --dbpath /dbprdMongo/bd
ExecStop=/dbprdMongo/mongodb/bin/mongod --dbpath /dbprdMongo/bd --shutdown
Restart=always

[Install]
WantedBy=multi-user.target


Como root se procede a automatizar el servicio

[root@bci-bluemixdbmongo01 ~]# sudo systemctl enable mongod
Created symlink from /etc/systemd/system/multi-user.target.wants/mongod.service to /etc/systemd/system/mongod.service.

Ahora se procede a probar el servicio
[root@bci-bluemixdbmongo01 ~]# systemctl start mongod
[root@bci-bluemixdbmongo01 ~]# systemctl status mongod
● mongod.service - Mongo Database
  Loaded: loaded (/etc/systemd/system/mongod.service; enabled; vendor preset: disabled)
  Active: active (running) since Fri 2017-05-26 12:11:46 CLT; 2s ago
Main PID: 2192 (mongod)
  CGroup: /system.slice/mongod.service
          └─2192 /dbprdMongo/mongodb/bin/mongod --dbpath /dbprdMongo/bd

May 26 12:11:46 bci-bluemixdbmongo01 mongod[2192]: 2017-05-26T12:11:46.408-0300 I CONTROL  [initandlisten]
May 26 12:11:46 bci-bluemixdbmongo01 mongod[2192]: 2017-05-26T12:11:46.409-0300 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hu...always'.
May 26 12:11:46 bci-bluemixdbmongo01 mongod[2192]: 2017-05-26T12:11:46.409-0300 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
May 26 12:11:46 bci-bluemixdbmongo01 mongod[2192]: 2017-05-26T12:11:46.409-0300 I CONTROL  [initandlisten]
May 26 12:11:46 bci-bluemixdbmongo01 mongod[2192]: 2017-05-26T12:11:46.409-0300 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hu...always'.
May 26 12:11:46 bci-bluemixdbmongo01 mongod[2192]: 2017-05-26T12:11:46.409-0300 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
May 26 12:11:46 bci-bluemixdbmongo01 mongod[2192]: 2017-05-26T12:11:46.409-0300 I CONTROL  [initandlisten]
May 26 12:11:46 bci-bluemixdbmongo01 mongod[2192]: 2017-05-26T12:11:46.410-0300 I FTDC     [initandlisten] Initializing full-time diagnostic data ca...ic.data'
May 26 12:11:46 bci-bluemixdbmongo01 mongod[2192]: 2017-05-26T12:11:46.410-0300 I NETWORK  [initandlisten] waiting for connections on port 27017
May 26 12:11:46 bci-bluemixdbmongo01 mongod[2192]: 2017-05-26T12:11:46.410-0300 I NETWORK  [HostnameCanonicalizationWorker] Starting hostname canoni...n worker
Hint: Some lines were ellipsized, use -l to show in full.
[root@bci-bluemixdbmongo01 ~]# ps -fea | grep -i mongo
mongod    2192     1  1 12:11 ?        00:00:00 /dbprdMongo/mongodb/bin/mongod --dbpath /dbprdMongo/bd
root      2218  1903  0 12:12 pts/0    00:00:00 grep --color=auto -i mongo

Ahora se procede a bajar
[root@bci-bluemixdbmongo01 bd]# systemctl stop mongod
[root@bci-bluemixdbmongo01 bd]#