Search results

I just cruised down the auto-bahn this week. Did a dump and load with a couple 700gb databases, the load was on a new SSD storage solution. Loaded the data, completed the index rebuild and ran the tabanalys in 16 hours or so. The iostat utility was consistently showing 80,000 w/s - I never...

If I recall - 32 bit limits 64gb for 256 rpb 128gb for 128 rpb 256gb for 64 rpb

My suggestion would be if you get to test either in house or at the vendor's site, make sure both VM's and bare metal are tested. In our environment we saw a significant difference between VM's and bare metal when we did the io tests.

Does the windows server get backed up to tape on Tuesday nights ? I've seen errors like that from backing up live db extents to tape.

If the time to start up a new agent isn't a problem, occasionally terminating idle state-less agents should help keep memory leaks to a minimum until the problem code can be identified. With the correct logging, you should be able to identify what code is running in each app server agent by...

If a file in the progress install disappears or becomes corrupt, I would probably focus on the VMWare or another application. Sounds like a problem outside of Progress.

a side note - if you must be on 10.1B - try to get to at least 10.1B03 - SP 03 had some big performance improvements.

you can see the memory usage for the app server processes using windows perfmon, is it slowly increasing ? What is the Operating Mode for the agents - State-Reset or State-less ?

We have been better off dumping the database and creating a new db from scratch as UTF-8 and then loading the data. besides the 36+ hours for the utility to run you still need the index rebuilds.

Maybe change the _file permissions for each of the user tables to only allow reads.

We have performed a dump and load for several databases (all below 150gb) that were already on type II storage because we changed OS platforms and we didn't see much of a change. Nothing like when we migrated from Type I to Type II. In a couple weeks we'll be going through the same process...

the db is 500mb so the backup will be pretty quick. a good test for a backup is to restore the backup to a new database and ensure it works.

I had week_day, week_end and a few other schedules and the point was to stop monitoring around times when we knew things would be down. There are many items to trend for DB stats, there are only a few for the app server so growth of the trend db shouldn't be as big of an issue. We collect...

If the app server agents are restarted at the same time every day, you could look at changing the times when the system is monitored. Inside the Default_Schedule_Plan is the Default_Schedule - 24 x 7 is the default. You have the option to trend certain app server stats, I don't trend app...

what performance data have you collected on the OS and database ? Do you have glance on the server ? What stats does it show ? Do you know how to use promon to collect stats on the database ?

Oh... I read the following "overall buffer pool is now 20m less with -B2 set to zero." and thought 20mb instead of 20 million blocks.

I know you don't want to upgrade service packs - but improvements in SP06 for handling traffic from remote clients and the lruskips parameter would help. Checkpoint duration is 30 seconds with -B2 in use and -B2 is only using 20mb. When -B2 is removed, the checkpoint duration is 10 seconds...

You don't mention using a BI Writer - but you did list an APW. You have to use a BIW. Can you show the promon R&D -> 3 -> 4 screen with the details of the last few checkpoints ? Can you provide what your BI Clustersize and BI Blocksize are ? What stats does windows perfmon show for the disk...

Something that just bit me with the index rebuild with the new datascanthreads option (new in the version Rob mentions above). I choose to rebuild all indexes in an area - around 1,000 indexes, but 1 of them was a word index, so my datascan was limited to a single thread...

If you are going to use SQL to access the database, I would recommend trying to stay current on the Service Packs, they contain many bug fixes related to SQL. In one of our systems, just going from 10.2B05 to 10.2B07 made a difference.