ESTADO: FGL-13215 se implementó en Foglight 5.6.10. Los cambios realizados en el tablero de instrumentos de gestión de datos para la directiva de retención de datos ahora se pueden aplicar a la configuración de almacenamiento de archivo global $ FGLHOME / config / storage-config.xml.
1) Comience FMS con modificador de la línea cmd -Dserver.persistence.config.update_storage_config = true
2) Solución de abajo ya no es necesaria si FMS es 5.6.10 o superior.
Solución:
NOTA: Oracle Database Repositorio: Por favor revise su archivo de almacenamiento-config.xml antes de la sustitución. Si el uso de espacios de tabla para la observación de datos, Índice, definiciones Lob, entonces esto va a requerir de editar su archivo de almacenamiento-config.xml existente en lugar de sustituir a los ejemplos adjuntos. Por favor, póngase en contacto con soporte técnico de Quest si usted tiene alguna pregunta como la modificación incorrecta del archivo de almacenamiento-config.xml puede causar problemas importantes.
El archivo de configuración $ FGL_HOME / config / storage-config.xml ($ FGL_HOME es donde instaló Foglight / vFoglight) es utilizada por el FMS para determinar cómo los datos de tiempo que se almacenan en la base de datos. Este archivo contiene 3 espacios de generación y los datos se mueven de una generación a la siguiente sobre la base de las políticas de retención configurados. Cambio del tamaño de la generación significa que el servidor no es capaz de almacenar datos durante más tiempo que la duración especificada.
Asegúrese de que el cambio apropiado se ha hecho a la sección de Política de retención de los datos Managment Dashboard. La directiva de retención y la necesidad de almacenamiento-config.xml para que coincida con el fin de evitar problemas y tener una base de datos de purga exitosa.
1) Storage-config.xml
Hemos proporcionado datos adjuntos de 5 tipos de valores storage finales más los predeterminados 100 Años en el archivo SOL52431.zip adjunto.
NOTA: Si necesita un valor almacenamiento final diferente, por favor póngase en contacto con Soporte de Quest para validar el valor de almacenamiento de su preocupación.
2-Semana-storage-config.xml
1-Mes-storage-config.xml
3-mes-storage-config.xml
6-Mes-storage-config.xml
1-Year-storage-config.xml
100-Year-storage-config.xml
1a) Por favor, extraiga el archivo correspondiente de su elección, así como cambiar el nombre del archivo en storage-config.xml
1b) Guarde la copia del archivo original en $ FGL_HOME / config y sustituir con su archivo storage-config.xml renombrado seleccionado.
2) los cambios de carga Almacenamiento-config.xml en el FMS
NOTA: Los nuevos valores deben cargarse en la consola JMX; un reinicio del servidor FMS no recogerá los cambios. Si no puede utilizar la consola JMX (en caso de que se ha desactivado) - se puede ejecutar este script desde la consola guión FMS para cargar el almacenamiento-config.xml
JMX CARGA: Una vez que el archivo ha sido modificado, los nuevos valores deben ser cargados en Foglight. Esto se puede hacer como sigue:
1. Inicie sesión en la consola JMX (http: // fmsmachinename: puerto / jmx-consola).
Es necesario utilizar el usuario foglight acceder jmx-consola. Si ya se conecte FMS con otro uso, obtendrá un error desminado acceso y necesita cerrar el navegador y acceder de nuevo
Aquí está un ejemplo de URL que puede utilizar, es necesario cambiar el nombre del servidor y número de puerto 8080 a su propio
http: // FMSServer: 8080 / jmx-consola
2. Haga clic en el enlace "servicio = de Almacenamiento" (bajo com.quest.nitro sección)
3. Busque "com.quest.nitro.service.persistence.obs.config.StorageConfiguration mergeConfiguration ()"
En el campo Nombre de archivo, escriba la ubicación / nombre del archivo de storage-config.xml modificado.
He aquí dos ejemplos, uno para UNIX, uno para Windows:
UNIX:
config / storage-config.xml
VENTANAS:
config \ storage-config.xml
Haga clic en invocar
4. Una actualización correcta resultará en la un mensaje similar al de abajo
StorageConfiguration: id = 1; version = 2,129; = 3 particiones-per-destino
5. Vuelva a la pantalla de Almacenamiento e invocar "java.lang.String diagnosticSnapshotAsString ()"
Obtener una captura de pantalla de esta pantalla como prueba se cargó el archivo storage.config. Este ejemplo es para una retención de 2 meses.
configuración LMACENAMIENTO: particiones num por destino = 3
generaciones:
Identificación del StorageGeneration = null; número = 0; version = 0; timeslice-size = 8 HORAS; generación-size = 3 DIA
Identificación del StorageGeneration = null; número = 1; version = 0; timeslice-size = 3 DIA; generación-size = 2 SEMANA
Identificación del StorageGeneration = null; número = 2; version = 0; timeslice-size = 1 MES; generación-size = 2 MESES
FMS script de carga: Ejecutar este de la consola de Script FMS si usted no tiene acceso jmx-consola.
com.quest.nitro.service.util.MBeanRef de importación;
javax.management.ObjectName importación;
def storageMgr = new MBeanRef (ObjectName.getInstance ("com.quest.nitro: Servicio de Almacenamiento =")) ref ();.
def storageConfigXml = "config / storage-config.xml";
storageMgr.mergeConfiguration (storageConfigXml);
Detalles de eliminación de datos
Si se encuentra en un estado de urgencia, consulte SOL97501 para forzar una purga.
Otra información - Gestión de datos: Eliminar y Purga Iconos
También hay opciones para eliminar y purgar en la pantalla de Gestión de Datos en la categoría de "gestionar los objetos supervisados". Como existe cierta confusión acerca de cómo funcionan, aquí es una explicación.
El botón "Eliminar" se acaba de eliminar el objeto de topología.
Las observaciones se mantendrán en la base de datos, sino que se elimina cuando las tablas en las que se encuentran está próximo enrollado (o truncado para las tables de más corto plazo).
La opción de "purga" salvará alguna configuración para registrar el hecho de que el usuario quiere descartar las observaciones mayores de cierta edad.
Si ha seleccionado Purga del Panel de administración de datos, a continuación, el PROCEDE con la tarea "fuera de las horas de mantenimiento de base de datos programada.
Fuera de las horas de mantenimiento de bases de datos: Horario para eliminar las observaciones de la base de datos. La tarea programada procesará todas las operaciones de purga configurados en una sola pasada sobre las tables de observación para descartar los valores de observación. Esto puede ser una operación costosa si el cliente tiene un montón de historia de observación en su base de datos. También puede no tener mucho efecto si los datos sólo se purgó durante un porcentaje bastante pequeño de objetos. Sería realmente sólo la pena pedir una purga si una cantidad significativa de datos necesita ser purgado. De lo contrario, puede ser que sea mejor utilizar sólo la opción "Borrar" y dejar que los valores de la edad a cabo.
Otra información - Best Practice Webcast para la conservación de datos
Información Adicional:
Tenga en cuenta que el cambio puede ser temporal para desencadenar los datos a ser purgados. Una vez que los datos más antiguos se ha eliminado, el tamaño de la generación se puede aumentar a permitir que los datos se conservarán durante un período de tiempo más largo. Suponiendo que las políticas de retención se han cambiado en el proceso del servidor se espera pueda retener sólo un conjunto más manejable de datos en el futuro.
No es una tarea periódica que se ejecuta en el servidor cada 5 minutos para comprobar las generaciones y se asegura de que las tablas necesarias están en su lugar. Los cambios realizados en el esquema son deliberadamente realizar lentamente para evitar los cambios de esquema, mientras que las operaciones se llevan a cabo sobre una mesa. Así que una vez que se ha cargado la configuración, se tardará unos 5 minutos para que el servidor de reconocer que hay mesas que ya no necesita. Se observará mensajes en el registro FMS con respecto a las fracciones de tiempo que se marcan como OBSOLETO. Minutos más tarde Fiver el servidor desasignará los timeslices. Mensajes entonces se registrarán sobre mesas para cambiar a un estado UNASSIGNED cuando se truncan.
Confirme que la purga se ha realizado mediante el examen de la instantánea de diagnóstico de la de Almacenamiento. Usted verá una salida como la siguiente:
Identificación del ObservationGeneration = 94998a1a197bc84701197bc92db40068; número = 2
Identificación del ObservationTimeslice = 94998a1a1ac5c13a011ad8484a6e0e82; start-time = 2008-07-01 00: 00: 00.0; tiempo del fin = 2008-08-01 00: 00: 00.0; ...
El ObervationGeneration será el número = 2 para la generación final que has cambiado, y usted debería ver ninguna entrada ObservationTimeslice con un tiempo del fin que se encuentra fuera del tamaño que usted hizo la generación.
Reclamar Tabla Espacial
MySQL con motor InnoDB no reduce el archivo de tablas, incluso después de truncar las tablas. Para reducir el tamaño del espacio de tablas, utilice el siguiente procedimiento:
1. Detenga el servidor de administración de Foglight:
$ FOGLIGHT_HOME \ bin \ fms -q
2. Inicie el servidor MySQL:
$ FOGLIGHT_HOME \ bin \ runDb.bat
3. Utilice mysqldump para volcar todas las tablas InnoDB:
cd $ FOGLIGHT_HOME \ mysql \ bin
mysqldump -P [dbPort] -u [dbuser] -p [DBPwd] -e -q -R -B [dbname] -r mysqldata.sql
Nota: Sustituya el correcto nombre de usuario, contraseña, puerto, y dbname.
Servidor 4. Dejar de MySQL:
$ FOGLIGHT_HOME \ bin \ shutdownDb.bat
5. Retire todos los ficheros InnoDB existentes:
cd $ FOGLIGHT_HOME \ mysql \ data
del ib_log *
del ibdata *
6. Reinicie el servidor MySQL:
$ FOGLIGHT_HOME \ bin \ runDb.bat
7. Importe los archivos de volcado:
cd $ FOGLIGHT_HOME \ mysql \ bin
mysql -P [dbPort] -u [dbuser] -p [DBPwd] <mysqldata.sql
Nota: Sustituya el correcto nombre de usuario, contraseña y puerto.
8. Detener servidor MySQL.
$ FOGLIGHT_HOME \ bin \ shutdownDb.bat
9. Reiniciar servidor Foglight Gestión.
$ FOGLIGHT_HOME \ bin \ fms
Nota: Para Oracle y Microsoft SQL Server, por favor pregunte a su DBA para obtener ayuda.
© 2022 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Términos de uso Privacidad