Be aware that A SharePoint Farm Administrator can set policies on each user property in a user profile to help govern how the information in that property can be used, and one relevant policy property is Replicable.  By default when Replicable policy is True, the user profile property's value can be replicated to user information lists in other site collections when its value changes. For a property to be replicated, its default privacy setting must be set to Everyone and the User can override policy must not be selected.
 
However, things can go awry and sometimes certain users’ profile metadata in a User Information List for unknown/mysterious reasons just ceases to get replicated updates from a profile sync run.
 
Where can things go wrong?  SharePoint maintains a mapping between the Profile DB and content DB userinfo table, based on “[Profile DB].[dbo].[UserProfile_Full].SID“ column and “[WSS_Content].[dbo].[UserInfo].tp_systemID” column.  This mapping is leveraged when SharePoint synchronizes the Profile Database and the Content Databases.  Linkages can apparently get broken here sometimes and impact user metadata replication.  But I won’t delve into this less common topic, and instead will cover the most typical scenario.
 
How do I fix user metadata in the hidden User Information List when things go awry? 
 
Set-SPUser -SyncFromAD to fix Name (DisplayName) and E-Mail:
 
If you want to manually force update existing user metadata in a User Information List, You can use "Set-SPUser" cmdlet at the site collection scope with the SyncFromAD parameter.  The SyncFromAD parameter specifies that user information will be synchronized (immediately, in my observation) from the user directory store. Be aware that this cmdlet only updates the Name/DisplayName and E-Mail fields.  It doesn’t touch the Title or Department or other fields. Example PowerShell for a SharePoint 2013 claims-enabled web site…
 
$login= "i:0#.w|dev\TestUser1"
$site= "https://intranet.contoso.com/sites/abcsite"
Set-SPUser -Identity $login -web $site -SyncFromAD
 
Remove-SPUser and manually re-add to fix Title, Department, and other metadata:
 
If there are only few user accounts having inconsistent metadata in the site collection, the easiest fix might be to run the Remove-SPUser cmdlet to remove each user from the site collection (which removes them from User Information List). Then via the SharePoint UI, manually grant the user access again within the site collection (or use New-SPUser cmdlet) to force SharePoint to re-add the user into the User Information List.  From my observation, it appears that SharePoint will refresh the user metadata properties from the user profile after the next profile synchronization runs (you may have to wait for an hour for the sync job to run successfully).  Example PowerShell for a SharePoint 2013 claims-enabled web site...
 
$login= "i:0#.w|dev\TestUser1"
$site= "https://intranet.contoso.com/sites/abcsite"  
Remove-SPUser -Identity $login -web $site
 
Important:   If you plan to remove the user from the site collection, all the user's permissions to this Site Collection are removed. Before you remove the user's permissions and re-add them, make sure you note the user's permissions.  To do this from the SharePoint site collection, you can go to Site Actions> Site Settings > Users and Permissions > Site Permissions > Check Permissions.
 
Manually delete user from All People group and re-add to fix Title, Department, and other metadata:
 
Alternatively, you could delete a user from a site collection by deleting them from the All People group using the SharePoint UI.  If you remove the user from this group, this also removes the user from the userInfo table in the Microsoft SQL Server database. I believe this is some type of soft delete, where a Deleted property is turned on.  When you re-add the user, the user's information is updated in this table.  From my testing it appears that SharePoint will refresh the deleted/re-added user’s metadata properties in the site collection from the user profile after the next profile synchronization runs.
 
Important:   If you plan to delete the user from the All People group, all the user's permissions to this Site Collection are removed. Before you remove the user's permissions and re-add them, make sure you note the user's permissions.  To do this from the SharePoint site collection, you can go to Site Actions> Site Settings > Users and Permissions > Site Permissions > Check Permissions.
 
How do I access the All People group/page in a SharePoint 2013/2010 site collection? 
 
In Microsoft Office SharePoint 2007, you could remove the user from the All People group and re-add them. This option is no longer available in SharePoint 2010/2013. SharePoint 2010/2013 removed the page from navigation, but you can still access the All People page by appending the following to the root URL of the site collection.
 
SharePoint 2013
/_layouts/15/people.aspx?MembershipGroupId=0
 
SharePoint 2010
/_layouts/people.aspx?MembershipGroupId=0&FilterField1=ContentType&FilterValue1=Person
 
 
What is the People Picker control in SharePoint? 
 
The People Picker control is used to search/find and select groups (as well as people and claims).  Where does the picker control pull its display data from?  SharePoint first checks if the user exists in the site collection (hidden User Information List), if it does not then it retrieves the user info from Active Directory and adds the user into the site collection.  People picker behavior is affected by the User Profile to SharePoint synchronization Job; however, it can be influenced by many other factors. 
 
How does the Person or Group column type work?
 
The Person or Group column type in a list/library allows you to select people based on User ID and Login Name using a picker control.  The People Picker control is used to search/find and select groups (as well as people and claims).  Where does the picker control pull its display data from?  The UserID relates to the ID of the user within the site collection. However chances are that not all users are currently members of the site collection. To address this, SharePoint first checks if the user exists in the site collection, if it does not then it retrieves the user info from Active Directory and adds the user into the site collection.  People picker behavior is affected by the User Profile to SharePoint synchronization Job; however, it can be influenced by many other factors.  The Show Field value for a Person or Group column type is obtained from the hidden User Information List in the site collection.

About Active Directory (AD) Groups

Groups are used to collect user accounts, computer accounts, and other groups into manageable units. Working with groups instead of with individual users helps simplify network maintenance and administration.

There are two types of groups in Active Directory:

• Distribution groups: Used to create email distribution lists (DLs).  Distribution groups are not security enabled, which means that they cannot be listed in discretionary access control lists (DACLs).  Distribution groups cannot be used to secure access to SharePoint.
• Security groups: Used to assign permissions to shared resources.   A security group can also be used as an e-mail entity.

