Results 1 to 4 of 4
  1. #1
    Join Date
    Mar 2003
    Posts
    223

    Unanswered: Transaction size

    Hello, everyone:

    I am deisgning the transaction log file, and having the rough idea for transaction numbers per hour. How to determine each transaction size?

    Thanks a lot.

    ZYT

  2. #2
    Join Date
    Jul 2002
    Location
    Village, MD
    Posts
    621
    Just calculate size of row for tables involved in transactions, multiply by quantity of row affected during transaction. But you have to remember that transaction log may grow if somebody does not close transaction in time or transaction is very long (bad practice). Transaction log has to have some extra free space in this case. Also, it depends on what kind of database is, what model. Server will do very often checkpoints with small transaction log.

  3. #3
    Join Date
    Mar 2003
    Posts
    223
    Hello, Snail:

    Thanks a lot for the reply. Could you explain the details of transaction length? What kind of transaction is "very long"? Thanks.

    ZYT

  4. #4
    Join Date
    Jul 2002
    Location
    Village, MD
    Posts
    621
    Originally posted by yitongzhang
    Hello, Snail:

    Thanks a lot for the reply. Could you explain the details of transaction length? What kind of transaction is "very long"? Thanks.

    ZYT
    All transactions should be as short as possible but because of locks transaction may be open for long time.

    BOL : Guidelines for designing applications to avoid blocking include:

    Do not use or design an application that allows users to fill in edit boxes that generate a long-running query. For example, do not use or design an application that prompts the user for inputs but rather allows certain fields to be left blank or a wildcard to be entered. This may cause the application to submit a query with an excessive running time, thereby causing a blocking problem.

    Do not use or design an application that allows user input within a transaction.

    Allow for query cancellation.

    Use a query or lock time out to prevent a runaway query and avoid distributed deadlocks.

    Immediately fetch all result rows to completion.

    Keep transactions as short as possible.

    Explicitly control connection management.

    Stress test the application at the full projected concurrent user load.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •