Formula to estimate content database storage

AS SALAMO ALAIKUM WA RAHMATULLAH

The following process describes how to approximately estimate the storage required for content databases, without considering log files:
Use the following formula to estimate the size of your content databases:
Database size = ((D × V) × S) + (10 KB × (L + (V × D)))
NoteNote:
The value, 10 KB, in the formula is a constant that approximately estimates the amount of metadata required by SharePoint Server 2013. If your system requires significant use of metadata, you may want to increase this constant.
Calculate the expected number of documents. This value is known as D in the formula.
How you calculate the number of documents will be determined by the features that you are using. For example, for My Sites or collaboration sites, we recommend that you calculate the expected number of documents per user and multiply by the number of users. For records management or content publishing sites, you may calculate the number of documents that are managed and generated by a process.
If you are migrating from a current system, it may be easier to extrapolate your current growth rate and usage. If you are creating a new system, review your existing file shares or other repositories and estimate based on that usage rate.
Estimate the average size of the documents that you'll be storing. This value is known as S in the formula. It may be worthwhile to estimate averages for different types or groups of sites. The average file size for My Sites, media repositories, and different department portals can vary significantly.
Estimate the number of list items in the environment. This value is known as L in the formula.
List items are more difficult to estimate than documents. We generally use an estimate of three times the number of documents (D), but this will vary based on how you expect to use your sites.
Determine the approximate number of versions. Estimate the average number of versions any document in a library will have. This value will usually be much lower than the maximum allowed number of versions. This value is known as V in the formula.
The value of V must be above zero.
As an example, use this formula and the characteristics in the following table to estimate the required storage space for data files in a content database for a collaboration environment. The result is that you need approximately 105 GB.

Input Value
Number of documents (D)
200,000
Calculated by assuming 10,000 users times 20 documents
Average size of documents (S)
250 KB
List items (L)
600,000
Number of non-current versions (V)
2
Assuming that the maximum versions allowed is 10
Database size = (((200,000 x 2)) × 250) + ((10 KB × (600,000 + (200,000 x 2))) = 110,000,000 KB or 105 GB
NoteNote:

Efficient File I/O in SharePoint Server 2013 is a storage method in which a file is split into pieces that are stored and updated separately. These pieces are streamed together when a user requests the file. This increases the I/O performance but it normally does not increase the file size. However, small files can see a small increase in the disk storage that is required.

--
MA ASALAAM
Passion 4 Oracle

SET TRANSACTION ISOLATION LEVEL

AS SALAMO ALAIKUM WA RAHMATULLAH

This statement is used to set the isolation level for either a connection or a stored procedure. The most typical use I’ve seen is at the top of a stored procedure in order to avoid locking and deadlocks. This is a cleaner alternative to using WITH (NOLOCK) hints on tables. If you set the isolation level within a procedure, the isolation level will revert to its previous level once the procedure finishes.

The syntax is:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
The available options are:

READ UNCOMMITTED – Allows dirty reads, meaning data can be read from a transaction that is not yet complete.
READ COMMITTED – Only reads data from transactions that have already been committed.  Current transactions must wait for transactions referencing common resources to finish.
REPEATABLE READ – Data that is being read is exclusively locked until the transaction completes.
SNAPSHOT – The default for Oracle.  This level allows all data to be read without using locks by maintaining a snapshot of all the data being modified in “versioning” tables.  This is the only isolation level not lock based.
SERIALIZABLE – Data that is being read is exclusive locked and inserts are prevented within this range until the transaction completes.


Snapshot isolation is not available unless enabled at the database level. It’s recommended to know all implications prior to enabling.

---
Ma Asalaam
Passion 4 Oracle