From…Overview of security groups in SharePoint 2013

What is Meant by "Rename" an Active Directory Group?

AD groups have many "name" attributes.  A Distinguished Name (DN) is used to uniquely name an Active Directory Object. All objects can be referenced using a Distinguished Name. A DN has following components:

• DC - Domain Component
• O - Organization
• OU - Organizational Unit
• CN - Common Name

Changing the CN (common name) of a group in AD effectively renames it. That same name change also appears to be reflected in both the “name” and “samAccountName” properties of the AD group.  The membership property (i.e., user account members) of the group is unaffected by rename.  By renaming an AD group you are actually giving it a new ADsPath, and effectively changing the Distinguished Name (DN).

In addition to Common Name (CN), an AD group object will also have additional “name” properties which typically reflect the same value as CN after a rename:

• name   (a.k.a., Display Name)
• samAccountName    (a.k.a., login name)

How Are AD Security Groups Used Within SharePoint 2010?

• People Picker:  The People Picker control is used to search/find and select groups (as well as people and claims) when a site, list, or library owner assigns permissions in SharePoint
• Authorization/Permissions:  You can use security groups to control permissions for your site by adding AD security groups to SharePoint groups and granting permissions to the SharePoint groups.  An AD security group can be listed in the DACLs for securable objects within a SharePoint site.
• Email Entity:  An AD security group (or a distribution list) can be used as an email entity.
• Group Profile Synchronization: By default, SharePoint’s User Profile Services Application synchronizes groups (security groups & distribution lists) when it synchronizes user profiles.
  • SharePoint does not import AD security groups. It imports AD group memberships only. This is by Design. 
  • Imported groups are only used to create audiences and to display which memberships a visitor has in common with the person whose My Site the person is visiting.
  • SharePoint’s sync database uses the DN property (Distinguished Name) as the unique key for finding objects when storing them in its database. It doesn’t update/change that key subsequently even when the values that make up that key originally change (it does update their “values” etc.).

 What is the User Information List in SharePoint?

The User Information List (“/_catalogs/users/simple.aspx” or “_catalogs/users/detail.aspx”) is a hidden list in each site collection that is only visible and accessible to Site Collection Administrators.  The User Information List stores metadata information about a user. Some metadata examples are Display Name (name), Login Name (samAccountName), Picture, Email, SID (determines authorization rights) etc.

When an AD Security Group is granted access to a site, a new item will be created in the User Information List storing some metadata information about that AD group.

How Does AD Security Group Rename Affect People Picker & Permissions in SharePoint 2010?

LAB TEST SCENARIO:  Rename AD Security group “MarjGroupABC” to “MarjGroupDEF”

1) Created a new AD security group in AD directory service.

cn:  MarjGroupABC
distinguishedName:  CN=MarjGroupABC,CN=Users,DC=dev,DC=sp14a,DC=mapalm,DC=com
name:  MarjGroupABC
samAccountName:  MarjGroupABC

2) Using People Picker, searched for “MarjGroup” and see the “dev\MarjGroupABC” AD security group.  Selected and added the AD Security group “dev\MarjGroupABC” to the “Members” SharePoint group in root site of a site collection.

3) Existing domain user account “dev\TestUser1” has not been granted access to that root site of the site collection.  Therefore, User gets an Access Denied when trying to login to site.

4) In Active Directory, added existing domain user account “dev\TestUser1” to membership of “dev\MarjGroupABC”

5) Now in SharePoint, that user “dev/TestUser1” is able to successfully login to that root site of site collection.  User’s membership in AD group “dev\MarjGroupABC” caused it to inherit Contribute permissions for the site because the AD group was mapped to the Members group in SharePoint,

6) The “dev\MarjGroupABC” group appears as an item in the hidden User Information List of the site collection (/_catalogs/users/simple.aspx).

7) Using the Active Directory Users and Computers application, right-click the security group “MarjGroupABC” and select the Rename action.  Change the group name to “MarjGroupDEF”. After this change the security group’s “name” properties reflect the following values

cn:  MarjGroupDEF
distinguishedName:  CN=MarjGroupDEF,CN=Users,DC=dev,DC=sp14a,DC=mapalm,DC=com
name:  MarjGroupDEF
samAccountName:  MarjGroupDEF

8)  In the User Information List of the site collection (/_catalogs/users/simple.aspx) in SharePoint, the AD group still appears with the old name “dev\MarjGroupABC”.

9)  In the SharePoint group “Members” the AD group still appears with the old name “dev\MarjGroupABC”.

10)  Can the user “dev\TestUser1” still successfully login to the SharePoint site, even though the AD group was renamed in Active Directory?  YES!  The SharePoint permissions authorization for the user apparently were unaffected by the rename of the AD group.

11)  Looking at the User Information List of the site collection (/_catalogs/users/simple.aspx) in SharePoint again, the AD group still appears with the old name “dev\MarjGroupABC”.  The new “dev\MarjGroupDEF” name does NOT appear in the list.

12) Using People Picker in SharePoint, search for “MarjGroup” and now see both old and new AD security group names “dev\MarjGroupABC” and “dev\MarjGroupDEF”.

SHAREPOINT ISSUES OBSERVED AFTER AD GROUP RENAME:

1) ISSUE: Both the old and the new AD group names will show in SharePoint People Picker.  
2) ISSUE: Only the old AD group name displays as item in the hidden User Information List in SharePoint.  Reason is the Name (Display Name) still reflects old AD group name.  However, if you view the associated Login Name property for that item it does reflect the new AD group name.
3) ISSUE: Only the old AD group name displays as mapped member of SharePoint group.

Note:  SharePoint permissions authorization for the user appear to be unaffected by the rename of the AD group.

DESIRED OUTCOME:

1) Only the new AD group name should show in SharePoint People Picker.  
2) The new AD group name should display for the item in the hidden User Information List in SharePoint.
3) The new AD group name should display for the mapped member in the SharePoint group.

