La seguridad en Analysis Services está basada en la seguridad propia de Windows. Los usuarios se autentican usando sus cuentas de Windows locales (del servidor) o de dominio y pueden tener derechos segun los roles a los que pertenecen. ¿Que quiere decir esto? Que por decreto y si no hacemos cambios en la configuración de nuestra instancia de SSAS los usuarios que pertenecen al rol de Administradores del SO pueden entrar como Administradores también en la instancia. Para cambiar este comportamiento y limitar la administración de SSAS a los usuarios que hemos marcado como tales debemos cambiar el valor de la propiedad Security\BuiltinAdminsAreServerAdmins y ponerlo a false. Pero cuidado al hacer esto, no vayamos a quedarnos sin administradores, previamente debemos asegurarnos de que tenemos otra cuenta en la lista de administradores de SSAS...

En MySQL existe un parámetro que habilita el registro de las consultas que tardan mas de x segundos en ejecutarse, las llamadas Slow Queries. Básicamente lo que hace es meterlas en un fichero de log para luego consultarlo con mysqldumpslow. Este mecanismo nos puede ser útil para mejorar el rendimiento global de la base de datos si reducimos el valor de forma progresiva para los tiempos de ejecución "no admitidos" antes de declarar una consulta como "lenta" o slow query...
 

A continuación dejo un pequeño post de como montar un sistema automático de notificación via mail que nos indique cual es el estado de nuestra base de datos. Por ejemplo lo podemos programar un poquito antes de empezar nuestra jornada laboral y antes de irnos o mientras estamos de vacaciones (jaja...). Este ejemplo es sobre un Mysql 5.X corriendo sobre Debian. Pasos que sigue:...

Al administrar nuestra base de datos tenemos que lidiar a veces con aplicaciones de terceros(ERPs, etc...) o desarrolladas dentro de la empresa que a veces pueden tener mal planteados algunos procesos o por el motivo que sea traten la base de datos como si fuera exclusivamente suya. Voy a mostraros un ejemplo:

Entorno:
-servidor con dos puntos de montaje. El del sistema operativo donde también residen los archivos de datos de la base de datos y un disco secundario donde tenemos los archivos de copia rman más los archivelogs...

¿Alguna vez os habeis preguntado como deshabilitar el autocommit en el Management Studio de Sql Server? Pues la respuesta es rápida. Lo podeís cambiar activando en el menú Herramientas > Opciones > Ejecución de la consulta > SQL Server > Ansi > SET IMPLICIT_TRANSACTIONS...

Una base de datos Oracle en Standby es una copia exacta de una base de datos operativa en un servidor remoto, usada como backup, como copia para consulta, recuperación de desastres, etc.
Una base de datos en modo Standby es algo más que un backup normal ya que se puede poner en producción en caso de desastre en un tiempo menor que si tuvieramos que restaurar una copia (ya sea desde rman o un simple export). Restaurar una copia desde fichero tarda tiempo, y durante este periodo el sistema no está disponible..

Para aquellos administradores de bases de datos que deban tratar con un tal Dynamics Ax 2009 y sus secuaces (desarrolladores, consultores, etc ) dejo aquí un par de cosillas que se deben saber(o te deben decir) cuando unimos ax2009 y sql server 2008. A veces se puede apuntar a la base de datos como fuente del problema pero no siempre es así.  Algunos requerimientos a tener en cuenta para la instalación de Ax2009 son que el usuario con el que quieran acceder para hacer la instalación debe ser usuario de DOMINIO y en sql server debe ser miembro de rol dbcreator y securityadmin para poder crear la nueva base  de datos desde el instalador de Ax. Una vez instalado (o durante el proceso de instalación) los problema con la base de datos que nos podemos encontrar pueden ser:

Caso 1:
Otro problema conocido en la sincronización de datos puede producirse por la falta de permisos. El mensaje dice algo así:

Por el motivo que sea nos podemos encontrar que en nuestra base de datos Oracle tenemos muchos tablespace y para hacer un poquito de limpieza decidamos resumir los que estén duplicados. Entoces nos dirigimos a OEM y vemos una maravillosa liista de 50 tablespace con nombres sin sentido, algunos vacíos y otros por triplicado por que han llegado al tamaño que consideran máximo (en lugar de tres datafiles) etc etc... Llega el momento de ponerse manos a la obra.

Recordar que para ver el contenido de un tablespace nos podemos dirigir a Oracle Enterprise Manager y en la sección Administración>tablespaces marcar el que queramos, seleccionar en el desplegable Mostrar Dependencias y luego pulsando Ir. Luego veremos una segunda pestaña Dependientes. Ahí se muestran todos los objetos dependientes del tablespace (contenidos, vamos).

En Oracle SQL, se pueden optimizar ejecuciones batch que hagan un volcado masivo de datos en una misma tabla usando sentencias de insert o update por registro dentro de un bloque. Se pueden optimizar con el uso de parámetros (si el cliente lo permite) o si usamos odbc con bind variables.

Normalmente para analizar lo que pasa unas horas antes bastaría con consultar los datos históricos del Enterprise Manager pero no tenemos datos como el detalle de sesiones activas (si la cantidad total) o el estado o programa de cada una de ellas. También consultar las instantáneas en la consola web pero el problema sigue siendo el mismo, la falta de detalle. Pero no todo es insalvable y podemos en tres pasos completar esta información con algo más de detalle.

Paso 1: Crear una tabla con los datos que necesitaremos con un campo fecha.

Paso 2: Crear un procedimiento para alimentar la tabla con datos.

Paso 3: Crear un job con el usuario indicado para acumular datos.

Esta técnica puede ser “cutre” pero muchas veces sirve para analizar con más detalle y a nuestro gusto ciertas estadísticas que son visibles mediante vistas v$ que muestran el estado actual de la base de datos y que directamente no muestran un estado anterior en el tiempo.