Es bueno, especialmente en "bases de conocimiento" (KB) que han pasado por varias versiones de Genexus, chequear su "estado de salud".
En este sentido KBDoctor es una herramienta que ayuda mucho, principalmente desde el punto de vista del "modelo" Genexus (atributos, calls, definiciones de variables, etc) representado en una KB.
También es útil revisar la salud de los archivos que lo soportan. Hasta la 9.0 eran archivos C-tree (los famosos .DAT) que tenían indices (los famosos .IDX) y teníamos en "rebuild -y" que mejoraba esos archivos y sobre todo reconstruía los indices.
A partir de la X las KBs se almacenan en MS SQL Server por lo cual la administración de la misma pasó de ser un "file server" a un "database server".
En este sentido algo que me ha dado muy buenos resultados es el "CheckKnowledgeBase".
Esta es una tarea msbuild (disponible a partir de la versión X Evolution 1 Upgrade 3) que recorre la base de datos que contiene la KB chequeando la consistencia de la misma, defragmentando indices (si se requiere), etc
¿Cómo usarla?
1. Copiar el siguiente contenido en un archivo TXT, llamado por ejemplo: CheckKB.msbuild.
<Project DefaultTargets="CheckKB" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="C:\Program Files (x86)\Artech\GeneXus\GeneXusXEv3U1\Genexus.Tasks.targets" />
<Target Name="CheckKB">
<OpenKnowledgeBase Directory="C:\kbs\MyKB" />
<CheckKnowledgeBase Fix="true" />
</Target>
</Project>
2. Sustituir el directorio de instalación de Genexus por el correcto en su instalación y el directorio de la KB por la KB que se quiere "revisar/diagnosticar"
3. Ejecutar: "msbuild Check.msbuild"
Notar que "msbuild" es un comando incluído con el .NET Framework. Personalmente abro una ventana de DOS (como administrador) y ahí en el directorio del Framework 3.5 de 32 bits ejecuto:
C:\Windows\Microsoft.NET\Framework\v3.5>msbuild c:\utils\CheckKB.msbuild
4. En el output aparecerá algo similar a:
"C:\Windows\Microsoft.NET\Framework\v3.5>msbuild c:\utils\checkKb.msbuild
Microsoft (R) Build Engine Version 3.5.30729.6387
[Microsoft .NET Framework, Version 2.0.50727.6413]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
Build started 14/08/2014 18:52:39.
Project "c:\tmp\checkKb.msbuild" on node 0 (default targets).
========== Open Knowledge Base Task started ==========
> Open Knowledge Base Task Success
========== Open Knowledge Base Task finished ==========
========== Check Knowledge Base started ==========
c:\tmp\checkKb.msbuild : warning : "Fix" parameter specified. Running checks and fixing issues.
Step 1: Check KnowledgeBase's database integrity
Index 'PK__Entity__023D5A04' in table 'Entity' is highly fragmented and should be rebuilt. Rebuilding this index may take some time but reduces fragmentation and improves index performance.
Index 'IEntityGuid' in table 'Entity' is highly fragmented and should be...."
así varios pasos más: entidades, redundancia, dominios enumerados internos, etc.
Notas importantes:
1. Respaldar la KB antes de ejecutar el comando.
Personalmente eso lo hago deteniendo el SQL Server y copiando el MDF.
2. El comando puede demorar, dependiendo de la KB, máquina, el estado de la fragmentación, etc.
En mi máquina por ejemplo una de 13.000 objetos demoró unos 20 minutos
3. Si se desea solo chequear el estado modificar el CheckKB.msbuild sustituyendo la linea:
"<CheckKnowledgeBase Fix="true" />" por "<CheckKnowledgeBase Fix="false" />
4. Las tareas que incluye el "CheckKnowledgeBase" dependen de la versión de Genexus que se utilice. En particular la defragmentación de indices está disponible a partir del X Evolution 2 U6 y X Evolution 3
Agradecimientos a @fedeazzato y @PabloMazzilli
En este sentido KBDoctor es una herramienta que ayuda mucho, principalmente desde el punto de vista del "modelo" Genexus (atributos, calls, definiciones de variables, etc) representado en una KB.
También es útil revisar la salud de los archivos que lo soportan. Hasta la 9.0 eran archivos C-tree (los famosos .DAT) que tenían indices (los famosos .IDX) y teníamos en "rebuild -y" que mejoraba esos archivos y sobre todo reconstruía los indices.
A partir de la X las KBs se almacenan en MS SQL Server por lo cual la administración de la misma pasó de ser un "file server" a un "database server".
En este sentido algo que me ha dado muy buenos resultados es el "CheckKnowledgeBase".
Esta es una tarea msbuild (disponible a partir de la versión X Evolution 1 Upgrade 3) que recorre la base de datos que contiene la KB chequeando la consistencia de la misma, defragmentando indices (si se requiere), etc
¿Cómo usarla?
1. Copiar el siguiente contenido en un archivo TXT, llamado por ejemplo: CheckKB.msbuild.
<Project DefaultTargets="CheckKB" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="C:\Program Files (x86)\Artech\GeneXus\GeneXusXEv3U1\Genexus.Tasks.targets" />
<Target Name="CheckKB">
<OpenKnowledgeBase Directory="C:\kbs\MyKB" />
<CheckKnowledgeBase Fix="true" />
</Target>
</Project>
2. Sustituir el directorio de instalación de Genexus por el correcto en su instalación y el directorio de la KB por la KB que se quiere "revisar/diagnosticar"
3. Ejecutar: "msbuild Check.msbuild"
Notar que "msbuild" es un comando incluído con el .NET Framework. Personalmente abro una ventana de DOS (como administrador) y ahí en el directorio del Framework 3.5 de 32 bits ejecuto:
C:\Windows\Microsoft.NET\Framework\v3.5>msbuild c:\utils\CheckKB.msbuild
4. En el output aparecerá algo similar a:
"C:\Windows\Microsoft.NET\Framework\v3.5>msbuild c:\utils\checkKb.msbuild
Microsoft (R) Build Engine Version 3.5.30729.6387
[Microsoft .NET Framework, Version 2.0.50727.6413]
Copyright (C) Microsoft Corporation 2007. All rights reserved.
Build started 14/08/2014 18:52:39.
Project "c:\tmp\checkKb.msbuild" on node 0 (default targets).
========== Open Knowledge Base Task started ==========
> Open Knowledge Base Task Success
========== Open Knowledge Base Task finished ==========
========== Check Knowledge Base started ==========
c:\tmp\checkKb.msbuild : warning : "Fix" parameter specified. Running checks and fixing issues.
Step 1: Check KnowledgeBase's database integrity
Index 'PK__Entity__023D5A04' in table 'Entity' is highly fragmented and should be rebuilt. Rebuilding this index may take some time but reduces fragmentation and improves index performance.
Index 'IEntityGuid' in table 'Entity' is highly fragmented and should be...."
así varios pasos más: entidades, redundancia, dominios enumerados internos, etc.
Notas importantes:
1. Respaldar la KB antes de ejecutar el comando.
Personalmente eso lo hago deteniendo el SQL Server y copiando el MDF.
2. El comando puede demorar, dependiendo de la KB, máquina, el estado de la fragmentación, etc.
En mi máquina por ejemplo una de 13.000 objetos demoró unos 20 minutos
3. Si se desea solo chequear el estado modificar el CheckKB.msbuild sustituyendo la linea:
"<CheckKnowledgeBase Fix="true" />" por "<CheckKnowledgeBase Fix="false" />
4. Las tareas que incluye el "CheckKnowledgeBase" dependen de la versión de Genexus que se utilice. En particular la defragmentación de indices está disponible a partir del X Evolution 2 U6 y X Evolution 3
Agradecimientos a @fedeazzato y @PabloMazzilli
Esta bueno que en las nuevas versiones ya defragmente los indices.. Hasta ahora habia logrado corregir varios errores de subtipos y atributos que quedaban mal definidos cuando alguien cambiaba algun dominio y problemas similares, que siempre daban dolor de cabeza.
ResponderBorrarSi ahora defragmenta los indices, es un motivo mas para ponerlo en una tarea que corra de noche en las KB importantes.
Como SUGERENCIA, estaría bueno que esto se pueda ejecutar desde el menu en el IDE de GeneXus, para no obligar a las personas a programar tareas batch que a mucha gente le da pereza.
Si, la idea en realidad era en el "open KB" analizar la fragmentación de los indices y de acuerdo a cómo estén ofrecer al usuario ejecutar o no la defragmentación porque puede demorar.
BorrarEso resulto algo "costoso" y para no cargar el Open KB no lo pusimos ahí así que creo que pronto será una opción del menú.
Este comentario ha sido eliminado por el autor.
ResponderBorrarAgrego algunas acotaciones:
ResponderBorrarYo ejecuté el proceso y luego de casi 20 horas tuve que cortarlo.
Nuestra KB tiene alrededor de 9000 objetos.
El proceso tiene 6 Steps en total.
En el Step 5 se dedica a la siguiente tarea "Fixing properties redundancies in all objects in version" por cada Version que tenga la KB.
Cada Versión de nuestra KB demoraba cerca de 1 hora por cada versión y teníamos alrededor de 25 versiones.
La recomendación es borrar todas las versiones que se estén usando a modo de backup antes de correr el proceso.
La otra recomendación es hacer un Shrink de la KB luego de correr este proceso porque éste genera aumentos importantes en el tamaño de la KB.
Hola Gustavo, estuve haciendo pruebas con esto y lo que me llama la atención es que después de ejecutar el procesos varias veces sigue arrojando los mismos mensajes sobre los índices como que hay índices que no defragmenta los índices (Step 1). Lo raro es que la primera vez dice: "53 issue(s) found, 53 fixed". La segunda vez dice: 24 issue(s) found, 24 fixed. La tercera vez dice: 23 issue(s) found, 23 fixed. Para el resto de los pasos si quedaron en 0 (cero) en la segunda ejecución. Que puede estar pasando?
ResponderBorrarEl proceso hace varias cosas (chequea redundancias, etc). Entre ellas chequea el estado de fragmentación de los indices.
BorrarO sea,le pregunta al SQL Server el % de fragmentación de cada indice.
Si un indice está menos de 5% fragmentado no hace nada.
Si está entre 5% y 30% hace un reorganize (ALTER INDEX ...ON ...REORGANIZE;)
Si está por encima del 30% fragmentado hace un rebuild (ALTER INDEX ... ON... REBUILD)
En el output debería aparecer como ""slightly fragmented" o "highly fragmented"de acuerdo a ese valor.
Lo unico que se me ocurre, si esos mensajes son del "step 1" que es cuando se reconstruyen los indices, es que esté con fragmentación entre 5% y 30% y que cada pasada reduzca la misma de modo que en algun momento quedan por debajo del 5%.
O sea, en la primera pasada encontró 53, hice "reorganize" y en la segunda pasada solo quedaron 24 y asi sucesivamente. Eventualmente termina defragmentandolo
Este comentario ha sido eliminado por el autor.
ResponderBorrar