Limpiar base de datos

La base de datos Navision sólo conoce una dirección: ¡crecer! Pero este comportamiento debería (¡debe!) detenerse de vez en cuando.

Por cierto... ¡también se pueden borrar datos en el viejísimo Navision 3.56 azul de DOS!

¿Está buscando una forma de eliminar usuarios en Navision / Business Central para acceder a una copia de seguridad de la base de datos, por ejemplo?

¿Por qué borrar datos en Navision?

Hay buenas razones para limpiar / comprimir / reducir el tamaño de una base de datos Navision. Y también para eliminar datos que ya no se necesitan:

• Velocidad de búsqueda
  Cuantos menos registros de datos tenga que buscar Navision, más rápido podrán ofrecer un resultado las búsquedas o los filtros. Esto a menudo resulta en un retraso apenas perceptible o tolerable de unos pocos segundos en el proceso individual para Navision por usuario. En general, sin embargo, ralentiza el Business Central SQL Server y retrasa repetidamente el flujo de trabajo de forma perceptible o imperceptible para toda la empresa, para todos los empleados.
  Es muy molesto cuando se busca
  -la última nota de entrega de Navision
  -el último pedido de Business Central
  -la última factura de Business Solutions NAV
  : En realidad , basta con CTRL+Fin, y ya estoy en el último comprobante. No es así si formateas los números de comprobante según los años (LS99.12345), y luego has empezado en 1999, por ejemplo. Entonces los documentos que empiezan por 99... ¡bloquean la vista de los documentos actuales (20...21...22...)! ¡No subestime el esfuerzo de búsqueda (gasto de tiempo) de sus usuarios! ¡Esto puede empeorar el rendimiento general de Navision (velocidad de trabajo) incluso más que todos los demás frenos de su servidor SQL!
• Workflow
  Hunderte, tausende oder gar 10-tausende von nicht mehr / nie mehr benötigten Navision-Belegen (Lieferscheine, Rechnungen, Angebote) und nie wieder benötigten Business Central Stammdaten wie Kunden (Debitoren), Lieferanten (Kreditoren), Artikel und Sachkonten hindern den Arbeitsfluss. Ist jetzt der Müller Schulze o Müller Schultze el cliente correcto? Ah, otra vez el equivocado... Y aquí también el rendimiento de sus empleados se resiente mucho más que de los breves tiempos de espera, a menudo imperceptibles, de la base de datos SQL de Navision.
• Tiempo administrativo
  Para reorganizaciones de bases de datos nativas de Navision, para la optimización clave de bases de datos SQL de Business Central, para copias de seguridad de datos, restauraciones de datos, creación de entornos de pruebareplicación de cambios de bases de datos en sistemas de alta disponibilidad: Una y otra vez, gigabytes de datos innecesarios son exprimidos a través de las líneas de red ya crónicamente sobrecargadas. Esto también deprime enormemente el rendimiento de su procesamiento de datos. Las copias de seguridad en cinta tardan cada vez más, las copias de seguridad en disco duro cada vez tienen más capacidad. Así, una base de datos Navision (SQL) o Business Central SQL innecesariamente grande también se hace notar en céntimos o euros.
• REGLAMENTO GDPR
  Este punto prácticamente siempre se olvida. Sin embargo, el GDPR es un auténtico campo de minas. Su obligación legal de archivo para las autoridades fiscales (GDPdU) finaliza al expirar el décimo año después de la última contabilización fiscal relevante. Si, por ejemplo, una factura del 31.12.2010 se paga el 02.01.2011 con un descuento, la obligación de archivar el pago expira el 31.12.2021. Esto significa también que expira la obligación de archivar la factura y, por tanto, los datos personales asociados. Usted ya no tiene derecho a seguir almacenando los datos personales de este proceso. O bien elimina los datos personales de este documento (destinatario de la factura, dirección IP...) y de todos los documentos asociados (albaranes, etiquetas de envío, estadísticas de mercancías, declaraciones del vendedor...), o bien simplemente elimina todos los documentos a más tardar una vez finalizada la obligación de archivo. Recomiendo el borrado completo porque también aporta las demás ventajas enumeradas aquí.
