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/
