On 4/17/07, Jerry <[EMAIL PROTECTED]> wrote:
Dawn, I will elaborate a little more. Unless they have changed their file structures from the OpenM system this is what you will have. When you log into their environment you will have all of the tables and program files and they may look the same as working within the MV environment. But from the operating system side looking at the file system you have one file that is humongous with a few log files outside of it.
Yes, I think that is the case as the default, and you can make changes to have a many to many relationship between OS files and Pick files.
This one file, in our case it's MUMPS.DAT, is where all of those tables are and where you have logged into.
I think that what is different is that InterSystems has made significant enhancements to their product, to reliability and scalability as well as features like AJAX, in the past decade or so, with many of these enhancements now available to Pick folks too. I have not seen another MV implementation put the time, money, and creativity into their products, giving them the same level of uptime, scalability and features that Cache' has. I don't need to be their sales arm here, and I am working with my before-I-do-real-things-with-it information, so you might want to ask me again in a half year or so. I did ask around regarding supporting the sys admin and their customers don't seem to think about broken files at all. Their 24/7 support desk sounds like it is top notch from the standpoint of customers.
It makes it convenient to back up, just back up the one file. However, the problem comes if you have a broken table (UV file). Let's say in UV you have a customer file, a client file, a vendor file, a parts file, and a wip file. If your customer file becomes corrupted in U2 a quick fix would be to rename the file from the operating system side to CUSTOMER.BAD and load the customer file from your last backup then enter any new customers since the backup. You're back in business.
I gather that you would instead restore a namespace and then potentially apply the transactions that were entered since that time. This would keep the referential integrity too. They explained how their backups work to backup the database while it is running. It is really very impressive. I don't think I was the only one who made an audible "wow" type of sound after hearing the specifics from the tech folks. If you are interested, I'm sure they would be more than happy to chat with you about it. If you want to write up a specific question, I can pass it along. I am not so smitten that I think that everything will be honkey dory, however (am I sounding like an old lady or what?!), as I'm certain there will be plenty of "why did they do it like that" moments as we get into the details. But I'm very impressed so far. Cheers! --dawn
With Cache if the customer table becomes corrupted you can't just change the name of the table from the operating system side because it is in this black box. There may be ways from inside that box to load that one table but I am not at that level of guru on Cache. If one of the program files was damaged or if I didn't have the knowledge to reload the individual tables I would have to wait and rely on Intersystems to fix the problem. In any case there is a possibility I would have to rename the black box and reload the whole thing from backup. Then I would have to re-enter all of the Clients, customers, vendors, parts, and wip's since the last backup. Then close out any work-in-progress (wips) that had been completed. Only then could I let the users back on the system. Jerry ----- Original Message ----- From: "Dawn Wolthuis" <[EMAIL PROTECTED]> To: <u2-users@listserver.u2ug.org> Sent: Tuesday, April 17, 2007 11:15 AM Subject: Spam:Re: Spam:Re: [U2] RE: [U2C] U2 / Cache > Hi Jerry -- I started responding and decided I wasn't certain about > some points so I passed your question along. I will get back to you on > this when I get a response. What I do know is that the file structures > look the same to any application software, but different to the OS. > > I can also pass along that I talked to several people and it > definitely seems to be true that there are even fewer hours spent in > sys admin each month with the approach they have, as there is no file > resizing and the like to be done. I asked many questions of both the > vendor and their customers and did not hear about the apps hitting a > wall, so I'll see if I can find out about that. Thanks. --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. >> 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. >> Jerry > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
-- Dawn M. Wolthuis Tincat Group, Inc. tincat-group.com Take and give some delight today ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/