• Fiscal
  Tatsächlich auch praktisch niemandem bekannt: Für die GDPdU müssen Sie -auf Anforderung- alle in Ihrem Navision oder Business Central 365 bereitstehenden Daten bereit stellen/ausgeben! Auch z.B. Rechnungsdaten zu Belegen/Vorgängen in Business Central, welche deutlich älter als 7 Jahre bei Lieferscheinen oder 10 Jahren bei Rechnungen und anderen Umsätzen sind! Ausnahme: Sie haben diese Daten nicht mehr vorrätig. Schon allein aus diesem Grund sollten Sie eine gewisse Datenhygiene in Ihrer Navision-Datenbank beachten.

¿Por qué no borrar los datos sin más?

Lamentablemente, en Navision/Business Central no es posible borrar simplemente una gran cantidad de datos que ya no se necesitan. Para los pedidos completados sigue habiendo rutinas preparadas ("Borrar pedidos completados"), lo mismo para los pedidos de compra ("Borrar pedidos completados"). Las ofertas Navision y las solicitudes de compra de Business Central pueden borrarse de forma rápida y sencilla directamente a través de las tablas: Tabla 36 o 38: Ejecutar, establecer filtro, seleccionar todo y con CTRL+a, eliminar. Para las cuentas por cobrar y los artículos, las tablas de artículos asociadas (21 Accounts Receivable/Cust. Entrada en el Libro Mayor, 25 Entrada en el Libro Mayor de Proveedores, 32 Entrada en el Libro Mayor de Artículos, 5802 Entrada de Valores) desafortunadamente no han sido borradas por mucho tiempo. Esto se justifica con la continuidad de las estadísticas.

También suele pasarse por alto: Tabla 405 Elementos de registro de cambios/Entrada de registro de cambios. Aquí, incluso pequeños errores en la configuración del registro de cambios son suficientes para inundar literalmente la base de datos de Navision/Business Central con datos sin sentido. En el transcurso de mi tiempo como programador y consultor de Navision, he descubierto muchos sistemas en los que el registro de cambios ha ocupado el 80% de una enorme base de datos, ¡sin ningún otro uso!

Y los usuarios "normales" no pueden influir en ella en absoluto: 339 Elementos de ajuste de artículos/Entrada de aplicación de artículos. En las versiones de Navision anteriores a 2009, esta tabla no es necesaria en absoluto; su contenido puede eliminarse completamente sin prácticamente ninguna consecuencia.

Dependiendo de la versión de Navision/Business Central, algunas entradas deben borrarse, pero las demás deben comprimirse (condensarse) para no dañar (mantener la coherencia), por ejemplo, los saldos de cuentas de mayor o las existencias de artículos.

¿Cómo se limpia entonces una base de datos Navision?

Le ayudo a limpiar/reducir/limpiar su base de datos Navision normalmente con los siguientes procedimientos:

