Usando Egdbhealth en el Diseño de Sistemas

DannyKrouk_ps

<\/HEAD>

Introducción<\/a><\/li>Objetivos de Información para el Diseño del Sistema<\/a><\/li>Recursos y Utilización de la Máquina<\/a><\/li>La Máquina<\/a><\/li>La Utilización<\/a><\/li>Procesador<\/a><\/li>Memoria<\/a><\/li>Almacenamiento<\/a><\/li>Inventario de Datos e Intercambio de Datos<\/a><\/li>Conteo de Registros y Almacenamiento por ObjectClass<\/a><\/li>Versionado, Archivado y Estado de Replicación<\/a><\/li>Consideración de Diseño de Datos Distribuidos<\/a><\/li>Datos Versionados y Replicación de Geodatabase<\\/a><\\/li>Archivado de Datos e Intercambio de Datos<\\/a><\\/li>Tamaño del Attachment y Sincronización Móvil<\\/a><\\/li>Resumen<\\/a><\\/li><\\/ul><\\/H2>

Nota: Esta publicación del blog es la tercera en la serie de tres publicaciones planificadas sobre egdbhealth. La primera describió la introducción a la herramienta, cómo instalarla y cómo ejecutarla. La segunda en la serie abordó cómo usar la herramienta para evaluar la salud de un Enterprise Geodatabase; su propósito principal. Este artículo aborda el uso de egdbhealth en un contexto de diseño del sistema.<\/> <\/>

