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.
Thanks a lot for the reply. Could you explain the details of transaction length? What kind of transaction is "very long"? Thanks.
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.