• Salida de Deb/Kred/SK-SuSa y listas de existencias, para verificar posteriormente que no se ha borrado demasiado.
• Cambie la lógica del programa en su Navision o Business Central, de modo que las tablas de artículos también se reduzcan/eliminen/borren realmente durante las siguientes limpiezas.
• En el proceso, las tablas dependientes como 379 Detailed Cust. Ledg. Detallado y 380 Libro de proveedores detallado también se ajustan.
• Ofertas de más de 3 años, se borran los pedidos completados. Mis rutinas van más allá que las rutinas estándar de Navision y reconocen más pedidos completados. Lo mismo ocurre en compras. Regla general: Los pedidos de más de 2 años ya no deberían entregarse, más bien causarían irritación o risa por parte del cliente...
• Los notas de entrega de compras y ventas con más de 7 años de antigüedad se borran automáticamente. Mis cambios garantizan que también se borren los no impresos. Esto significa a menudo que por fin puede utilizar CTRL+Fin para obtener de nuevo el último aviso de entrega de Navision inmediatamente y sin necesidad de buscar - por ejemplo, si ha trabajado con series de números como L99xxxx, que antes lo impedían.
• Las facturas con más de 11 años de antigüedad se eliminan (¡tiene la obligación de archivar / GDPdU los movimientos fiscalmente relevantes durante 10 años después del final del período contable! Esto da lugar a los 11 años). Con esto, por fin puede volver a encontrar la última/actual factura contabilizada de Business Central inmediatamente con CTRL+Fin - si ha trabajado con series de números como R99-xxxx, por ejemplo, que antes lo impedían.
• Las partidas de deudores, acreedores y libro mayor con más de 11 años de antigüedad se comprimen. Para ello, dependiendo de la versión de Navision, se corrige la compresión. Esto también se aplica a las partidas de artículos, si su Navision aún lo permite. Por lo demás, sin embargo, ya se ahorra mucho espacio mediante el borrado real de las posiciones de artículo y las posiciones de valor para artículos que ya no existen.
• Después de los resúmenes anteriores, también se eliminan de la base de datos los clientes/proveedores/cuentas de propiedades/artículos obsoletos (no utilizados durante mucho tiempo), incluidos sus artículos aus der Datenbank entfernt. Bei Kunden/Lieferanten/Artikeln gehe ich dabei von 5 Jahren aus. Sachkonten können natürlich erst nach den 11 Jahren gelöscht werden, wenn also keine oder nur komprimierte Posten dazu vorhanden sind. Alle Zeiträume werden noch einmal mit Ihnen abgestimmt! Hierbei wird auch stichprobenartig überprüft, ob Ihre Gebuchten Belege danach noch ausgedruckt werden können. Schlechte Programmierung verhindert das überraschend oft. In diesem Fall ist abzustimmen ob der Belegdruck angepasst wird oder der Lösch-Horizont. Gerade hier ist Ihre Mitarbeit sehr wichtig: Benutzen Sie virtuelle Artikel, Sachkonten oder Kunden? Z.B. als Dachgesellschaften, Notizsammler oder für Preisgruppen? Bei diesen Sätzen kann ich ohne ihre Hinweise nicht automatisiert feststellen, ob ich die löschen darf, weil uralt und keine Bewegungen drauf, oder ob diese wichtige Daten tragen, die nicht gelöscht werden dürfen.
• Dependiendo de la versión, aquí también se borran generalmente los elementos de ajuste del artículo (varias versiones de Navision no los necesitan en absoluto - Business Central, sin embargo, los necesita generalmente para los artículos existentes).
• Cuando se utiliza Microsoft SQL Server, también existe la comprobación del TransactionLOG. Desafortunadamente, todavía hay muchas empresas de sistemas y/o programadores aficionados que hacen "copias de seguridad" de una base de datos Navision (o más generalmente: una base de datos SQL) haciendo una copia de seguridad de todo el servidor, por ejemplo, con Microsoft Backup o Veeam. O haciendo una copia de seguridad de todo el servidor SQL virtualizado en su conjunto o -de forma muy inteligente- "incrementalmente". Esto no es una copia de seguridad autorizada o recomendada por Microsoft para una base de datos MS-SQL. No importa si es para Navision, Business Central o cualquier otra aplicación en el servidor SQL. Si además establece el modelo de restauración como completo (lo cual es bastante recomendable por muchas razones, por ejemplo, para todas las copias de seguridad de 5 minutos en entornos de alta disponibilidad), el registro de transacciones se llenará. No es de extrañar: ¡nunca se vacía de forma controlada! Mi récord personal era una base de datos Navision con 7 Gb de datos de usuario (sin ajustar) y 67 Gb de registro de transacciones. Eso quizás ya no sea negligencia, ¡sino quizás intencionado!!
• Al comprimir por primera vez, se realiza una (o más, si es necesario) tirada de prueba para que puedas revisar el resultado una vez antes de que reduzca tus datos reales. Incluida la impresión renovada y la comparación de las listas SuSa mencionadas al principio. Los programas necesarios permanecen después en su base de datos. De este modo, si lo desea, puedo volver a limpiar regularmente (anualmente) su base de datos en el futuro.

