On Mon, 4 Dec 2006, Gerhard Hofmann wrote: > > Gerhard Hofmann wrote: > > Hi all, > > > > it seems that Ingres 2006 is very slow when reloading a database. > > > > Example: a database is unloaded, unload takes about 5 minutes and > > consumes about 1.6 GigaBytes of disk space -> quite good unload > > performance. The same database will take over an hour (!) to reload on > > the same PC. > > > > Is this a known issue? Any workaround for this? > > > > I have seen this problem on three PCs now (two were Win XP Pro, one was > > Win 2003 Server). I definitely haven't experienced this with 2.5 / 2.6 / > > 3.0.3. > > > > Hi, > > I'd like to "restart" this old thread. Some of you supposed that the > different reload times between 3.0.3 were caused by different hardware, > different disk layout, weird CBF settings and so on. > > Now I did some further tests, all of them on the *same* machine. > > Test 1: installed Ingres 3.0.3 on Win-XP-Pro, enabled 4K DMF cache > (because all original tables were page_size=4096), left all other CBF > defaults untouched: database was reloaded in about 10 minutes. > Then upgraded this installation to Ingres 2006, destroyed + created + > reloaded database again: it took about 70 minutes!!! > > Test 2: wiped out the same machine and installed to parallel instances > of Win-XP-Pro with boot mananger. Installed Ingres 3.0.3 into one > Windows instance and Ingres 2006 into the other one. For both Ingres > installations I enabled 4K DMF cache. > Reload times the same as in test 1: 10 minutes vs. 70 minutes > > Test 3: disabled 4K DMF cache in Ingres 2006 installations (to have > *every* CBF setting like the default). > Tweaked the copy.in script to use page_size=2048 for every table: it > took about 70 minutes again to build the database. Same behaviour for > page_size=8192. > > As my setup is out-of-the-box now, I really think this is a bug (or at > least bad design) in 2006. > > Any ideas? > > Regards > Gerhard
Yes, Gerhard, I should start off by saying I don't know just what technical problem exists in your situation, but I think there are some things to consider here. To wit: Back in May of 1989, I joined Relational Technology Inc.'s (Ingres Corp v1.0's) "Corporate Support" team. We were the Fly And Fix consultants, called out to rescue customers that were in trouble that represented the most significant revenue to the company. I realized that we were always called out to rescue _new_ customers. I also realized that we weren't doing well financially and that this was an overhead function. So, I developed a new program; I gathered together all of the documentation, training materials, and all internal notes I could find and heaped them into piles sorted by subject. I then culled through the materials, removing duplicate information, keeping the best-written versions, and identifying conflicting information. I then resolved the conflicts by experiment or consulting with engineering or both. The resulting material provided the corpus for three very important bodies of work, the first of which was my initial goal; to create a service for new customers wherein we'd install the product for them, sized/configured to their projected needs, and then gave them from two to five days of onsite training. This turned our overhead function into a revenue generating business, but more importantly it instantly stopped problems like what you're talking about. This also revealed a basic challenge in the goals of the installation process; It had to be able to work "out of the box" for both sites with the most meager resources as well as for ones with the most resources. Engineering wasn't really ready to address the issue, but when I had my chance, I tried to do something about it: As I was specifically hired as the company's VMS Internals expert, the chance came to rewrite the installation program for VAX/VMS, and I took it. I tried to evaluate what resources existed on the system and then ask the administrator questions to help figure out how to size things without having to expect the'd know what they were doing regarding Ingres settings. My code was unfortunately shelved at first. Howard Shao (sp?) was nervious taking code from someone who wasn't in engineering. However, the code was the first attempt at automating the configuration of derrived settings... I understand that some Engineering person later took my code, went through it and blessed it, so it should be the foundation of the VMSINSTALL stuff that's in the current product. (If there are any VMS users out there, I'd love to have a copy of the current VMS installation script - I didn't see it in the source download.) My point here is that "out of the box," I don't think Ingres the company ever really tried to size things appropriately and Ingres the product suffers for it with people like you getting frustrated. ...It's a sophisticated product and there's a lot to learn. Picking it all up right away can be frustrating. And the cost of training might seem daunting for a supposedly free database product. But I can assure you that properly configured, Ingres is almost certainly the best scaling, best performing relational database system in existence today - if anything does beat it, it won't be by much and it would be for a rare boundary condition case. Finally, if you have over a gig of main memory, consider giving the DMF cache at least a quarter, or perhaps a third of it. The transaction logfile is "circular", so size it fairly large also. These are general recommendations and not particularly targeted at your specific problem... Regards, Richard -- Richard Troy, Chief Scientist Science Tools Corporation 510-924-1363 or 202-747-1263 [EMAIL PROTECTED], http://ScienceTools.com/ _______________________________________________ Users mailing list Users@lists.ingres.com http://lists.ingres.com/mailman/listinfo/users
