Very strange IDS 9.20 happenings

IDS 9.20 FC2 on HP-UX 11.0. I've got 3 instances running on the same UNIX server, all identically configured. Two are fine, one is exhibitng, sporadically, very slow responses. For example, an oncheck -pe will whizz through on the two, but the other will plod very slowly. Even a dbaccess->query languauge->info can take 10 seconds to build the table list, abd another 15 to show the colums of the selected table. kaio is on for each instance. The schema and usage is similar for each instance/database. Each instance represents one of our depots (the reason there not combined into a single instance is that the 4GL warehousing application demands that the database be called "system" - hence we need three instances). Tech Support have suggested that I stop and re-start the instances, but in a different order (the one suffering is the last to be started), but admit that this is just a hunch and not based upon any knowledge-based notes. As I say, the instances have similar usage profiles, contain the identically-schema'd database, are identically configured. there are no abnormal service times on any disk or any other demonstrable fault. Any ideas please? Neil

Found it! Application waking up every minutes to do multiple: select 1 from table where .... sequential scan on 112k row table. Why select a constant from a table? Those wacky guys from Dallas! Neil Truby <ntruby@netcomuk.co.uk> wrote in message news:8mpn6n$ref$1@lyonesse.netcom.net.uk... > IDS 9.20 FC2 on HP-UX 11.0. > > I've got 3 instances running on the same UNIX server, all identically > configured. Two are fine, one is exhibitng, sporadically, very slow > responses. For example, an oncheck -pe will whizz through on the two, but > the other will plod very slowly. Even a dbaccess->query languauge->info can > take 10 seconds to build the table list, abd another 15 to show the colums > of the selected table. > > kaio is on for each instance. > > The schema and usage is similar for each instance/database. Each instance > represents one of our depots (the reason there not combined into a single > instance is that the 4GL warehousing application demands that the database > be called "system" - hence we need three instances). > > Tech Support have suggested that I stop and re-start the instances, but in a > different order (the one suffering is the last to be started), but admit > that this is just a hunch and not based upon any knowledge-based notes. > > As I say, the instances have similar usage profiles, contain the > identically-schema'd database, are identically configured. there are no > abnormal service times on any disk or any other demonstrable fault. > > Any ideas please? > > Neil > >