¿Y si no me funciona?

En resumen: Por regla general, esto encaja y los miedos (realmente) innecesarios suelen estar fuera de lugar. Pero, por supuesto, cada período, cada registro maestro, cada eliminación en Navision o Business Central 365 puede adaptarse individualmente a sus necesidades.

Hierbei ist es ganz besonders wichtig ihre Besonderheiten zu beachten! Haben Sie statistische oder aus anderen gründen relevante Debitoren/Kreditoren/Sachkonten/Artikel, welche keine oder nur alte Bewegungen haben, und trotzdem nicht gelöscht werden? Oder andere auffällige Abweichungen vom „Standard“, die bei nicht-löschen berücksichtigt werden müssen?

¿Cómo puedo saber cuáles son los mayores derrochadores de espacio?

En Navision nativo hasta la versión 2009R2 bastante simple: nuevo formulario (Página), Tabla 2000000028 Tabelleninformation / Tabla de Información, Vista previa (guardar no es necesario). Filtro para tamaño (KB) > 1000000 (1Gb, normalmente no tiene que tratar con tablas más pequeñas).
Bajo MS-SQL (Navision y Business Central con el SQL Server) con este pequeño script para consultar el tamaño de la tabla:

USE Name-Der-Navision-Datenbank
GO
SELECT TOP 50 
  used AS "Pages",
  rows AS "Saetze",
  (used * 8) / 1024 AS "MB",
  CAST(OBJECT_NAME(id) AS CHAR(100)) AS TableName
  FROM sysindexes WHERE indid IN(1,2,255) ORDER BY used DESC

Me gustaría mucho ver los elementos del registro de cambios muy arriba. Regla de oro: Los elementos del registro de cambios sólo deben utilizarse en los datos maestros. Por ejemplo, en datos maestros de artículos (tabla 27), datos maestros de clientes (tabla 21), condiciones de pago, condiciones de entrega, etc.
La pregunta clásica que el registro de cambios debe y puede responder es algo así como: "¿Quién ha cambiado el número de teléfono de Müller?" o "¿Quién ha cambiado el precio de venta del artículo 4711 de 6,90 a 5,80?". Navision estándar sólo almacenaría "Modificado el" y "Modificado por" en diferentes y escasas tablas de datos maestros.
Si utiliza los elementos del registro de cambios de forma incorrecta, por ejemplo, para registrar datos de transacciones, su registro de cambios reventará rápidamente, al igual que su base de datos.

El tamaño del registro de transacciones se puede consultar en MSSMS en las propiedades de la base de datos correspondiente. No hay registro de transacciones si se trabaja con la base de datos nativa de Navision hasta la versión 20090R2. Regla de oro: Los registros de transacciones con un tamaño superior a 1 Gb o un tamaño > 2 % de la base de datos del usuario son señal de chapuza. Esto no siempre es cierto, por ejemplo, el registro de transacciones puede haberse inflado una vez durante una acción de mayor envergadura y no haberse reducido posteriormente. Pero esta regla casi siempre se cumple. En este caso, la información "usado" o "utilizado" es útil. En Navision hasta 2009R2, los tamaños de base de datos para el servidor SQL también se pueden encontrar en Archivo/Base de datos/Cambiar.

Reducir el tamaño de los archivos de base de datos

Tras las acciones de eliminación, suele quedar más de un 50% de "aire" en los archivos de la base de datos.

