En este video, Jesús Muñoz Torres explica paso a paso y magistralmente como armar un cluster para SQL Server 2008 R2 sobre Windows Server 2008 R2. Toda esta explicación está dada sobre entornos virtualizados de modo de poder replicarlo localmente a modo de prueba.
Read More...
Encontrar los queries que consumen mas recursos
Los DMVs (Dynamic Management Views) son una magnífica forma de encontrar información de performance a partir de SQL Server 2005 en adelante (2008/2008R2/2012)
En este query de Pinal Dave se utilizan DMVs para encontrar los queries que mas consumen en un server SQL Server 2005/2008 (recordar que este script funciona solo en bases compatibilidad 2005/2008)
Query:
SELECT TOP 10 SUBSTRING(qt.TEXT, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(qt.TEXT)
ELSE qs.statement_end_offset
END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.total_logical_writes, qs.last_logical_writes,
qs.total_worker_time,
qs.last_worker_time,
qs.total_elapsed_time/1000000 total_elapsed_time_in_S,
qs.last_elapsed_time/1000000 last_elapsed_time_in_S,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
ORDER BY qs.total_logical_reads DESC -- logical reads
-- ORDER BY qs.total_logical_writes DESC -- logical writes
-- ORDER BY qs.total_worker_time DESC -- CPU time
Obviamente se puede cambiar el ordenamiento del script para destacar otro criterio de búsqueda.
Twitter: @bernachea
Como reparar usuarios "huérfanos"?
Muchas veces encontramos que el user de una base de datos está "huérfano", lo que significa que ya no existe un login asociado al mismo.
Puede ocurrir que exista un login incluso con el mismo nombre, pero internamente su SID no coincide.
Lo primero que hacemos es verificar cuales usuarios son huérfanos en la base de datos
use [su base de datos]
go
EXEC sp_change_users_login 'Report'
con la opción Report le estamos diciendo que liste los usuarios huérfanos.
Una vez que encontramos los usuarios huérfanos los reparamos con la siguiente sentencia.
EXEC sp_change_users_login 'Auto_Fix', 'user'
Donde user es el nombre del usuario que queremos "reparar".
Ahora bien, si además se quiere crear un nuevo login y password para este usuario, usaremos la siguiente sentencia:
EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'
Read More...
Puede ocurrir que exista un login incluso con el mismo nombre, pero internamente su SID no coincide.
Lo primero que hacemos es verificar cuales usuarios son huérfanos en la base de datos
use [su base de datos]
go
EXEC sp_change_users_login 'Report'
con la opción Report le estamos diciendo que liste los usuarios huérfanos.
Una vez que encontramos los usuarios huérfanos los reparamos con la siguiente sentencia.
EXEC sp_change_users_login 'Auto_Fix', 'user'
Donde user es el nombre del usuario que queremos "reparar".
Ahora bien, si además se quiere crear un nuevo login y password para este usuario, usaremos la siguiente sentencia:
EXEC sp_change_users_login 'Auto_Fix', 'user', 'login', 'password'
Hugo Román Bernachea
Mail de contacto: SQLServer777@gmail.com
Microsoft Certified DBA
Microsoft Certified Trainer
Twitter: @bernachea
SQL Server Best Practices for Developers
SQL Server Best Practices - Hugo Bernachea - Part One
Hugo Román Bernachea
Mail de contacto: SQLServer777@gmail.com
Microsoft Certified DBA
Microsoft Certified Trainer
Twitter: @bernachea
Máquina virtual para probar las nuevas características de Business Intelligence de SQL Server 2012 (denali)
Microsoft ha puesto a disposición la Base ImageX Server que es una imagen de Máquina virtual para testear las últimas características de Business Intelligence de SQL Server 2012 (denali) - RC0, incluyendo PowerView Reports y PowerPivot Excel Documents.
La máquina la pueden obtener de esta url: http://www.microsoft.com/betaexperience/pd/BIVHD/enus/, para conectarse a la máquina pueden utilizar el usuario CONTOSO\Administrator, con la contraseña pass@word1 (precaución con el idioma de la máquina, está en inglés por lo que es posible que la @ la tengan que introducir con Shift+2).
Hugo Román Bernachea
Mail de contacto: SQLServer777@gmail.com
Microsoft Certified DBA
Microsoft Certified Trainer
Twitter: @bernachea
Configurando una replicación Master a Master usando MySQL
Todos sabemos de la importancia de implementar mecanismos de alta disponibilidad en los servidores que nos toca administrar. En este caso, voy a detallar los pasos para implementar una replicación master to master o bidireccional entre servidores MySQL (una especie de espejado o mirror).
En ambos servers debemos hacer las siguientes tareas:
1. Crear una carpeta Logs, por ejemplo:
c:\program files\mysql\logs\
2. Crear un usuario para la replicación con suficientes permisos.
mysql -u root -pSuPassword (sin espacios el pass y el -p)
GRANT REPLICATION SLAVE ON *.* TO 'usuario'@'%' IDENTIFIED BY 'pepe';
FLUSH PRIVILEGES;
En el master principal
Hay que editar el archivo my.ini (en windows) o my.conf (en linux).
En la sección marcada como [mysqld] agregar lo siguiente.
log-bin = “D:\MySQL\MySQL Server 5.1\Logs” (cuidado con las comillas)
binlog-do-db=mibase
server-id=1
y agregar al final del archivo lo siguiente:
slave-net-timeout = 30
master-connect-retry = 30
Una vez hecho esto, grabamos y reiniciamos el servicio, ya sea por services o por línea de comandos:
mysqld restart
En el Master secundario:
Lo mismo, cambiar my.ini o my.conf, segun sea Windows o Linux y agregar lo siguiente en la sección: [mysqld]
log-bin = “c:\program files\mysql\logs\” (cuidado con las comillas)
binlog-do-db=winnings
server-id=2 (fijarse que este número es distinto al del master principal)
y al final del archivo agregar:
slave-net-timeout = 30
master-connect-retry = 30
grabar el archivo y reiniciar el servicio mysql
mysqld restart
En el Master principal:
Para evitar problemas vamos a bloquear las tablas hasta que finalicemos la operatoria.
FLUSH TABLES WITH READ LOCK;
En el Master secundario:
Creamos la base a ser replicada:
mysql -u root -pSuPassword
CREATE DATABASE suBase;
mysql -u root -pSuPassword suBase < suBase_backup.sql
En el Master principal:
mysql -u root -pSuPassword
use SuBase
go
SHOW MASTER STATUS;
Esto nos mostrará algo asi
PLAIN TEXT
CODE:
+---------------------+----------+-------------------------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------------+----------+-------------------------------+------------------+
| mysql-bin.000001 | 21197930 | my_database,my_database | |
+---------------------+----------+----------------------------
Lo que nos interesa a nosotros es el dato del file (mysql-bin.000001) y el número de la posición (21197930) . Con esos datos nos vamos al master secundario.
En el master secundario:
mysql -u root -pSuPassword
stop slave;
CHANGE MASTER TO MASTER_HOST='10.33.0.14', MASTER_USER='usuario', MASTER_PASSWORD='pepe’, MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=21197930;
start slave;
Fijense que en los parametros master_log_file y master_log_pos pusimos los datos que guardamos en el paso anterior en el master principal. En master user pusimos el usuario que creamos originalmente para la replicación y en Master_password su correspondiente password.
A continuación ejecutamos lo siguiente para ver como está funcionando la replicación:
Show Slave Status;
A este punto ya tendríamos seteada la replicación desde el master principal al master secundario, pero nos faltaría hacer la inversa, replicación desde el secundario al principal, por lo tanto...
Vamos al Master secundario.
use SuBase
go
SHOW MASTER STATUS;
Lo mismo que antes, tomamos los valores de file y position y los llevamos ahora al master principal.
En el master principal
mysql -u root -pSuPassword
stop slave;
CHANGE MASTER TO MASTER_HOST='10.33.0.13', MASTER_USER='usuarios', MASTER_PASSWORD='pepe’, MASTER_LOG_FILE='Logs.000001', MASTER_LOG_POS=107;
start slave;
Y como habiamos bloqueado las tablas para replicar sin problemas ahora es el momento de desbloquearlas:
unlock tables;
Si se siguieron todos los pasos, en este momento la replicación debería estar funcionando.
En ambos servers debemos hacer las siguientes tareas:
1. Crear una carpeta Logs, por ejemplo:
c:\program files\mysql\logs\
2. Crear un usuario para la replicación con suficientes permisos.
mysql -u root -pSuPassword (sin espacios el pass y el -p)
GRANT REPLICATION SLAVE ON *.* TO 'usuario'@'%' IDENTIFIED BY 'pepe';
FLUSH PRIVILEGES;
En el master principal
Hay que editar el archivo my.ini (en windows) o my.conf (en linux).
En la sección marcada como [mysqld] agregar lo siguiente.
log-bin = “D:\MySQL\MySQL Server 5.1\Logs” (cuidado con las comillas)
binlog-do-db=mibase
server-id=1
y agregar al final del archivo lo siguiente:
slave-net-timeout = 30
master-connect-retry = 30
Una vez hecho esto, grabamos y reiniciamos el servicio, ya sea por services o por línea de comandos:
mysqld restart
En el Master secundario:
Lo mismo, cambiar my.ini o my.conf, segun sea Windows o Linux y agregar lo siguiente en la sección: [mysqld]
log-bin = “c:\program files\mysql\logs\” (cuidado con las comillas)
binlog-do-db=winnings
server-id=2 (fijarse que este número es distinto al del master principal)
y al final del archivo agregar:
slave-net-timeout = 30
master-connect-retry = 30
grabar el archivo y reiniciar el servicio mysql
mysqld restart
En el Master principal:
Para evitar problemas vamos a bloquear las tablas hasta que finalicemos la operatoria.
FLUSH TABLES WITH READ LOCK;
En el Master secundario:
Creamos la base a ser replicada:
mysql -u root -pSuPassword
CREATE DATABASE suBase;
mysql -u root -pSuPassword suBase < suBase_backup.sql
En el Master principal:
mysql -u root -pSuPassword
use SuBase
go
SHOW MASTER STATUS;
Esto nos mostrará algo asi
PLAIN TEXT
CODE:
+---------------------+----------+-------------------------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------------+----------+-------------------------------+------------------+
| mysql-bin.000001 | 21197930 | my_database,my_database | |
+---------------------+----------+----------------------------
Lo que nos interesa a nosotros es el dato del file (mysql-bin.000001) y el número de la posición (21197930) . Con esos datos nos vamos al master secundario.
En el master secundario:
mysql -u root -pSuPassword
stop slave;
CHANGE MASTER TO MASTER_HOST='10.33.0.14', MASTER_USER='usuario', MASTER_PASSWORD='pepe’, MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=21197930;
start slave;
Fijense que en los parametros master_log_file y master_log_pos pusimos los datos que guardamos en el paso anterior en el master principal. En master user pusimos el usuario que creamos originalmente para la replicación y en Master_password su correspondiente password.
A continuación ejecutamos lo siguiente para ver como está funcionando la replicación:
Show Slave Status;
A este punto ya tendríamos seteada la replicación desde el master principal al master secundario, pero nos faltaría hacer la inversa, replicación desde el secundario al principal, por lo tanto...
Vamos al Master secundario.
use SuBase
go
SHOW MASTER STATUS;
Lo mismo que antes, tomamos los valores de file y position y los llevamos ahora al master principal.
En el master principal
mysql -u root -pSuPassword
stop slave;
CHANGE MASTER TO MASTER_HOST='10.33.0.13', MASTER_USER='usuarios', MASTER_PASSWORD='pepe’, MASTER_LOG_FILE='Logs.000001', MASTER_LOG_POS=107;
start slave;
Y como habiamos bloqueado las tablas para replicar sin problemas ahora es el momento de desbloquearlas:
unlock tables;
Si se siguieron todos los pasos, en este momento la replicación debería estar funcionando.
Hugo Román Bernachea
Mail de contacto: SQLServer777@gmail.com
Microsoft Certified DBA
Microsoft Certified Trainer
Twitter: @bernachea
Suscribirse a:
Entradas (Atom)