Introducción<\/> Egdbhealth es una herramienta para reportar diversas características de Enterprise Geodatabases (eGDBes). El propósito principal de la herramienta es evaluar la "salud" de los eGDBes. Sin embargo, la salida también puede usarse en un contexto de diseño del sistema. Este artículo aborda el caso de uso del diseño del sistema.<\/> Para información sobre cómo instalar y ejecutar la herramienta, por favor refiérase a la primera publicación del blog en esta serie "¿Qué es Egdbhealth?"<\/><\/> Objetivos de Información para el Diseño del Sistema<\/> La práctica de diseño del sistema Esri se enfoca en planificar las características de hardware, software y red para el estado futuro de los sistemas basados en requisitos nuevos o cambiantes.<\/> La salud actual de un sistema existente no necesariamente tendrá una relación fuerte con un sistema futuro que tenga requisitos diferentes. Sin embargo, dependiendo de los objetivos del diseño, la información sobre el sistema actual puede ser relevante.<\/> Por ejemplo, en el caso de una migración planificada desde un sistema on-premises a una plataforma cloud, sería bastante útil describir el sistema actual tal que pueda ser fielmente representado en una plataforma cloud. O bien, los requisitos que impulsan un diseño pueden indicar la necesidad de intercambiar (replicar, mover, sincronizar, transformar, copiar, etc.) grandes porciones de una Geodatabase a otro repositorio. En ese caso, un inventario del contenido de la Geodatabase puede ser útil para establecer detalles importantes sobre la naturaleza y cantidad de datos que necesitarían ser intercambiados y las formas óptimas para que ese intercambio ocurra.<\/> Así, a un nivel alto, es principalmente la información descriptiva de egdbhealth, más que la información evaluativa, lo que es pertinente para el diseño del sistema.<\/> Este artículo discute ejemplos para un eGDB respaldado por SQL Server. Sin embargo, los principios son los mismos para eGDBes respaldados por Oracle y PostgreSQL.<\/> Recursos y Utilización de la Máquina<\/> Para casos de diseño del sistema donde la plataforma máquina del eGDB cambiará, puede ser útil entender los recursos actuales de la máquina que soportan el eGDB y su grado de utilización. Por ejemplo, si está migrando un eGDB a una plataforma cloud, el número de núcleos procesadores que el sistema tiene on premises tiene cierta relevancia para el número que podría desplegar en cloud.<\/> La Máquina<\/> El archivo metadata HTML producido por egdbhealth proporcionará información sobre los recursos acerca de la plataforma máquina en la cual corre el RDBMS.<\/> En el ejemplo abajo, la instancia SQL Server corre en una máquina con un procesador que presenta 8 núcleos lógicos procesadores.<\/> Esta información desde SQL Server deja alguna información poco clara. Por ejemplo, SQL Server no puede reportar si los núcleos lógicos son resultado del hyperthreading. Si lo son, entonces los núcleos físicos serían la mitad de los núcleos lógicos (4 núcleos físicos). Y es el número de núcleos físicos lo más útil para planificación de capacidad en diseño del sistema. Así que esta información es buena pero imperfecta.<\/> El HTML también reporta la memoria física en la máquina (16GiB) y la memoria mínima y máxima configurada para la instancia SQL Server (0 y 3GB). Aquí vemos que la configuración de la instancia SQL Server es bastante relevante para entender los recursos relevantes de memoria para planificación de capacidad. Aunque la máquina tiene 16GiB de memoria, esta instancia SQL Server (y el eGDB que soporta) no tiene acceso a toda esa memoria.<\/> La Utilización<\/> Las características de la máquina y la configuración de la instancia ofrecen una visión incompleta sobre el grado al cual los recursos máquina son utilizados y qué recursos son realmente necesarios para la carga actual.<\/> Podemos estar seguros que SQL Server no usa más que 3GB de memoria. Pero ¿la usa completamente? ¿Y qué hay sobre los recursos del procesador? ¿Están ocupados o inactivos?<\/> Mucha información sobre utilización aparece en el archivo Expert Excel porque es relativamente volátil.<\/> Procesador<\/> En el caso SQL Server, hay una evaluación en el archivo Expert Excel llamada "ProcessorUtil" (Utilización del Procesador; La Categoría es "Instance"). Proporciona una muestra reciente por minuto del uso del procesador por SQL Server en la máquina. En este caso podemos ver que durante el período muestreado SQL Server usa casi ninguno de los recursos totales del procesador en la máquina donde corre.<\/> De esto inferimos que si este período es típico, la máquina existente tiene muchos más recursos procesadores que necesita. Si todo lo demás es igual, el diseño futuro del sistema puede especificar menos núcleos procesadores para soportar la carga eGDB. Naturalmente, para que esta inferencia tenga integridad debe ejecutar la herramienta durante períodos típicos y/o picos de carga.<\/> Hay otro evaluación, CpuByDb (categoría de Instancia), que informa qué bases de datos en la instancia consumen la mayoría de los recursos del procesador.  Entonces, en el caso de que la instancia tuviera una utilización significativa del procesador, esta información podría usarse para determinar si esa utilización del procesador estaba relacionada con la eGDB de interés o con alguna otra carga de trabajo en la misma instancia de SQL Server.<\/P><\/P><\/P><\/P>Memoria<\/H4>En el caso de SQL Server, hay varias evaluaciones que proporcionan información sobre la utilización de memoria dentro de la instancia.  La mayoría de estas están en la categoría Instancia del archivo Expert Excel.<\/P><\/P>MemoryByDb le permite ver la cantidad de memoria (en este caso, filas de datos en lugar de sentencias SQL u otro consumo de memoria) utilizada por cada base de datos.<\/P><\/P><\/P><\/P>En este caso, vemos que la eGDB "GIS" es el principal consumidor de memoria en la instancia SQL Server.  Por lo tanto, parece razonable entender que la eGDB puede hacer uso de la mayor parte de los 3GB de memoria de la instancia.  Pero, ¿es eso demasiado o no suficiente para un buen rendimiento y salud del sistema?<\/P><\/P>La evaluación MemoryMetrics informa sobre varias métricas de memoria que pueden ofrecer pistas sobre cuán demandada está la memoria de la instancia.  En este caso, vemos que hay advertencias que sugieren que la memoria disponible existente en la instancia puede ser demasiado baja para la carga de trabajo.  Por lo tanto, no sabemos si 16GiB de memoria máquina es demasiado o muy poco.  Pero, tenemos razones para creer que 3GB de memoria en la instancia es muy poco.<\/P><\/P><\/P><\/P>Hay varias otras evaluaciones de memoria en el archivo Expert Excel.  Se requiere experiencia y juicio para integrar estas observaciones en un juicio informado sobre las verdaderas necesidades de memoria del sistema.   En este caso, como en muchos otros, las inferencias que se pueden hacer son incompletas.  Pero, son mejores que nada.<\/P><\/P>Almacenamiento<\/H4>SQL Server no proporciona información completa sobre el almacenamiento local en la máquina donde se ejecuta.  Sin embargo, sí proporciona información sobre el tamaño de los archivos en los que se almacena la eGDB.  Gran parte de esta información está disponible en la categoría "Database" del archivo Expert Excel.<\/P><\/P>La hoja FileSpace evaluation informa sobre los archivos en los que se almacena la eGDB.  En este ejemplo, vemos que hay un solo archivo de datos ("ROWS") que tiene aproximadamente 6GB y un solo archivo de registro de transacciones ("LOG") que ha usado alrededor de 650MB en el pasado.  También puede ver los límites máximos establecidos por el DBA, presumiblemente como indicación del almacenamiento máximo esperado para la eGDB.<\/P><\/P><\/P><\/P>Estos datos son buenas indicaciones sobre la cantidad de almacenamiento que se necesitaría para un escenario "lift and shift" donde toda la eGDB necesitará moverse a una plataforma diferente.<\/P><\/P>Inventario y Intercambio de Datos<\/H2>Otro caso en el diseño del sistema es cuando los datos eGDB necesitan ser intercambiados con un repositorio diferente, quizás otra Geodatabase en un centro de datos distinto.  En estos casos, puede ser relevante establecer el tamaño del almacenamiento y otras características de los datos que serán intercambiados, en lugar del tamaño total del almacenamiento completo de la eGDB.<\/P><\/P>Conteo de Registros y Almacenamiento Por ObjectClass<\/H3>Si conoce la identidad de los ObjectClasses a intercambiar, hay información en el archivo Content Excel para informar sobre el tamaño del almacenamiento y conteo de registros esos elementos. <\/P><\/P>En la categoría Storage, hay una hoja llamada "ObjClass" (ObjectClasses).  Informa, con bastante detalle, las tablas que componen varios ObjectClasses eGDB, el número de filas que contienen y la cantidad de almacenamiento asignado a cada uno. <\/P><\/P>En el ejemplo a continuación, hay tres ObjectClasses de interés (filtrados en la primera columna): BUILDINGS_NV, COUNTRIES y SSFITTING.  BUILDINGS_NV tiene alrededor de 4.400 registros y consume poco más de 1.25MB espacio.  COUNTRIES está versionado, con 249 registros en la tabla base, 66 adiciones y 5 eliminaciones (la columna TableName indica los nombres "A" y "D" para ObjectClasses versionados).<\/P><\/P><\/P><\/P>Por lo tanto, podemos establecer el conteo aproximado y las características del almacenamiento para ObjectClasses relevantes dentro del eGDB.  Al mismo tiempo, también podemos ver qué ObjectClasses están registrados como versionados.  Esta es información crítica para establecer el rango opciones disponibles para intercambio de datos.<\/P><\/P>Estado Versionado, Archivado y Replicación<\/H3>En el mismo archivo Context Excel, ObjClassOverview (categoría Inventory) proporciona una visión general sobre los estados versionado, archivado y replicación para todos los ObjectClasses dentro del eGDB.  Esto ofrece un mecanismo más conveniente para planificar el rango mecanismos apropiados para diferentes ObjectClasses.<\/P><\/P>

