PC SOFT

FOROS PROFESIONALES
WINDEVWEBDEV y WINDEV Mobile

Inicio → WINDEV 2024 → Help deleting/archiving LARGE HFCS Databases
Help deleting/archiving LARGE HFCS Databases
Iniciado por myerssj, 09,feb. 2018 07:56 - 2 respuestas
Miembro registrado
20 mensajes
Publicado el 09,febrero 2018 - 07:56
I have a very large set of web, desktop/server, and mobile applications all built around a LARGE database primarily in HFCS. I am trying to address performance issues due to some of the tables being huge. I originally tried to use some logic to move old records to an archive table, but that was way to slow. I have now mode copies of the files (FIC and NDX) and mapped to a new name for archive.

I can't seem to find a way to delete/purge the old records from the production table that is at all practical. The largest table is 155GB FIC, not including the NDX. We've tried to use queries to delete the old records but it is painfully slow. I need to delete about 15 Million records. It took 3 hours to delete 8,000 last time we tried.

I also noticed the file size is not reduced on the delete. I assume we will have to reindex to have that happen, which would take a ridiculous amount of time as well.

Anyone have any suggestions,, best practice for how to handle this? We do not have an option to take any of the "current" data offline (about 20 Million records in this particular file).

Stephen
Miembro registrado
28 mensajes
Publicado el 09,febrero 2018 - 10:49
Hi Stephen,

I do not have experience with such bit databases, I do have with databases with million records. Maybe you already know this but in HF C/S Control center if you choose one or more tables and click "Optimize and Repair" (als used for indexing) you can choose:
- Delete the damaged records
- Delete the inactive records (deleted or crossed)

The second option wil free disk/database size.

Hope this is useful...
Miembro registrado
20 mensajes
Publicado el 09,febrero 2018 - 12:45
thanks for the response.


I've never messed with Crossed records. I wonder if cross would be faster than delete. Since it looks like I will need to reindex anyway. We are deleting on a simple query of unique keys, essentially anything less then the specified Automatic identifier index.