Para la base de datos nativa (Cliente Clásico), no debe haber más de un 15-20% de espacio vacío activo. Cuanto más pequeña sea la base de datos, más rápidas y compactas serán las copias de seguridad HotCopy (esto no supone ninguna diferencia con la base de datos lógica). Por supuesto, el espacio vacío no debe ser DEMIASADO pequeño, ya que la base de datos volverá a crecer.

En el caso de la base de datos SQL, Navision o el propio servidor de la base de datos SQL pueden ampliar los archivos de la base de datos Navision o los archivos del registro de transacciones si es necesario. Por lo tanto, éstos pueden reducirse hasta el límite inferior. También en este caso, la reducción garantiza copias de seguridad de datos más rápidas y compactas. La desfragmentación de los índices (Index Defrag) forma parte de toda reducción de bases de datos. Pero en una base de datos Navision limpia, de todas formas hay procesos periódicos para reconstruir los índices (actualización de índices) y una desfragmentación de índices (desfragmentación de índices).

No active nunca la opción "Reducir tamaño automáticamente". Esta opción es absolutamente contraproducente. Esta opción fragmenta su base de datos muy fuertemente - es literalmente "hecha jirones" (destrozada), ¡los índices (claves) pueden ser desfragmentados tan fuertemente que el servidor SQL no los utiliza!

Si la base de datos está en discos duros magnéticos (recomiendo sólo SSDs desde 2008), el acceso efectivo a los datos desde Navision o Business Central también se acelera con archivos de base de datos más pequeños (reducidos), ya que los cabezales del disco duro ahora tienen que recorrer distancias más cortas. No se olvide de "Defrag" 🙂 . Mientras que aquí más bien los pecados de configuración (Raid5, varias partes de base de datos en un disco, registro de transacciones no en un disco separado...) proporcionan una ralentización de Dynamics NAV/Navision/Business Central con un rendimiento miserable. Prácticamente ningún programador de Navision (o administrador de Business Central o cualquier otro gurú de las bases de datos) entendió entonces, cuando se introdujeron los nuevos discos duros magnéticos más rápidos y grandes (alrededor del año 2000), por qué el nuevo y ultramoderno disco duro de 15.000 con 120 Gbytes era taaaan más lento que los antiguos HD's de 2 Gb con 5.400 rpm..... Con el servidor de base de datos nativo bajo Navision, 5 o 6 antiguos HDD's aún podían ser órdenes de magnitud más rápidos que menos/un HDD ultramoderno. Esto tenía que ver con la configuración de las tablas. Pero básicamente este comportamiento se aplica a cada proceso de base de datos (palabra clave I/O Durchsatz).

¿Con qué frecuencia se debe reducir el tamaño de la base de datos?

En este caso no se trata de "mucho ayuda mucho". La reducción y desfragmentación anual como parte de la higiene de datos suele ser suficiente. Excepción: se han hecho auténticas burradas en su base de datos, por ejemplo, en relación con el registro de cambios (elementos del registro de cambios) o el registro de transacciones. Entonces la reducción y la desfragmentación de índices forman parte de las tareas de reparación.

Procedimiento de limpieza de datos

Concretamente, el procedimiento es el siguiente:

1. Cambiar la lógica del programa para que cuando se borren los datos maestros, se borren también las partidas asociadas (y no sólo "vacío" en el número de cuenta).
2. Imprima una evaluación de existencias SuSa SK, Deb, Kred.
3. Llame la compresión de las partidas del libro mayor (98), de las partidas de clientes (198), de las partidas de proveedores (398) y, si aún es posible, de las partidas de artículos.
4. Lagerregulierung laufen lassen (Alternativ: Ajustar el código para ignorar los artículos no regulados).
5. Aclarar qué debe ocurrir con las líneas de la hoja de partidas no contabilizadas (-> Suprimir).
6. Ajustar (borrar horizonte) y llamar a la (nueva) función "Borrar datos antiguos".

Tiempo estimado de lectura: 15 minutos