I agree with you in concept. In today's world of SAN and NAS and TB files one has to take this all in consideration. I will have to reconsider my way of thinking. What I am still hesitant about is the advantages and disadvantages of having all your data in one massive file spread over many spindles. As you said, if your M implementation does have an upper limit on indvidual file size, then obviously that has to be taken into consideration. But for the sake of this argument, let's assume there is no upper limit on file size. What disadvantages would there be to have the entire VistA data globals in a single file versus partitioning those globals over multiple files? Some considerations that come to mind: 1. These arguments presume a sophisticated NAS or SAN architecture that presumably can handle such considerations. 2. What hardware are you running? Are there technical considerations that would be imposed upon the M dataset configuration? 3. What OS are you running?
A single doctor's office or a small clinic operation would be a no brainer, you have a single file or at most 2 or 3 datasets depending upon your M implementation. Thanks Bhaskar, you latest arguments swept those old cob webs around. Hopefully they won't resettle in the same pattern. I will have to ponder the question "For a large institutional implementation, why should I have multiple datasets?". ----- Original Message ----- From: "K.S. Bhaskar" <[EMAIL PROTECTED]> To: <hardhats-members@lists.sourceforge.net> Sent: Wednesday, June 22, 2005 9:34 AM Subject: Re: [Hardhats-members] VistA global variable partitioning > > > smcphelan wrote: > > Having things spread across multiple partitions (or namespaces or volume > > sets or whatever) does increase the management complexity of the system. > > However routines and business logic will see a VistA database set as one > > virtual database. Thus the tight integration is not an issue. Now if you > > are talking about system management issues that is another concern. But > > those system management concerns overtly do not have any effect upon > > executing business logic unless you poorly design that database set. > > > > Bhaskar, I assume you have large bank customers. I also assume they have > > multiple database partitions because putting all data in a single database > > can lead to performance issues. Is this correct? If so, the reasoning > > behind having multiple partitions for the large banks is similar to the > > logic for having multiple partitions for a sizable VistA system. Of course > > whether to partition or not would be platform dependent. How I configure > > VistA to run on some Dell servers would be different than running VistA > > on a > > mainframe. > > Historically, there were two major reasons to partition databases into > multiple regions: performance (to distribute the IO) and maximum > database file size limits (through some version in the last century, > GT.M had a 16GB maximum database file size limit). > > In these days of RAID, logical volume managers and SANs, there is never > a need to partition a database to avoid IO hotspots. With GT.M V5's > maximum database file size limit of a little under 8TB, there is no need > to partition a database because of database file size limits. [Also, > starting with the database format changes in V5.0-000, it will be easy > for us to increase file size limits in future versions, in case people > start bumping into the current limits.*] > > So, today, the only reasons to partition a database today are for > operational reasons (as discussed in previous posts, to segregate > temporary globals, for access restrictions, size of backup files, etc.). > Whereas large banks that implemented Profile in the early to mid 1990s > partitioned their databases into twenty or more regions, even the > largest banks today will partition their databases into 6-9 regions > where each region has some operational or management reason for being a > reason. > > -- Bhaskar > > * Although it's hard for me to conceive of bumping into GT.M's limits, I > remember Bill Gates, when IBM introduced the PC circa 1981, saying, > "640K ought to be enough for just about everyone". > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