Consideración Diseño Datos Distribuidos
La documentación ArcGIS se refiere a esta área temática como "distributed data" y ofrece orientación general sobre las diversas estrategias que pueden usarse para mover datos: http://desktop.arcgis.com/en/arcmap/latest/manage-data/geodatabases/understanding-distributed-data.htm.

Datos Versionados y Replicación Geodatabase
Si un ObjectClass no está ya registrado como versionado puede o no ser apropiado hacerlo con fines del uso Geodatabase Replication.  Esto se relaciona con cómo se actualizan los datos.  La mayoría datos registrados como versionados se actualizan "transactionally", lo que significa que solo un pequeño porcentaje total registros cambian en cualquier momento dado.  Este tipo actualización es compatible tanto con versioning como Geodatabase Replication.  Otros datos se actualizan con métodos como "truncate and add", "delete and replace", o "copy and paste."  En estos casos, la mayoría registros se actualizan físicamente (incluso si mayoría valores registro son iguales, registros físicos han sido reemplazados).  Ese tipo actualización no es particularmente adecuado para Geodatabase Replication.  La información en egdbhealth puede decirle sobre estado versioning y replicación ObjectClasses.  Pero no sabe cómo esos ObjectClasses son realmente actualizados.  Esperemos que aquellos registrados como versioned sean actualizados transactionally y por lo tanto candidatos adecuados para Geodatabase Replication.


Archivado Datos e Intercambio Datos
Si un ObjectClass tiene archivado habilitado puede haber consideraciones adicionales.  Por ejemplo, si intercambio planeado podría aumentar tasa actualizaciones esto podría causar crecimiento indeseable cantidad información archivada.


Para ObjectClasses versioned habilitados archivado información archivada se almacena tabla separada "history."  Tamaño esa tabla no impacta rendimiento consulta datos versioned.  En este caso consideración principal diseño es si es práctico persistir usar toda información archivada.  En muchos casos será así.  Pero determinarlo requiere conocer estado archivado ObjectClass y tasa planeada actualizaciones.


En caso ObjectClasses no-versioned habilitados archivado (y branch-versioned ObjectClasses), información archivada está tabla principal.  Por lo tanto rápido crecimiento información archivada puede cambiar necesidades ajuste rendimiento ObjectClasses y\u002For eGDB.  Egdbhealth no puede conocer futuras necesidades actualización datos.  Sin embargo puede informar patrones históricos actualizaciones a ObjectClasses no-versioned habilitados archivado.  Archivo Context Excel contiene hoja "NvArchEditDatesSql" con sentencias SQL para cada ObjectClass no-versioned habilitado archivado dentro eGDB.  Estas sentencias no se ejecutan automáticamente porque son consultas intensivas recursos que no proporcionan información relevante a todas circunstancias.


<\/P><\/P>En este caso de diseño de sistema, sin embargo, establecer la tasa a la que los registros se han acumulado con el tiempo puede ser bastante pertinente para planificar una estrategia de intercambio de datos.  Utilice un cliente SQL como SQL Server Management Studio para ejecutar las consultas para los ObjectClasses en cuestión y obtener una idea de la tasa de actualización de datos.  En este ejemplo, podemos ver un patrón para las actualizaciones de registros donde la actualización típica es pequeña (1 registro), pero hubo al menos una ocasión en la que hubo una gran actualización en relación con el tamaño del ObjectClass (289 registros el 8 de abril de 2018):<\/P><\/P><\/P><\/P>Tamaño del adjunto y sincronización móvil<\/H5>Otro caso de diseño que se relaciona con datos distribuidos es la recopilación de datos basada en campo y los adjuntos.  Collector for ArcGIS utiliza mecanismos eficientes similares a Geodatabase Replication para sincronizar "deltas" entre cliente y servidor.  Sin embargo, la capacidad de recopilar grandes cantidades de datos en adjuntos (como imágenes) y las condiciones de red a menudo limitadas en las que se pueden sincronizar los datos pueden plantear problemas de diseño del sistema.<\/P><\/P>El archivo Expert Excel tiene una evaluación "LargeAttachments" que automáticamente llamará su atención sobre casos probablemente preocupantes.  En el ejemplo a continuación, no se violaron los valores umbral, por lo que no hubo una evaluación negativa:<\/P><\/P><\/P><\/P>Sin embargo, aún puede ser útil saber algo sobre la naturaleza de los adjuntos existentes.  El archivo Context Excel contiene una hoja "AttachmentSizeSql" (categoría "Inventory") que contiene varias sentencias SQL para cada ObjectClass que tiene adjuntos. <\/P><\/P><\/P><\/P>Ejecutar estas sentencias SQL en un cliente como SQL Server Management Studio le permite caracterizar estadísticamente los adjuntos de varias maneras: estadísticas agregadas, top 100 por tamaño y distribución percentil. <\/P><\/P><\/P><\/P>Con estas estadísticas, puede entender no solo la cantidad total de información, sino si se debe a un gran número de adjuntos pequeños o a un pequeño número de adjuntos grandes.  Los adjuntos grandes podrían representar un mayor riesgo para sincronizarse en condiciones de red pobres y podrían llevarlo a recomendar que la recopilación de datos opere en modo desconectado y que la sincronización ocurra solo bajo condiciones específicas de red.<\/P><\/P>Las consideraciones sobre el tamaño del adjunto también podrían llevarlo a ofrecer recomendaciones sobre si y cómo sería práctico manejar la sincronización bidireccional (en lugar de unidireccional).  Mientras que los usuarios basados en campo podrían tener circunstancias de red suficientes para subir los adjuntos que recopilan individualmente, la sincronización bidireccional significaría que todos los adjuntos recopilados por otras personas (en el área de sincronización) tendrían que descargarse.  En algunos casos, esto podría ser muchas veces la cantidad de información que necesitaría subirse.<\/P><\/P>Resumen<\/H2>Como diseñador de sistemas GIS, no es práctico que tenga un conocimiento profundo en todas las áreas tecnológicas relacionadas con el sistema.  Por esta razón, su comprensión de las salidas egdbhealth y lo que puede hacer con ellas tiene límites.  El propósito de este artículo es identificar algunos de los casos de uso más comunes para las salidas egdbhealth para el diseño del sistema.  Las principales áreas de interés son (1) dimensionamiento de máquinas / utilización de recursos y (2) características de datos relevantes para el intercambio de datos.  Seguir los ejemplos en este artículo, y generalizar a partir de ellos para las bases de datos Oracle y PostgreSQL, le permitirá extraer información útil de la herramienta egdbhealth para su trabajo de diseño.<\/P><\/P>Espero que esto le sea útil, no dude en publicar sus preguntas aquí: https:\/\/community.esri.com\/thread\/231451-arcgis-architecture-series-tools-of-an-architect<\/SPAN><\/A><\/SPAN><\/P> <\/SPAN><\/P>Nota:<\/_EM> Los contenidos presentados arriba son recomendaciones que típicamente mejorarán el rendimiento para muchos escenarios. Sin embargo, en algunos casos, estas recomendaciones pueden no producir mejores resultados en rendimiento, en cuyo caso podrían ser necesarias pruebas adicionales de rendimiento y modificaciones en la configuración del sistema.<\/_EM>