How Does Shrinking the Log File Work?

Shrinking the transaction log reduces its physical size by removing one or more inactive virtual log files. The unit of the size reduction is always the virtual log file. For example, if you have a 600 megabyte (MB) log file that has been divided into six 100 MB virtual logs, the size of the log file can only be reduced in 100 MB increments. The file size can be reduced to sizes such as 500 MB or 400 MB, but the file cannot be reduced to sizes such as 433 MB or 525 MB. A virtual log file that holds any active log records, that is, an active virtual log file, is part of the logical log, and it cannot be removed. For more information.


For a log file, the current size is the same as the total size of the pages that are used by the virtual log files. Note, however, that pages are not used by the log files. Virtual log files that hold any part of the logical log cannot be freed. If all the virtual log files in a log file hold parts of the logical log, the file cannot be shrunk. Shrinking is not possible until after log truncation marks one or more of the virtual log files as inactive.


A shrink-file operation can remove only inactive virtual log files. If no target size is specified, a shrink-file operation removes only the inactive virtual log files beyond the last active virtual log file in the file. If a target size is specified, a given shrink-file operation removes only enough inactive virtual log files to approach but not exceed the target size. After shrinking, the log file is typically somewhat larger than the target size, and it will never be smaller. The virtual log files make it difficult to predict how much the log file will actually shrink.


When any file is shrunk, the space freed must come from the end of the file. When a transaction log file is shrunk, enough virtual log files from the end of the log file are freed to reduce the log to the size requested by the user. The target_size specified by the user is rounded to the next highest virtual log file boundary. For example, if a user specifies atarget_size of 325 MB for our sample 600 MB file that contains six 100 MB virtual log files, the last two virtual log files are removed and the new file size is 400 MB.


If part of the logical log in the virtual logs does extend beyond the target_size mark, the SQL Server Database Engine frees as much space as possible and issues an informational message. The message tells you what actions you have to perform to remove the logical log from the virtual logs at the end of the file. After you perform this action, you can then reissue the DBCC statement to free the remaining space.

For example, assume that a 600 MB log file that contains six virtual log files has a logical log that starts in virtual log 3 and ends in virtual log 4 when you run a DBCC SHRINKFILE statement with a target_size of 275 MB, which is three-quarters of the way into virtual log 3:

Virtual log files 5 and 6 are freed immediately, because they do not contain part of the logical log. However, to meet the specified target_size, virtual log file 4 should also be freed, but it cannot because it holds the end portion of the logical log. After freeing virtual log files 5 and 6, the Database Engine fills the remaining part of virtual log file 4 with dummy records. This forces the end of the log file to the end of virtual log file 1. In most systems, all transactions starting in virtual log file 4 will be committed within seconds. This means that the entire active portion of the log is moved to virtual log file 1. The log file now looks similar to this:

The DBCC SHRINKFILE statement also issues an informational message that states that it could not free all the space requested, and that you can run a BACKUP LOG statement to free the remaining space. After the active portion of the log moves to virtual log file 1, a BACKUP LOG statement truncates the entire logical log that is in virtual log file 4:

List AD Group Member

The easy way to get the member list of a group in Active Directory is using the following command in Active Directory Module for Windows PowerShell.

Get-ADGroupMember G1 | FT Name

Notes
Get-ADGroupMember: command name
G1: group name
FT Name: full name of user

DataFormatString in GridView

Data Formatting Expression	Applied to Types	Description
Price: {0:C}	numeric/decimal	“Price:” is shown, followed by the number formatted as currency.
{0:D4}	integer	Shows an integer in a zero-filled 4-char-long string format.
{0:N2}%	numeric	Accuracy is set to 2 digits after decimal point. Shown with a percentage sign.
{0:000.0}	numeric/decimal	Show 1 digit after decimal point. Zeroes are filled in if the number is less than 100.
{0:D}	date/datetime	Standard DateTime format(e.g. Saturday, November 08, 2008”).
{0:d}	date/datetime	Short DateTime string like 11/06/08.
{0:yy-MM-dd}	date/datetime	08-11-08.

Array vs. Linkedlists

Dimensions

Arrays can be one-dimensional or multidimensional, depending upon your requirements.

In contrast to arrays, linked lists are, by their very nature, one-dimensional.

Memory allocation

Most often, arrays are static, with their size defined upon creation. Additionally, the memory allocated for arrays is contiguous. Therefore, they are typically used when the maximum number of elements is known at design time.

On the other hand, linked lists are usually dynamic. They can grow and shrink as needed at runtime. Due to this trait, linked lists are more appealing when the number of elements is unknown.   The downside to being able to deal with uncertainty is that adding and deleting elements to linked lists requires more overhead than merely assigning values to pre-allocated array elements. 

Accessing elements

The elements within arrays are accessed by their indices. If you don’t know the index of the element needed, but the elements are sorted based on some key value, you can perform highly efficient search algorithms to locate specific elements. However, arrays are inefficient when the ordering of their elements is likely to change. Maintaining a sorted array upon element deletion or insertion could require the transfer of every element in the array.

Linked lists are usually traversed element by element until a match is found. Because the memory for linked lists is not guaranteed to be contiguous, this list traversal is the only method for searching the list (without involving the use of other data structures as indices). The upside of noncontiguous memory is that reordering the list simply involves manipulating the links. Insertion or deletion of an element requires only a couple of pointer modifications. The transfer of the actual data isn’t required at all.

Breaking the rules

Using language-specific constructs may allow for the best of both worlds. With C, pointers to variables or objects can be used as arrays of the corresponding type if they are pointed to the first element in an allocated array. This allows a pointer to be used as an array, but when resizing is necessary, the realloc() function allocates a new block of memory and transfers all existing elements to the new location. This technique allows for dynamic resizing of an array while maintaining contiguous memory and element indexing.

With Java, the provided linked-list class offers an indexed linked list that supports all of the standard list methods (top, next, previous, etc.) as well as indexed operation. The indexOf(), get(), and set() methods allow array-like access to the elements of the list. Additionally, Java provides an ArrayList class that represents a resizable-array implementation of the list class. Both of these classes support methods for returning true arrays from their list representations.

Programming languages continue to become more advanced, and there is less distinction between the various types of data implementations as their structures expand to include the strengths and correct the deficiencies found in the standard models. However, it will always be important to remember where these structures originated and how they are still used within the newer classes. Although these newer implementations hide the details from the programmer, the computational overhead and resources required do not change.

Move Data or Transaction File in SQL Server

Sometimes the database data or transaction file are resided in the hard drive which is running out of space. One solution is to move the files to the other drive has enough space. We can move Data or Transaction File in SQL Server by detaching and attaching the database.

For the best practice, we should make sure there is no connection to the database which file we want to move. We can use "Activity Monitor" in SQL Server Management Studio to check all the sessions are connecting to the databases on the SQL server.

If there is no connection to the database that we will manipulate, we detach and attach the database through following steps:

1. In   SQL Server Management Studio, select and right click the database, and then go to "Tasks" -> "Detach" . 
2. After the database is detached successfully, we can move the data or transaction file within file system. 
3. Next, we right click "Databases" and select "Attach ...". 
4. In the "Attach Database" window, select the files in the new path and hit "OK".