POSSIBLE WORKAROUND FOR DESIRED OUTCOME?

From my research and testing in my own SharePoint 2010 lab environment, the following steps seem to fix SharePoint to have the desired outcome. I would expect same outcome for SharePoint 2013.  If you plan to use this possible fix, you should fully test it in your own SharePoint test environment to ensure it fully works with no unexpected side-effects and meets your expectations.

Step 1) If the CN name is changed for an AD security group, then you would have to run the stsadm –o migrategroup command in SharePoint.  This seems to fix People Picker issue and fixes Login Name property.  For example,

stsadm –o migrategroup –oldlogin "dev\MarjGroupABC" –newlogin "dev\MarjGroupDEF"

Note: Above command seems to work OK, even though it displays an error “value cannot be null parameter name: userprofileapplicationproxy.”  Not sure why error displays???

Step 2) Write and execute a PowerShell script to change the “Display Name” on all SharePoint site collections as per new display name (name) attribute in AD

$login= "dev\MarjGroupDEF" # fill with correct new value
$title = "dev\MarjGroupDEF" # fill with correct new value
Get-SPSite -Limit all | % {$domainGroup = $_.OpenWeb().SiteUsers[$login]; if ($domainGroup -ne $null) {$domainGroup.DisplayName=$title; $domainGroup.Update()}}

How Does AD Group Rename Affect Audience Targeting in SharePoint 2010?

The impact of renaming a group (either a Distribution Group or an email-enabled Security Group) in Active Directory of will depend upon how the group is being used within SharePoint.

SCENARIO #1:  Group used in an audience definition within SharePoint Central Administration

• Issue:  Once an audience has been defined, it must be compiled on a regular basis because the underlying user profile properties and membership in directory services and groups can frequently change.

• Fix: An administrator schedules the timer job that controls when audiences are compiled.

SCENARIO #2: When you target a web part or a list item, you don’t *have* to use an audience, you can select an AD group directly.  

• Issue:  Webparts/documents that had audience targets for that renamed group will become broken (e.g., group name underscored with red squiggly line).

• Fix: You will need to manually ( or programmatically through PowerShell or standalone application ) identify and re-assign the audience to the webpart/document in the sites.

About Audiences in SharePoint

Audiences can be defined by one or a combination of the following items:

• Membership in a distribution list
• Membership in a Windows security group
• Location in organizational reporting structure
• By public properties in user profiles

Audiences Defined by Windows security groups and distribution lists:  

• The Windows security groups that are available when you are creating audiences are those that are imported when user profiles synchronized with the User Profile service application.
• The distribution lists that are available when you are creating audiences are those that are imported when user profiles are imported into the User Profile service application.

Compiling Audiences

Once an audience has been defined, it must be compiled on a regular basis because the underlying user profile properties and membership in directory services and groups can frequently change. An administrator schedules the timer job that controls when audiences are compiled.

What are recommended procedures for monitoring the Distributed Cache Service on SharePoint 2013 for scale-up (memory) or scale-out (add cache host) to handle increasing load?  I’ve done some initial research, and learned this isn’t an exact science.  I’ve provided some initial information I collected in this post.

The Distributed Cache Service provides in-memory caching services to several features in SharePoint Server 2013, and should be monitored for memory management, resiliency, and availability issues.  So, you might want to start by getting a pattern of usage (non-peak versus peak).  Note: I believe “load” as RPS (requests per second) would be driven by total users and number of concurrent users.  In a nutshell, the goal of the AppFabric service is to maintain the memory a cache host uses to store cached items between the low watermark and high watermark configured for that cache host.

To view common configuration details for individual caches, run the following command:

Use-CacheCluster
Get-AFCache | % {Get-AFCacheConfiguration -CacheName $_.CacheName}

You may want to know how many items are stored and how much memory is in use for individual caches. For specific stats about each cache, run this command:

Use-CacheCluster
Get-AFCache | % {
    $CacheName = $_.CacheName
    Get-AFCacheStatistics -CacheName $CacheName | Add-Member -MemberType NoteProperty -Name 'CacheName' -Value $CacheName -PassThru
}

You could pipe the output from this command to Export-Csv to create a short report. Typical output is shown here:

CacheName         : DistributedLogonTokenCache_f3bd4763-f482-4bb8-a5a5-f40806460bdd
Size              : 36864
ItemCount         : 6
RegionCount       : 6
RequestCount      : 55
ReadRequestCount  : 26
WriteRequestCount : 14
MissCount         : 32
IncomingBandwidth : 96924
OutgoingBandwidth : 880

Cache Statistics

Since the current amount of memory in use by the cache is so important, you’ll be interested in the commands which return a snapshot of current usage.  You have a couple options for retrieving information about all servers in the cluster, one using the Get-AFCacheHostStatus to iterate through all hosts, and one by finding all configured service instances in SharePoint. They are as follows:

Get-AFCacheHostStatus | % {
    $ServerName = $_.HostName
    Get-AFCacheStatistics -ComputerName $_.HostName -CachePort $_.PortNo | Add-Member -MemberType NoteProperty -Name 'ServerName' -Value $ServerName -PassThru
} | Format-List -Property *

**OR**

$SPDCServers = Get-SPServer | ? {($_.ServiceInstances | % TypeName) -contains 'Distributed Cache'} | % Address
$SPDCServers | % {
    $ServerName = $_
    Get-AFCacheStatistics -ComputerName $_ -CachePort 22233 | Add-Member -MemberType NoteProperty -Name 'ServerName' -Value $ServerName -PassThru
}

And typical output looks like this:

ServerName      : SERVER09
Size            : 51200
ItemCount       : 18
RegionCount     : 13
NamedCacheCount : 10
RequestCount    : 393
MissCount       : 66

From…
AppFabric Caching (and SharePoint): Configuration and Deployment (Part 2)

The Distributed Cache can be monitored using below performance counters in Perfmon:

SharePoint Distributed Cache Counters
• Cache Data Transferred Per Sec
• Cache Hit Count
• Cache Hit Ratio
• Cache Miss Count
• Cache Read Requests per sec
• Cache Write Requests per sec
• Total Cache Read Requests
• Total Cache Write Requests

Additionally, there are three groups of ‘AppFabric’ counters available. Note there are multiple instances – indicating the different caches present in the Distributed Cache.

• AppFabric Caching:Cache
• AppFabric Caching:Host
• AppFabric Caching:Secondary Host

Note: If “Cache Miss Count” should to rise significantly higher than expected (based on usage patterns), I think that might warrant some deeper investigation.

From…
SharePoint 2013 Distributed Cache service

General capacity planning and tuning guidance for Distributed Cache Service:

Plan for feeds and the Distributed Cache service in SharePoint Server 2013
See topics:
• Capacity planning for the Distributed Cache service
• Memory Allocation

Manage the Distributed Cache service in SharePoint Server 2013
See topic:
• Fine-tune the Distributed Cache service by using a Windows PowerShell script

How to check the existing memory allocation for the Distributed Cache service on a server:

Run the following command at the SharePoint Management Shell command prompt:

Use-CacheCluster
Get-AFCacheHostConfiguration -ComputerName ComputerName -CachePort "22233"

Where:
• ComputerName is the computer name of the server that you are running the SharePoint Management Shell cmdlet on.

How to modify the memory allocation of the Distributed Cache:

Update-SPDistributedCacheSize -CacheSizeInMB CacheSize

Notes:
• The Distributed Cache service, cache size should not exceed 16 GB
• When more than one server is used for Distributed Cache in a cluster, all the servers must have the same cache size configured.

Warning About Using Cmdlets Add/Remove-SPDistributedCacheServiceInstance:

If you uninstall and reinstall the Distributed Cache Service Instance on a server (i.e. by running Remove-SPDistributedCacheServiceInstance and then Add-SPDistributedCacheServiceInstance) the cache host size will be reset to the default (5% of physical memory at time of installation). If removing and adding the cache service instance is part of your maintenance cycles, make sure to also modify the cache size afterwards if needed.

As an example, I took a quick look in my own SharePoint 2013 lab environment at a web application which had 1 content DB. Following is what I observed for SQL vs. SharePoint size proportion...

Web application:  https://intranet.contoso.com
Content database:  WSS_content_intranet

Per SharePoint
• Site Collection Count : 19
• Sum of Size in MB     : 110.757159233093

Per SQL Server Management Studio
Database: WSS_Content_Intranet
Properties:
  • Database Size:  206.06 MB
  • Database Space Available:  1.09 MB

C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\WSS_Content_Intranet.mdf
154 MB

C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\WSS_Content_Intranet_log.ldf
52.MB

Total size of all site collections was about ½ of the database size property in SQL Server Management Studio.  What might explain this?

The SQL database size is the physical size of the database files (mdf and ldf). It is queried by the sp_helpdb stored procedure. This size includes all SQL data related to the database: transactions logs, indexes, SQL database schema, permissions and tables metadata. Depending on SQL administration it may include pre-allocated space for future growth - around 10-25%.

For SQL Server, actual content size can fluctuate up and down over time. When has backup happened? That will commit all transactions to the DB and the size will become smaller.  The mdf file size can be smaller than the DB size in SQL Management studio, that is because Management studio shows the current database size including uncommitted transactions in the transaction log(ldf).

Why is SharePoint’s report of current site usage so much less that what shows in SQL content database?  There is no actual direct correlation between the database size and content size. One reason is SharePoint will display the size of the content stored within the Content Database (caveat: also read below referenced Support article "Total Size from Storage Metrics shows full size file version in SharePoint 2013"), but it won't include the size of the whitespace, that is the disk space currently allocated to the database files to permit more content to be uploaded.  As users add content to their SharePoint sites, the content database will naturally grow.  To have a content database size that is larger than the content is usually a good thing because it gives SharePoint room to grow without the performance hit of having to auto grow the DB at every write/save.

If the database size relation to the content size gets unreasonably big then a shrink might be motivated, but do proper research on the effects first.  Shrinking database files should only be done in very specific circumstances (NEVER automatically or as part of a maintenance plan) because they cause horrible fragmentation of your databases. A good candidate is the situation where you just moved a large site collection to another content database and you leave your original database with 80% of unused space for example. Database files grow, that's what they do.

If a user uploads ten 1 MB documents to a site, you’d see the site content in SharePoint’s report increase by about 10 MB. At the same time, the SQL database size either may not change in case space has already been allocated for this data; or the change will be greater as SQL needs to keep auxiliary structures such as transactions logs, indexes, document properties in order to store these documents. So, there will be storage overhead added by SharePoint and possibly by SQL auxiliary data.

The site collection size SharePoint reports does not include SharePoint permissions structures, audit and events data.  It is comprised of the total size of the following data:

• documents
• doc versions
• list items
• account personalization info
• webparts
• document metadata
• Recycle bin (1st stage end-user recycle bin)

How is the SharePoint’s storage usage calculation for a site collection done?  For inquiring minds who want to know… SharePoint scans AllDocs, AllFileFragments, AllWebs, AllLists, AllDocVersions, AllUserData, AllWebParts, Personalization, ContentTypes, and RecycleBin for the total size. Please note, the DocStreams table is not considered in this algorithm. There’s a gap between the AllDocs and DocStreams for the same file. The actual file in binary form is stored in DocStreams. AllDocs table stores the meta info. Thus, the DocStreams table will be huge if there’re lots of files stored in the site. That being said, now the question is why DocStreams is not considered in the calculation algorithm.  The reason is a) this is an auxiliary table that only contains binary information; b) the information in this table does not actually reflect the file size, but size of the binary length. Therefore, it is not considered.  As a result, the content size stored in the database for a site collection takes more space than reflected in SharePoint’s storage usage calculation.

