I'll pass along this answer on both u2-users and u2-community, but please respond on community since this is not about U2, per se. Thanks. See below. --dawn
On 4/17/07, Jerry <[EMAIL PROTECTED]> wrote:
Dawn, One thing I don't think you mentioned is the file structure. Tell me if I'm wrong. The file structure is not like U2 at all. Unlike U2, and all other PICK environments, which have separate files for each table, Cache has one file that contains all of you tables. The one big problem with this file arrangement is that if you get a broken table your whole database is broken. You can either scrap the whole thing for a backup, which means all of your tables are old or you can attempt to fix the broken table which may or may not work. The file that contains all of your tables is not dynamically resized either. You have to keep a close eye on how much room you are taking up in this file (MUMPS.DAT). Because, when you run out of room for data you have to allocate more room to increase the size of your file, otherwise you hit a wall and your apps stop working. Because of this file structure you also have a problem with maximum file size due to operating system constraints.
Below is what my sales engineer said when I asked him this question: <quote> There are a couple of assumptions about this premise. The fact that the "multiple files" is some how more reliable has the major flaw that you are reliant upon the Operating System for database integrity. This is seen by the assertion that things DO break i.e. the very construct of "broken table" as a common concept indicates this problem. We have addressed this fundamental problem by decades of constant improvement to the foot printing portion of our engine. With us "tables don't break". And for the unbelieving among us, we have backups, AND we have the ability to export any sub-set. When anything DOES break, you will ALWAYS be at the mercy of the 'last back up'. We go to great lengths to make the database integrity something that you CAN place peoples lives on (and almost 80% of all clinical data in the US DOES just that!) Can things become corrupt, certainly they can, just as the file structure at the OS level can become corrupt. Storage hardware CAN fail. Multiple files does not lessen this at all, and the pay back in both performance and reliability that comes from putting the entire foot printing under our control more than (in our opinion) out weighs the perceived 'risk'. This is really just a mind set shift that needs to happen. </quote> He then makes a comment about whether one has more faith in the OS or the DB in the MV world. In the next info, the term "global" is what we would call a file. <quote> For me, I have more faith in Cache then the OS'es we run on (and btw, both Cache & OS faith is VERY HIGH). Plus with what we call "Subscript Level Mapping" you CAN put separate globals (or subsets of global values) into different databases (CACHE.DAT files) all mapped to the same Namespace. So, in MV terms, Each Account CAN in fact have multiple OS level footprints. We don't default to doing that, since there is admin. to setup and manage the mappings, and we don't force the assumption of WHICH globals or global sub scripted value ranges make sense to have separated. So in practice, you have MORE flexibility than the MV model of a "file" HAS to be in a single file. We default to everything, but offer a finer granularity, should a data layout dictate that it makes sense to break things out, therefore this is a non issue. Our disk footprint IS allocated more space as needed dynamically, but we do NOT reduce (dynamically) the footprint. Once we have the image on disk, we only reduce that through an overt compact process (should it ever be needed). If you DO fill up, then YES we will (to keep from corrupting the footprint) halt. But monitoring how much space is being used is just common sense for a DBA. As for the maximum disk file size, YES each OS'es file structure does have an upper limit per file. But since the Namespaces can point to multiple CACHE.DAT files (I haven't seen them referred to as MUMPS.DAT files for decades)...the maximum live data set can be be HUGE!!! At 32TB per database and 16k of subscript level mappings possible, the upper limit is 576,460,752,303,423,488 bytes of live data (1/2 Exabyte) </quote>
We have an OpenM system here which is the forerunner of Cache and that is the experience I have had with it. Once we ran out of space in the file and everything stopped working. We had to call and have the allocated space increased just to get in and cleanup logs and statistics tables that were growing. I have to constantly keep an eye on the file space to make sure we don't hit the limit and remove older statistics when it looks like we are running short. I have batch processes that prune the log files for anything over two weeks old. One time we hit, what I think, was a bad spot on the disk within the allocated space. This broke one of the tables. Luckily for us the table that got broken was one that wasn't used often and when Intersystems (or it may have been Ontario Systems, our VAR) dialed in to fix the file they were able to link to a backup we had to recover the data that got damaged after they fixed the broken table. The only other alternative would have been to bring back a backup which would mean we would have lost statistics for the time period between.
<quote> There are many automated admin. functions that now will do log purging as the admin. sees fit. Again, if some admin. let's their system run without understanding the limits that they are running in, then they WILL have to pay the price...This has nothing to do with Cache vs. any other persisting technologies. The admin. functions of an MV system are clearly understood, where as the tools within Cache are simply not known, therefore they are grounds for resistance. We pride ourselves on minimal DBA time needed to admin. the system. We are continually evaluating and enhancing ways to make the administration of the system easier and more effective. </quote> ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
