The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (IBMsysProg) writes: > Memory. > Over the years the first exploiters of architecture changes to allow more > address spaces, more real memory, and more virtual memory have always been > DBMS systems. At this time I would suggest allocating at least 2 gig of > additional real memory to your future DBMS. DBMS system address spaces in > general are intolerant of paging. This is because a page in results in a > wait for the entire address space and to make things worse DBMS address > spaces serve many concurrent users. i've related before the discussion between IMS group and (original SQL/System/r group about pros & cons. http://www.garlic.com/~lynn/subtopic.html#systemr IMS has/had direct pointers ... which significantly cut down processing overhead ... but significantly increased development, maintenance, and administrative costs. System/r abstracted away the direct pointers ... at the cost of implicit overhead of automatically maintained index. The "argument" back then was that the (RDBMS) automatically maintained index, doubled the physical disk space and significantly increased the number of disk i/os (as part of processing the index) ... offset by significantly reduced human resources & skills. going into the 80s ... disk price/bit came down significantly (muting the disk price/bit argument) and (relative) significant increases in system "real" memory allowed much of the indexes to be cashed (eliminated lots of the increased index disk i/os). The index overhead then somewhat shifted from the amount of disk i/os ... to just CPU overhead. In any case, the price and availability of system resources changes that went on in the 80s ... changed the trade-off between the human skill/resources and system price-resources ... significantly enabling the wider use of RDBMS. Virtual memory and high-end DBMS don't mesh very well. High-end DBMS tends to have lots of their own managed cache ... typically with some sort of LRU type algorithm. I first noticed that running an LRU storage managed algorithm under an LRU storage managed algorithm could be a bad idea ... in the mid-70s with SVS/MVS running in virtual machine (virtual memory). It was possible to get in extremely pathelogical situation where MVS would select one of the pages (at a location it believed to be "its" real-memory) to be replaced ... at about the same time that the virtual machine hypervisor also decided that the corresponding virtual page should be replaced (since they were both looking at effectively the same useage patterns as basis for replacement decision). As a result, a LRU-based strategy ... running in a virtual memory, can start to look like an MRU strategy (the next most likely page to be used ... is the one that has been least recently used). lots of past posts about page replacement algorithms ... including some difference of opinion of some of the "internally" implemented MVS strategies http://www.garlic.com/~lynn/subtopic.html#wsclock as well as some "old" email on various aspects of the subject http://www.garlic.com/~lynn/lhwemail.html#globallru In any case, when running high-end DBMS that have their own cache implementation ... in a virtual memory operating system environment ... there tends to be a lot of "tuning" options ... to minimize the conflict between the DBMS cache replacement strategy (typically some sort of LRU-based) and the operating sysetm virtual memory replacement strategy (typically also some sort of LRU-based). There is also the possibility of things analogous to the old "VS1-handshaking", where VM370 would present a psuedo page fault interrupt to VS1 (running in a virtual machine) ... enabling VS1 to do a task switch (instead of blocking the whole VS1 whenever any page fault occured for a virtual machine page). note that one of the progression of large real storage has resulted in DBMS "memory" implementations ... rather than assuming that the DBMS natively resides on disk and there is a lot of processor overhead related to the assumed DBMS operation. The assumption is that nearly everything is memory resident and managed with memory pointers ... with periodic snap-shots to disk for commits/integrity. Given the same amount of large real storage ... there are claims that the switch to a RDBMS memory-based paradigm can run ten times faster than a RDBMS disk-based paradigm that was fully cached and otherwise doing little disk i/o (and both running nearly identical SQL-based applications). misc. recent posts mentioning old "interactions" between IMS and System/r organizations regarding various pros and cons http://www.garlic.com/~lynn/2007e.html#1 Designing database tables for performance? http://www.garlic.com/~lynn/2007e.html#14 Cycles per ASM instruction http://www.garlic.com/~lynn/2007e.html#31 Quote from comp.object http://www.garlic.com/~lynn/2007e.html#37 Quote from comp.object http://www.garlic.com/~lynn/2007f.html#66 IBM System z9 http://www.garlic.com/~lynn/2007g.html#25 Bidirectional Binary Self-Joins http://www.garlic.com/~lynn/2007g.html#26 Bidirectional Binary Self-Joins and recent related DBMS posts with some topic drift http://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style" http://www.garlic.com/~lynn/2007.html#13 "The Elements of Programming Style" http://www.garlic.com/~lynn/2007d.html#4 Jim Gray Is Missing http://www.garlic.com/~lynn/2007d.html#6 Jim Gray Is Missing http://www.garlic.com/~lynn/2007d.html#8 Jim Gray Is Missing http://www.garlic.com/~lynn/2007d.html#17 Jim Gray Is Missing http://www.garlic.com/~lynn/2007d.html#33 Jim Gray Is Missing http://www.garlic.com/~lynn/2007g.html#28 Jim Gray Is Missing http://www.garlic.com/~lynn/2007i.html#68 A tribute to Jim Gray ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