You might wonder since the calculated site collection size and actual content size are not aligned, what’s the point? This number will be the same once the site collection is backed up to disk (using stsadm -o backup or backup-spsite). If you’re interested, the size reported in the SharePoint UI is from SPSite.UsageInfo.Storage (https://msdn.microsoft.com/EN-US/library/microsoft.sharepoint.spsite.usageinfo.storage) and its internal name is SiteDiskUsed. You can manually force a re-calculation using SPSite.RecalculateStorageUsed (https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsite.recalculatestorageused).

What features in SharePoint 2013 can influence the size of content databases?  The following SharePoint Server 2013 features can significantly affect the size of content databases:

• Recycle bins:  Until a document is fully deleted from both the first stage and second stage recycle bin, it occupies space in a content database. Calculate how many documents are deleted each month to determine the effect of recycle bins on the size of content databases. For more information, see “Configure Recycle Bin settings in SharePoint Server 2013.”
• Auditing:  Audit data can quickly compound and use large amounts of space in a content database, especially if view auditing is turned on. Rather than letting audit data grow without constraint, we recommend that you enable auditing only on the events that are important to meet regulatory needs or internal controls. If you enable auditing within a site collection, use the following guidelines to estimate the space that you must reserve for auditing data:
  • Estimate the number of new auditing entries for a site, and multiply this number by 2 KB (entries generally are limited to 4 KB, with an average size of about 1 KB).
  • Based on the space that you want to allocate, determine the number of days of audit logs you want to keep.
  • TIP!  Remember to also configure automatic audit log trimming for your site collection.  Site Settings > Site Collection Administration > Site collection audit settings > Audit Log Trimming
• Gradual site delete:  When you delete a site collection, it’s not immediately completely deleted from the source content database just the flag for deletion has been set to 1 in the database for that site collection. You will find a timer job in central administration, scope to the web app, which is called “Gradual site delete.”  This job needs to run to delete the whole site collection from the database. The timer job is scheduled by default to run daily, but you can also force it to run manually. When that job runs the source database should get smaller for the size of the site collection removed.

ADDITIONAL REFERENCES

Total Size from Storage Metrics shows full size file version in SharePoint 2013
https://support.microsoft.com/en-us/kb/3038333

Software boundaries and limits for SharePoint 2013
https://technet.microsoft.com/en-us/library/cc262787.aspx

Storage and SQL Server capacity planning and configuration (SharePoint Server 2013)
https://technet.microsoft.com/en-us/library/cc298801.aspx

Configure Recycle Bin settings in SharePoint Server 2013
https://technet.microsoft.com/en-us/library/cc263125.aspx

Timer job reference (SharePoint 2013)
https://technet.microsoft.com/en-us/library/cc678870.aspx

Best practices for SQL Server in a SharePoint Server farm
https://technet.microsoft.com/en-us/library/hh292622.aspx

When did the issue start?

How many users are experiencing the issue?

• Are all users affected, or just some?

• What is user login account of an affected user?

Is the issue specific to only one computer?

• What is public IP address of the affected computer?

• Is the user is behind a firewall or proxy?

For a user experiencing slowness, does same user experience same slow performance when using a different PC or device to access SharePoint?

Is the issue specific to one geographical location?

What kinds of users are experiencing the issue?

• Are AD managed user accounts affected?

• Are federated user accounts affected? If so:

    o Are you using Active Directory Federation Services (AD FS)? If so, how is your AD FS setup? DirSync?

    o Are you using any third-party solutions like Ping federated?

Does the specific network affect the performance? For example,

• Is the issue occurring from the office network?

• Is it occurring on cellphones or mobile devices that aren't connected to Wi-Fi?

• Is it occurring from home?

• Is it occurring from a free Wi-Fi hot spot?

What is URL of site where slowness observed?

What is URL to one particular page exhibiting slowness? Can you screen capture page?

What authentication types and providers are configured for the SharePoint web application?

Can you clarify the particular type of SharePoint Online slowness observed? For example:

• Site pages are slow to display?

• Slow response from dialog windows?

• File uploads or downloads are generally slow?

Is the performance problem intermittent, or constant? If it's intermittent,

• Have you identified any pattern with the behavior?

• Does the time of day make a difference?

Page/Site Scope:

• Are all pages in a site exhibiting slowness?

• Is only a specific page exhibiting slowness? If so:

    o What's located on the affected Page?

    o When you browse to the slow page, add ?Contents=1 to the end of the URL. The Web Part maintenance page will appear. Can you screen capture?

• Are all sites in the site collection exhibiting slowness?

• Are multiple site collections exhibiting slowness?

• Does the issue occur only on a new or on an existing site collection, or both?

• If you add a new page to the site, is that new page also slow?

Is the site customized? If so:

• Has the customization ever worked, or is this a new feature?

• Could the customization be involved in degrading performance?

• What is the goal or purpose of the customization?

• How are you customizing site?

Are publishing features enabled for the site?

Has anything changed since the time that the page worked correctly and now?

• Have you migrated any content to the site collection? If yes, are you still migrating content?

• Have you on-boarded lots of new users?

• Have you created lots of content recently?

If the slow page displays a view of a list/library, how many items are in current view?

TOOLS YOU CAN USE TO COLLECT DIAGNOSTIC DATA

Fiddler trace (https://www.fiddler2.com/fiddler2/): Fiddler is a free web debugging tool which logs all HTTP(S) traffic between your computer and the Internet. Recommend you capture a Fiddler trace while doing following:

• Browse to your site where experiencing slowness and perform actions that are taking longer than expected.

• Browse to multiple libraries or lists on the site. View at least 2 to 3 libraries and or lists.

• Have you seen issues with Searching performance? If so, run a search query.

• Upload a document. To limit the time that is required to test, use a file that is approximately 1 megabyte (MB), but no larger than 10 MB.

• Download one or more files.

Fiddler Notes:

• In the Fiddler trace you should see http status codes of 200 or 401. You shouldn’t see a 304 error. A 304 error indicates you are using the local copy. If you see 304 errors, that means the Fiddler trace has to be rerun after clearing local browser cache. There is a clear cache button in Fiddler that can also be used. The goal for a good Fiddler trace collection is to capture all the CSS files, JS files, and so on, to help diagnose the issue.

• When collecting a Fiddler trace, it's ideal to obtain a Fiddler trace where the issue reproduces. However, this isn't required. If the issue is intermittent, collecting a Fiddler trace correctly can be very important for understanding your general code flow and page request and can help facilitate troubleshooting

PathPing to the site (https://technet.microsoft.com/en-us/library/ff963096.aspx)

• Can help diagnose network connectivity and congestion issues. PathPing is a command-line route tracing tool that combines features of the tools Ping and TraceRt with additional information. PathPing sends packets to each router on the way to a final destination over a period of time, and then computes results based on the packets returned from each hop. PathPing shows the degree of packet loss at any given router or link, allowing you to pinpoint which routers or links might be causing network problems.

UPDATE NOVEMBER 30, 2015:  Clarification that this History List purge best practice is also applicable for:

• SharePoint 2010 & 2013 style workflows in SharePoint 2013
• SharePoint 2010 & 2013 style workflows in Office 365 SharePoint Online

Why?
The SharePoint 2010 built-in workflow cleanup job removes workflow history associations, but does not actually delete the items from the Workflow History list, allowing that list to potentially grow very large and unmanageable…sometimes millions of items (can severely impact site performance)!  Also when items exceeds 5,000 in the Workflow History list, query throttling can make the list difficult to view without a filtered query that returns less item results than the list view threshold.

Can I just increase the query throttling threshold or disable throttling on the list? 
The Microsoft best practice guidance is, “We recommend against changing the query throttling thresholds (or disabling throttling on a list). The default limit of 5,000 items was chosen to match the default point at which SQL Server will escalate from row-level locks to a table-level lock, which has a markedly detrimental effect on overall throughput.” 

Additional Information…
A workflow is made up of a sequence of events such as workflow initiation, task creation, and task completion. When you add a workflow, you specify a task list and a history list that workflow instances of that workflow association will use to track the events for the workflow. The task list contains items that users interact with and enter data into while interacting with a workflow. The workflow history contains key information about each event including date, status, participant, and description.

By default, Microsoft SharePoint Server 2010 runs a daily Workflow Auto Cleanup job to permanently delete workflow instances and related task entries that still exist 60 days after a workflow is completed or canceled. Workflow history items themselves are not deleted, but the entry point to view them on the status page for a particular instance of a workflow will no longer be available. As with any SharePoint list, as the workflow history and task lists grow in size, site performance may be compromised.

Best Practice Tips! 

•  Create a separate history and task list for each workflow association to distribute items across lists. Segregating each workflow to write into its own lists can help minimize total number of items in each list and may help avoid hitting SharePoint’s query throttling threshold.

•  Workflow history is not intended to be used to audit workflow events and is not necessarily secure because a user who has edit permissions on the site can update items in the history list, by default.  If auditing is crucial for workflows, such as tracking who approved a particular document and when, develop a custom audit mechanism (perhaps using a separate custom list or a site column to store the data).

WORKFLOW HISTORY LIST PURGE OPTIONS

The simplest purge solution to implement would be manually deleting the Workflow History list items on a regular basis before they surpass 5000 items.

An out-of-the-box solution approach to automate purging is configuring information management retention policy settings on workflow history lists, which allows SharePoint to regularly sweep the list and physically delete expired items.  One potential risk of this solution approach concerns long running workflow, because you might potentially delete history list items for which the workflow status is not yet completed.  However a best practice is to never design long running workflows (which pause and wait a long time for an event to occur before resuming and running to completion), so that shouldn’t be an issue!  Following is how to configure information management policy settings on the Workflow History list and have SharePoint automatically purge the list for you. 

1) Open the Workflow history list (your site url + Lists/WorkflowHistory

2) Open the List settings page, and select “Information management policy settings” in the Permissions and Management section. If you don’t see this option, you may need to enable the site collection feature, Library and Folder Based Retention

3) In the Content type policies, select the Workflow History content type, and then select “Enable Retention”. Once enabled, you will be able to select “Add a retention stage”.

Stage Properties

Event
  Time Period: Date Occurred + 120 days   (to purge any items over 4 months old)
Action:
  Permanently Delete

4) Save list policy, the expired items will be deleted the next time the timer jobs run.  

