How to Analyze the already developed database? (i.e. Transaction Handling, profiling)

  • Hi All,

    Thanks in advance.

    I am working on web-based application project which have already developed databases. Now my client's expectation is as below. He wants me to improve the below areas.

    Right now the DB Server is MSSQL 2000 but in the future they will prefer the MSSQL 2005.

    Expectations :

    Transaction Profiling & Transaction Handling

    Data retrieval

    Index Management

    Verify the table structure and suggest if the new structure for the better data retrieval

    Scalability

    Load the system can handle.

    Maximum load the system can handle for the concurrency.

    Please suggest me what is the best option to analyze the database with respect to above expectations.

    You can also mail me on the below email address.

    jshah333@gmail.com

    Thank & Regards,

    JShah.

  • That's a pretty massive request. Do you have any experience in doing any of that?

    If not, I would recommend you look at getting someone in who does know how to do that. It'll probably work out cheaper in the long run.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass
  • Though I knew the below things in SQL Server

    Index De-fragment

    Clustering/Log-shipping/Replication

    Dead-Lock handling,

    Performance Tuning of database by DBCC commands

    TSQL Statements Tuning

    Transaction Handling

    Lock handling

    The above things I have done very well. But I need the idea from the experts how they are doing this stuffs.

  • You can also mail me on the below email address.

    jshah333@gmail.com

    A bit selfish, there... no one but you would learn, then. 😉

    My first reaction is "stupid people" really did it to you... they're always in a hurry to build stuff and don't give much thought to what will happen to scalability and performance in the future. They don't understand how much time and money will be spent fixing things afterward.

    Other than the normal DBA stuff of setting up proper maintenance of indexes, backups, etc, etc, you might want to setup Profiler to see what the hardest hit procs and embedded queries are. By studying the procs, you can also figure out what the hardest hit tables are and, perhaps, identify additional indexing opportunities. You might also identify RBAR rewrite opportunities and the opportunity to remove some of the embedded SQL in favor of properly parameterized stored procedures.

    If you also maintain a "space used" log, you can also plan on how much growth the database will need each week or month and make the growth "en masse" during scheduled "quiet times" instead of having the app hit the wall and growth occuring "by accident".

    Like Gail said, your request is a huge one... but there's a couple of things to think about...

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Thank you very much.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply