Database stress testing is quite a challenge. You need to know something
about how your application is accessing data. If you are using host
variables and array fetching (and you should if you want to scale) then your
model will be more complex, but it will scale much better. If you are not
using those things you should look into them. Modeling a load is very
challenging.
Jim
Lamont Alan Lucas wrote in message <726l54$s7c_at_tick.ece.utexas.edu>...
>Hi.
>
>I'm a systems administrator attempting to get a basic suite of tools
>together to test our application and the database behind it as we
>upgrade our database machine and experiment with different raid
>configurations.
>
>My original (and probaby naive) plan was to run portions of our
>applications with the SQLnet client tracing turned on, parse the output
>for the SQL statements that were executed against the database, and
>write a perl app that applies them against a sample database, monitoring
>response and system load.
>
>I've tried turning on client trace files to level 16 (in sqlnet.ora on
>the client side), which spits out a hex dump of all traffic to and from
>the database, but it's rather difficult to parse, and not resulting in
>statements I can actually use (although that's due more to my lack of
>knowledge of SQL than anything else).
>
>What I'd like to know is: Am I on the right track, and is there an
>easier way to get the data that I want? I've read about turning tracing
>on on the client side, and tkprof seems to have some of the output I
>want.
>
>This is all being done against my development database, running 7.3.3.
>The client connections are all using perl DBD/DBI. If it matters, both
>systems are IRIX, 6.2 and 6.4.
>
>Any suggestions or help would be appreciated. Thank you.
>
>
Received on Mon Nov 09 1998 - 19:49:12 CST