5) go to Central Administration -> Monitoring -> Review Job Definitions.

     In the list of timer jobs, select Information management policy and schedule the job to run at a particular instance of time (minutes, hourly, daily, weekly, monthly).  Then, select Run Now.

     In the list of timer jobs, select Expiration policy and schedule the job to run at a particular instance of time (minutes, hourly, daily, weekly, monthly).  Ensure previous job finishes running, then select Run Now.

Enumerate Site URLs in SharePoint Online
https://www.microsoft.com/en-us/download/details.aspx?id=44294

• File Name: CSOM-EnumerateSiteUrls.ps1
• Version: Oct2014
• Date Published: 10/3/2014
• File Size: 11 KB

Prior to running the example PowerShell script, you must install client components SDK in order to run SharePoint 2013 CSOM…

SharePoint Server 2013 Client Components SDK
https://www.microsoft.com/en-us/download/details.aspx?id=35585

How To Run CSOM-EnumerateSiteUrls.ps1

1. Launch a Windows Powershell window and Run As Administrator. 

Note: Do NOT launch SharePoint Online Management Shell window!  Do NOT execute any Connect-SPOService cmdlet!  Otherwise, script will fail with the error... 'New-Object : Cannot find an overload for "KeywordQuery" and the argument count: "1"'

2. Change directory to location of the PowerShell script.

