From: credondo on 8 Apr 2010 18:59 Hi Guys, I'm working on a .net project (C#) and my database is a DB2 iSeries Server. Basically, we have a set of Stored Procedures that are consumed from the Data Layer using .Net DB2 Provider (V5R4). DBA is reporting a unusual high CPU utilization from a job signed with my DB2 user (same user I use within the dB2 connection string), but nobody in the system is reporting performance issues neither frozen app. I worked with the DBA and we noticed that at the beginning of the day the server reports some jobs created with my app db user, but all jobs are in TimeWait status with 0% of CPU usage (which is normal and expected). Do you know how .Net Provider should behave with jobs on DB2? Could a job on DB2 server attend more than one request at the same time? Thanks.
From: Karl Hanson on 9 Apr 2010 15:49 credondo wrote: > Hi Guys, > I'm working on a .net project (C#) and my database is a DB2 iSeries > Server. Basically, we have a set of Stored Procedures that are > consumed from the Data Layer using .Net DB2 Provider (V5R4). DBA is > reporting a unusual high CPU utilization from a job signed with my DB2 > user (same user I use within the dB2 connection string), but nobody in > the system is reporting performance issues neither frozen app. I > worked with the DBA and we noticed that at the beginning of the day > the server reports some jobs created with my app db user, but all jobs > are in TimeWait status with 0% of CPU usage (which is normal and > expected). Do you know how .Net Provider should behave with jobs on > DB2? Could a job on DB2 server attend more than one request at the > same time? > > Thanks. The following is some info from a System i .NET expert (not me) that may be helpful: When you use the Access for Windows .NET Provider to connect to your IBM i, the .NET provider connects to server jobs called QZDASOINIT (or QZDASSINIT if using SSL encryption). Those jobs run under your user id. Depending on how you are using your .NET provider connections, you may have one or more of these server jobs running. By default, .NET provider connections are 'pooled', meaning that when you .Close() a connection, the server job stays active, the connection gets placed into a pool, and the next .Open request that uses the exact same ConnectionString will pick up the connection out of the pool. If you have many server jobs running, it's possible one of the following may be happening: - You never call Close() on the connection object, so each new call to Open() causes a new server job to be created. - You are using the MinimumPoolSize property in your ConnectionString. This causes a 'minimum' number of pooled connections to be created at the time the first connection is opened, and they will sit idle until a new connection Open request comes in. Without knowing more information about your scenario, it is hard to say for sure what's going on. For future questions about this .NET provider, please use the "DB2 for i" forum located here: http://www.ibm.com/developerworks/forums/forum.jspa?forumID=292 -- Karl Hanson
|
Pages: 1 Prev: Air Max 360 man shoes paypal wholesale on www golden-wholesaler com/ Next: db2look |