Periodically, all computer systems, even an INFONETICS system, need to be purged of old data. This is needed to conserve space, improve speed/access time, and generally to clean out old unneeded information that tends to clutter up a database over time. This article describes a new technique we’ve developed for archiving data in historic databases, and even moving those databases onto secondary historic machines.
Over the years, we’ve recommended printing off reams of paper reports on this obsolete information, then purging it completely out of the system. If fact, we’ve even built a special long-term holding facility for old Orders/Invoices, (the familiar Archive System), to postpone the need to purge these most valuable of information assets from your system.
However, hardware advances over the last few years have dramatically lessened the need to purge information. Whereas disk drives had been in the 70 – 200 megabyte range (and quite expensive at that), our newest systems use 1200 – 1600 megabyte drives. That’s ten times the amount of space a typical database uses. And, processor speed has quadrupled (and yet again with the PentiumPRO), leaving ample extra horsepower to manage data.
All this extra space and horsepower add up to a system that can manage much more data, and manage it more efficiently at that. Unfortunately, we humans still need to weed out that old data periodically so that we can understand, organize, and manage it better in our minds.
Wouldn’t it be nice if you purge your data, and keep it around both at the same time (kind of like having your cake and eating it too). We’ll with our new “Historical Database” technique, you can! Each year, we can make a complete copy of your database, give it a new name (and login to access it with), and freeze access to it for all eternity. Then, you can purge your active database to your hearts content. You’ll still be able to access the historical database through its separate login, and it will appear exactly as it was on the day we set it aside, even years after the fact.
Let’s take a real world example. Mid-January 1997, you ask us to configure an historical database. On a quietsystem one afternoon, we’ll make a copy of the database and give it a new login name of “1996”. To do this, you’re system will of course need enough spare room to hold a second copy of data. Your normal logins will continue to access your active books, which can then be safely purged down to the bare minimum needed. Anytime you need to access the historical books, simply login as “1996”!
One of the disadvantages of historic databases is that, when it is in use, it actually degrades the overall performance of the system. This is because the system is being asked to manage not only your active database, but also a second, often larger, historical database. So only login to your historical databases just long enough to locate the information needed, then logoff!
Of course, for those power addicts out there we have just the solution to that problem. A dedicated historic MACHINE! Yes, we can now dedicate one unix server (say a brand new PentiumPRO) to your active database. Then, we’ll dedicate a second unix server (say your former main Pentium system) to your historic databases. And, through the power of ethernet networking, we’ll configure it so that all terminals and workstations throughout your site can login into either system! That way, any users accessing the active database will be serviced by the big system, while users accessing the historic databases will be serviced by its little brother machine. Two heads are definitely better than one in this case.
To setup either of these configurations, just give us a call. We’ll be glad to schedule an hour or so of time for you to setup your historic database. And, we now have PentiumPRO systems in stock and ready to ship if you’d like an historic machine to go with it.