Si usamos VMware ESX como sistema de virtualización y lo tenemos clusterizado con VMware vCenter, es posible que en algún momento el vCenter empiece a ir lento y no nos muestre las máquinas virtuales correctamente, dejarán de funcionar los servicios que usen su API como Veeam Backup, no podremos conectar al vSphere Client ni al vSphere Web Client y si conseguimos conectarnos obtendremos desconexiones o errores como «Health status monitoring«. También puede que nos muestre las máquinas virtuales del clúster con la etiqueta «Orphaned» y, además, inhabilitadas. Os explicamos una posible causa de estos errores y problemas y cómo solucionarla.
- Escenario de trabajo con VMware ESX, VMware vCenter y SQL Server Express.
- Antes de continuar, es imprescindible hacer copia de seguridad de la base de datos SQL Server Express.
- Liberar espacio de eventos y estadísticas en BD SQL Server de VMware vCenter.
- Opción de eliminación de estadísticas y eventos de vCenter más drástica.
- Error 9002 The transaction log for database ‘VIM_VCDB’ is full en SQL Server.
- Liberar espacio de forma drástica vaciando tablas de log manualmente.
Escenario de trabajo con VMware ESX, VMware vCenter y SQL Server Express
Si tenemos un entorno de virtualización con servidores VMware ESX y tenemos el entorno clusterizado con VMware vCenter, sobre base de datos Microsoft SQL Server Express, puede que nos encontremos con este problema transcurrido un tiempo de la instalación.
VMware vCenter necesita una máquina virtual (habitualmente sobre Microsoft Windows Server 2012), en dicha máquina los servicios de VMware vCenter almacenan toda la información de estadísticas y otros datos del cluster en una base de datos, puede ser Oracle, SQL Server, PostgreSQL u otras. Por defecto vCenter se instala sobre una base de datos SQL Server Express, la versión gratuita de la base de datos SQL de Microsoft. Esta versión, entre sus limitaciones, tiene la de tamaño máximo de los ficheros de datos de 10 GB.
El archivo anterior, de 10.4 GB: VIM_VCDB.mdf, será el que indique el tamaño de la BD, en este caso totalmente llena.
También se puede ver el espacio usado por la BD desde Microsoft SQL Management Studio, conectarnos con un usuario con permisos de administrador y pulsar sobre las propiedades de la BD, en nuestro caso sobre VIM_VCDB:
En «General», en «Tamaño» nos indicará el tamaño ocupado por la BD, que no debe superar los 10.000MB:
Si la base de datos llega al tamaño máximo de 10 GB, y esto puede ocurrir transcurridos unos meses desde la instalación y puesta en marcha del clúster vCenter, nos encontraremos con que el vCenter dejará de funcionar, al principio nos permitirá hacer algunas tareas, incluso acceder a la administración del vCenter a través de vSphere Web Client o vSphere Client, pero se nos cortará la conexión y otras tareas darán error.
Al final acabará yendo muy lento el acceso a la administración del vCenter (o fallando directamente) y si conseguimos acceder nos mostrará mensajes como:
- Health status monitoring.
- Lost connection.
Las máquinas virtuales no serán accesibles, o las marcará como inhabilitadas y con la etiqueta «Orphaned»:
A continuación indicamos cómo vaciar la base de datos SQL Server Express de VMware vCenter para liberar espacio y bajar de ese límite de 10 GB. Lo que haremos será eliminar datos estadísticos y de eventos, innecesarios, salvo para análisis y auditorías de problemas.
Antes de continuar, es imprescindible hacer copia de seguridad de la base de datos SQL Server Express
Puesto que vamos a realizar una tarea de eliminación de registros en la base de datos SQL Server Express, y dado que podríamos necesitar el histórico de eventos y estadísticas en algún momento para depurar algún posible error, es MUY conveniente realizar una copia de seguridad de toda la base de datos antes de continuar.
Podemos hacer la copia de seguridad usando Microsoft SQL Management Studio, en un software gratuito de Microsoft que podemos descargar e instalar y con él acceder a la gestión y administración de la base de datos SQL Server.
Una vez instalado nos conectaremos con un usuario administrador a la base de datos, pulsaremos con el botón derecho del ratón sobre la base de datos de vCenter (por defecto suele ser VIM_VCDB) y seleccionaremos «Tareas» – «Copia de seguridad…»:
Elegiremos la base de datos, en tipo indicaremos «Completa», marcaremos «Copia de seguridad en: Disco» (si no disponemos de unidad de cinta), elegiremos un destino pulsando «Agregar» y pulsaremos «Aceptar» para hacer la copia de seguridad:
Si queremos hacer el backup mediante script, desde la línea de comandos, sería algo así:
|
1 2 3 4 5 |
BACKUP DATABASE [VIM_VCDB] TO DISK = N'G:\backup\VIM_VCDB.bak' WITH NOFORMAT, NOINIT, NAME = N'VIM_VCDB-Completa Base de datos', SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO |
Liberar espacio de eventos y estadísticas en BD SQL Server de VMware vCenter
En primer lugar detendremos todos los servicios de vCenter, para ello accederemos a «services.msc» e iremos deteniendo los servicios:
Hay que tener en cuenta que al detener estos servicios el cluster vCenter dejará de funcionar, pero NO las máquinas virtuales que contenga, seguirán operativas aunque sin posibilidad de aplicarles tareas (migración, exportación, ..).
Copiaremos el siguiente script a un fichero de texto plano, que podemos abrir con el bloc de notas (notepad) y lo llamaremos «script_vaciar.sql», lo guardaremos en el raíz de C:
Abriremos una ventana de MS-DOS como administrador:
Y ejecutaremos el siguiente script:
|
1 |
sqlcmd -E -S localhost\VIM_SQLEXP -d VIM_VCDB -v TaskMaxAgeInDays=4 -v EventMaxAgeInDays=4 -v StatMaxAgeInDays=4 -i C:\script_vaciar.sql |
Donde:
- 4 indica el número de días a partir de los cuales se eliminarán los log. De esta forma podemos mantener los log de los últimos 4 días.
- localhost\VIM_SQLEXP: indicaremos aquí el nombre o IP del servidor de la base de datos y el nombre de la instancia.
- VIM_VCDB: nombre de la base de datos de vCenter.
- C:\script_vaciar.sql: la ubicación y el nombre del fichero sql de script a ejecutar.
El resultado del script:
sqlcmd -E -S localhost\VIM_SQLEXP -d VIM_VCDB -v TaskMaxAgeInDays=4 -v Event
MaxAgeInDays=4 -v StatMaxAgeInDays=4 -i C:\script_vaciar.sql
———————————————————
Database cleanup may take long time depends from size of
VPX_TASK, VPX_EVENT, VPX_SAMPLE_TIME1, VPX_SAMPLE_TIME2,
VPX_SAMPLE_TIME3, VPX_SAMPLE_TIME4
and all VPX_HIST_STATx_y tables
———————————————————-
Starting task cleanup at Oct 6 2017 12:09PM
———————————————————-
Starting event cleanup at Oct 6 2017 12:09PM
———————————————————-
Starting statistics cleanup at Oct 6 2017 12:11PM
———————————————————-
Starting cleanup orphan data at Oct 6 2017 12:11PM
———————————————————-
Done at Oct 6 2017 12:13PM
———————————————————-
Opción de eliminación de estadísticas y eventos de vCenter más drástica
Otra opción más drástica que la anterior es ejecutar el siguiente script (siguiendo los mismos pasos que en el caso anterior, cambiando el contenido del fichero SQL):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
Declare @current_table varchar(100) Declare @sqlstatement nvarchar(4000) --move declare cursor into sql to be executed set @sqlstatement = 'Declare table_cursor CURSOR FOR SELECT name FROM sys.tables where name like ''VPX_HI%'' or name like ''VPX_SAMPLE%''' exec sp_executesql @sqlstatement OPEN table_cursor FETCH NEXT FROM table_cursor INTO @current_table WHILE @@FETCH_STATUS = 0 BEGIN set @sqlstatement = 'truncate table ' + @current_table exec sp_executesql @sqlstatement FETCH NEXT FROM table_cursor INTO @current_table END CLOSE table_cursor DEALLOCATE table_cursor |
En este caso se eliminará todo el contenido de las tablas cuyo nombre empiece por VPX_HI y por VPX_SAMPLE. En el caso anterior nos permite indicar el número de días que queremos mantener los log.
Error 9002 The transaction log for database ‘VIM_VCDB’ is full en SQL Server
Si al ejecutar el script se produce el error:
Database cleanup may take long time depends from size of
VPX_TASK, VPX_EVENT, VPX_SAMPLE_TIME1, VPX_SAMPLE_TIME2,
VPX_SAMPLE_TIME3, VPX_SAMPLE_TIME4
and all VPX_HIST_STATx_y tables
Starting task cleanup at Oct 6 2017 9:02AM
Starting event cleanup at Oct 6 2017 9:02AM
Mensaje 9002, Nivel 17, Estado 4, Servidor servidorvcenter\VIM_SQLEXP, Procedimiento event_part_cleanup_np, Línea 39 The transaction log for database ‘VIM_VCDB’ is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
Puede ser debido a que la base de datos a alcanzado el tamaño máximo y no permitirá ejecutarlo, dado que el script hace algún insert para su correcto funcionamiento. Para solucionar este problema podemos obtener espacio adicional de la siguiente forma:
- Una opción es eliminar los ficheros de log de la BD, para ello abriremos SQL Server Management Studio (si no lo tenemos instalado lo podemos descargar de la web de Microsoft e instalarlo, es una herramienta gratuita). Una vez descargado e instalado accederemos al equipo con un usuario administrador, abriremos la aplicación SQL Server Management Studio y nos conectaremos a la base de datos del vCenter:
- A continuación pulsaremos con el botón derecho sobre la base de datos del vCenter y elegiremos «Tareas» – «Reducir» – «Archivos»:
- Seleccionaremos en «Tipo de archivo» la opción «Registro», en «Nombre de archivo» la opción «VIM_VCDB_log» y marcharemos «Liberar espacio no utilizado». Pulsaremos «Aceptar» para ejecutar el proceso:
Si lo queremos realizar mediante script desde la línea de comandos sería:
|
1 2 3 4 |
USE [VIM_VCDB] GO DBCC SHRINKFILE (N'VIM_VCDB_log' , 0, TRUNCATEONLY) GO |
Otra opción para liberar espacio en la base de datos es compactarla, para ello pulsaremos con el botón derecho del ratón sobre la base de datos, en el menú emergente elegiremos «Tareas» – «Reducir» – «Base de datos»:
Marcaremos la opción «Reorganizar archivos antes de liberar espacio no utilizado» y pulsaremos «Aceptar»:
Para hacerlo mediante script:
|
1 2 3 4 |
USE [VIM_VCDB] GO DBCC SHRINKDATABASE(N'VIM_VCDB' ) GO |
Liberar espacio de forma drástica vaciando tablas de log manualmente
Si ninguno de estos procesos anteriores libera espacio suficiente y el script de eliminación de estadísticas de la BD del vCenter sigue dando el mismo error, siempre podremos truncar alguna de las tablas que habitualmente ocupan mucho espacio, por ejemplo VPX_EVENT_ARG.
Desde la consola de SQL Server Management Studio, en «Nueva consulta», podemos ejecutar el siguiente SQL para mostrar el tamaño ocupado por todas las tablas:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
SELECT a3.name + '.' + a2.name AS [name], a1.rows AS [rows], (a1.reserved + ISNULL(a4.reserved, 0)) * 8 AS [Reserved KB], a1.data * 8 AS [Data KB], (CASE WHEN(a1.used + ISNULL(a4.used, 0)) > a1.data THEN(a1.used + ISNULL(a4.used, 0)) - a1.data ELSE 0 END) * 8 AS [Index_size KB], (CASE WHEN(a1.reserved + ISNULL(a4.reserved, 0)) > a1.used THEN(a1.reserved + ISNULL(a4.reserved, 0)) - a1.used ELSE 0 END) * 8 AS [unused KB], CONVERT(DECIMAL(18, 2), (((a1.reserved + ISNULL(a4.reserved, 0)) * 8) - ((CASE WHEN(a1.reserved + ISNULL(a4.reserved, 0)) > a1.used THEN(a1.reserved + ISNULL(a4.reserved, 0)) - a1.used ELSE 0 END) * 8)) / 1024.0 / 1024.0) AS [Table_used_Space GB] FROM ( SELECT ps.object_id, SUM(CASE WHEN(ps.index_id < 2) THEN row_count ELSE 0 END) AS [rows], SUM(ps.reserved_page_count) AS reserved, SUM(CASE WHEN(ps.index_id < 2) THEN(ps.in_row_data_page_count + ps.lob_used_page_count + ps.row_overflow_used_page_count) ELSE(ps.lob_used_page_count + ps.row_overflow_used_page_count) END) AS data, SUM(ps.used_page_count) AS used FROM sys.dm_db_partition_stats ps GROUP BY ps.object_id ) AS a1 LEFT OUTER JOIN ( SELECT it.parent_id, SUM(ps.reserved_page_count) AS reserved, SUM(ps.used_page_count) AS used FROM sys.dm_db_partition_stats ps INNER JOIN sys.internal_tables it ON(it.object_id = ps.object_id) WHERE it.internal_type IN(202, 204) GROUP BY it.parent_id ) AS a4 ON(a4.parent_id = a1.object_id) INNER JOIN sys.all_objects a2 ON(a1.object_id = a2.object_id) INNER JOIN sys.schemas a3 ON(a2.schema_id = a3.schema_id) WHERE a2.type != N'S' AND a2.type != N'IT' ORDER BY [Table_used_Space GB] DESC, [rows] desc ; |
En nuestro caso vemos que la tabla dbo.VPX_EVENT_ARG es la que más ocupa y, además, es una tabla de eventos que podría vaciarse, siempre con precaución.
Si decidimos varicarla, siempre haciendo copia de seguridad previamente, podemos hacerlo ejecutando el siguiente script (se puede ejecutar en una ventana de consulta de SQL Server Management Studio:
|
1 2 3 4 5 6 7 8 9 10 |
alter table VPX_EVENT_ARG drop constraint FK_VPX_EVENT_ARG_REF_EVENT, FK_VPX_EVENT_ARG_REF_ENTITY alter table VPX_ENTITY_LAST_EVENT drop constraint FK_VPX_LAST_EVENT_EVENT truncate table VPX_TASK truncate table VPX_ENTITY_LAST_EVENT truncate table VPX_EVENT truncate table VPX_EVENT_ARG alter table VPX_EVENT_ARG add constraint FK_VPX_EVENT_ARG_REF_EVENT foreign key(EVENT_ID) references VPX_EVENT (EVENT_ID) on delete cascade, constraint FK_VPX_EVENT_ARG_REF_ENTITY foreign key (OBJ_TYPE) references VPX_OBJECT_TYPE (ID) alter table VPX_ENTITY_LAST_EVENT add constraint FK_VPX_LAST_EVENT_EVENT foreign key(LAST_EVENT_ID) references VPX_EVENT (EVENT_ID) on delete cascade |
Teniendo en cuenta que este proceso vaciará las tablas VPX_TASK, VPX_ENTITY_LAST_EVENT, VPX_EVENT y VPX_EVENT_ARG por completo. En el script anterior se eliminan previamente las integridades referenciales para poder vaciar las tablas y luego se vuelven a crear.
Si se ejecuta el proceso anterior, será conveniente hacer una reorganización y compactación, como indicamos aquí.