3. Execute the PowerShell script.

.\CSOM-EnumerateSiteUrls.ps1

4. Script prompts to supply value for MySiteHostURL parameter value. Supply value similar to following, where "<tenant>" is your Office 365 tenant (example, "contoso").

https://<tenant>-my.sharepoint.com

5. Script prompts to supply value for Adminlogin. Specify a Global Administrator account for your tenant.

admin@<tenant>.onmicrosoft.com

6. Script prompts to "Please enter your password" for <Adminlogin>.  Type password for the Global Admin account specified as Adminlogin parameter. Then press Enter.

ADDITIONAL NOTES

I have test run the script successfully myself using installed SharePoint Client Components at version 15.0.4641.1002 (as verified in Windows Programs and Features).

Installed location of DLLs was...
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\ISAPI\

Microsoft.SharePoint.Client.dll
8/1/2014
V15.0.4641.1000

Microsoft.SharePoint.Client.Runtime.dll
8/1/2014
15.0.4561.1000

Microsoft.SharePoint.Client.Taxonomy.dll
8/1/2014
V15.0.4420.1017

Example Scenario:  You want to revise the default URL (https://servername:5555) for an existing SharePoint 2010 web application to be a more user-friendly URL (https://inside.contoso.com). Then users will solely access the web application using the new user-friendly URL.

Option 1:  Edit Bindings of IIS and Change the Alternate Access Mapping  [NOT RECOMMENDED]

1.1 Go to Central Administrator, System Settings, Farm Management, Configure alternate access mappings, Alternate Access Mapping Collection, Change Alternate Access Mapping Collection, Select the collection corresponding to the Web Application you wish to change.

1.2 Click Edit Public URLs, overtype the URL you wish to change, and click Save to save your AAM change.  SharePoint does not automatically change any bindings in IIS.

1.3 Using IIS Manager on each WFE server, manually change the bindings for the corresponding web site to match URL change.  Good idea to do an IISRESET /NOFORCE after changing IIS bindings.

1.4 Open a SharePoint Management Shell and execute PowerShell to update the display Name of the SharePoint web application to something meaningful.  For example,

 $rwa=Get-SPWebApplication | where {$_.Name -match "Your Old Web Application Name"}
 $rwa.Name
 $rwa.Name="Your New Web Application Name"
 $rwa.Update()
 Get-SPWebApplication | where {$_.Name -match "Your New Web Application Name"}

Pros:

• Avoids having to extend web application into another AAM zone (which would create an additional backing web site in IIS)
• Deployed custom solutions, including web.config customizations, are generally unaffected by this approach.

Cons:

• When you change the URL (Host Header and/or Port bindings) of a SharePoint web application by updating the Alternate Access Mapping and manually update the bindings in IIS, the SPWebApplication object which is stored in the objects table in the configuration database is never updated so it continues to maintain bindings knowledge of the original URL and not the new one.   When you start the Microsoft SharePoint Foundation Web Application service in Central Admin (or via PowerShell), the information from the associated SPWebApplication object in the configuration database is used when instantiating IIS Sites and original URL shows up.  How to avoid this issue?  The SharePoint PowerShell cmdlets do not provide a direct way to update web app bindings stored in the Config DB.  However, you could use PowerShell in combination with client site object model code to update the web app bindings in the config db to changed values.
• Changing the display Name property of the SharePoint web application via PowerShell does not correspondingly change the Alternate Access Mapping Collection name, which can be confusing.  Doesn’t seem to be a PowerShell cmdlet to directly change this AAM collection name.  Perhaps it can also be changed using PowerShell and client side object model code, but I haven’t explored this possibility.

Option 2:  Un-extend and re-extend the Web Application In SharePoint

2.1 Go to Central Administrator, Application Management, Select the Web Application you wish to change and click the arrow under Delete and choose Remove SharePoint from IIS Web Site.

2.2 Next, select the associated IIS Web site for which want to update the URL.  For Delete IIS web sites, select No and click OK.  Note: Content databases and IIS web sites are preserved.

2.3 Go to Central Administrator, Application Management, Select the same Web Application and choose Extend button on the ribbon.

2.4 Choose Use an existing IIS Site and choose the original site from Step 2.2 above. Specify the new IIS Web Site bindings, Host Header and/or Port, and any other settings that should match.  SharePoint will automatically update the bindings in corresponding web site in IIS.

Pros:

• Because you are re-using existing web site in IIS when you re-extend web app, this approach avoids extending web app and creating an additional backing web site in IIS.
• SharePoint automatically updates the corresponding web site bindings in IIS when using this technique.
• Whenever you create/extend a web application, SharePoint stamps the IIS Web Site bindings on the spwebapplication object which is stored in the objects table in the configuration database.  

Cons:

• Custom solutions. 
  • If you perform these steps on a web app with only one zone all the solutions deployed to the web app will be dissociated. Re-deploying them may cause issues because features might already be activated.  Test!
  • If the web.config for a web application has been manually customized outside of SharePoint, be aware that Extending a web application creates a new default web.config file and will lose your customizations.

Option 3:  Delete and re-create the Web Application in SharePoint

3.1 Go to Central Administration, Application Management, Select the Web Application you wish to change and click the arrow under Delete and choose Delete Web Application. Selection delete options to keep the content databases but delete the IIS web site.

3.2 In Central Administration, Application Management, click New to create a new application.

3.3 Specify a new IIS Web Site and new binding information, Host Header and/or Port.  For Database Name, specify the existing content database name retained in step 3.1. Verify that the Public URL field is correct.  Specify any other settings as appropriate.  Click Save to create the new web app and IIS web site, reusing existing content database.

Pros:

• Because you are deleting and recreating web site in IIS, this approach avoids extending web app and creating an additional backing web site in IIS.
• SharePoint automatically updates the corresponding web site bindings in IIS when using this technique.
• Whenever you create/extend a web application, SharePoint stamps the IIS Web Site bindings on the spwebapplication object which is stored in the objects table in the configuration database.  

Cons:

• Suitable only if web application is not currently extended and URL exists only in Default zone.
• Custom solutions. 
  • If you perform these steps on a web app with only one zone all the solutions deployed to the web app will be dissociated. Re-deploying them may cause issues because features might already be activated.  Test!
  • If the web.config for a web application has been manually customized outside of SharePoint, be aware that recreating a web application creates a new default web.config file and will lose your customizations.

ADDITIONAL REFERENCES

Update a web application URL and IIS bindings for SharePoint 2013
https://technet.microsoft.com/en-us/library/cc262366.aspx

How to properly change the Host Header URL of a web application in SharePoint 2010
https://blogs.msdn.com/b/russmax/archive/2013/02/27/how-to-properly-change-the-host-header-url-of-a-web-application-in-sharepoint-2010.aspx

Example Scenario:  You want to add another user-friendly URL (https://inside.contoso.com) to an existing SharePoint 2010 or 2013 web application in addition to the default URL (https://servername:5555). Then users can access the web application using either the default or user-friendly URL.
 
To be in a Microsoft supported state, every alternate access mapping URL in SharePoint must have a backing IIS site which means that the web application has to be extended into another zone. What this means is you cannot have multiple public URLs in same AAM zone for one SharePoint web application.  Multiple internal URLs can be associated with a single public URL. But each zone can have only a single public URL.  If alternate access mappings are configured manually without extending web application, unexpected authentication failures could occur on some sites depending on authentication settings.  https://support.microsoft.com/kb/2624320
 
ADDITIONAL REFERENCES
 
VIDEO How Do I: Configure an Alternate Access Mapping in SharePoint 2010?
https://technet.microsoft.com/en-us/video/dn153778.aspx

Plan alternate access mappings for SharePoint 2013
https://technet.microsoft.com/en-us/library/cc261814.aspx

Extend claims-based web applications in SharePoint 2013
https://technet.microsoft.com/en-us/library/gg276325.aspx

Per Microsoft published TechNet guidance for SharePoint 2007/2010/2013, the Setup User Account must be a generic domain account that’s granted special permissions to perform initial SharePoint farm installation and configuration.  The Setup User Account  would be used to run setup to install SharePoint software on each server.  And then, to the run SharePoint Products Configuration Wizard to create new farm and join member servers to farm.  Why is the Setup User Account needed?  In the future when performing maintenance activities on the farm, the SharePoint Farm Administrator could encounter an out-of-the-ordinary Access Denied failure, for which logging in as original Setup User Account to perform the activity might be only possible resolution.  If the SharePoint farm was initially installed and configured by a user who logged in as their own user account and then that user later leaves the company causing their account to be deleted from Active Directory… then there may be no possible way to resolve such an Access Denied problem.

However after initial setup of the SharePoint farm is complete, I recommend my customers inactivate the Setup User Account in Active Directory so interactive logon is not possible, but leave all permissions granted to account intact.  Then in future if that account is needed quickly to resolve a troublesome Access Denied issue with maintaining the farm, simply re-active the account in AD and all necessary permissions are still effective.  I also recommend following…

SharePoint Farm Administrators Group

Recommend: To perform any ongoing maintenance to the SharePoint farm, avoid routine practice where SharePoint Farm Admins need to login interactively using SharePoint Server Farm Service account (or the Setup User Account). Move toward better practice where Farm Admins login interactively using their individual user accounts to perform their day-to-day duties.  Why?

• Security best practice is to not permit service accounts to be routinely used for interactive login by any user.  One reason is service accounts typically have very high privilege, usually more than is required by the user (doesn’t follow the least privilege security model). 
 
• Security best practice is to never allow users to share accounts.  Such sharing (such as by multiple farm admins) of a service account for interactive login makes it harder to audit who actually did what after-the-fact.

Recommend:  I have suggested that my customers establish role-based global groups in AD for SharePoint Farm Admins.  I recommend they create at least 2 SharePoint Farm Administrators groups in AD, 1 for production & 1 for non-production farms (dev, QA, etc).  The individual user accounts of each Farm Admin are then added as a members into the AD group.  When a Farm Admin is no longer in the role, you simply remove that user from AD group and all inherited permissions are automatically removed.

For example, SharePoint Farm Administrators Global Groups:
CONTOSO\SP15FarmAdminDev-G   
CONTOSO\SP15FarmAdminProd-G   

Grant the AD group necessary SharePoint Farm Administrator permissions:

• Add to SharePoint_Shell_Access role ("Add-SPShellAdmin CONTOSO\SP15FarmAdminDev-G")
• Logon Interactive Windows user right for each SharePoint Server
• Member of local Windows Administrators group on all SharePoint servers
• OPTIONAL: Granted Full Control permissions for each SharePoint web application via user policy
• Grant Logins privilege for SQL Server
• Grant SecurityAdmin and DBCreator fixed server roles in SQL Server
• Grant db_owner role to any existing SharePoint databases

Recommend: In future when SharePoint Farm Admins use Central Admin or PowerShell/STSADM to create a new content database, they should also submit a change request to DBA to grant the Farm Admins group the db_owner role privilege on that new DB. Otherwise, they will encounter Access Denied problems when trying to manage the content within the DB.  Plus the change request alerts the DBA that a new database has been created in SharePoint.

ADDITIONAL REFERENCES

Choose administrators and owners for the administration hierarchy in SharePoint 2013
https://technet.microsoft.com/en-us/library/cc263291.aspx

Plan for administrative and service accounts in SharePoint 2013
https://technet.microsoft.com/en-us/library/cc263445.aspx