Shredded Storage in SharePoint 2013

What Is Shredded Storage:

Shredded Storage is going to help us with BLOBS (Binary Large Objects).

1. It’s reduces the network IO by shredding the document into smaller pieces and reassembling when someone requests it.
2. It reduces the amount of data saved in content databases.
3. It decreases the amount of network traffic between the web servers and the SQL servers.
4. Allows for faster backup of content databases.

 

Other Benefits:

• A User can open a cached document, and start working with it before it is completely downloaded.
• Documents are uploaded to the server in the background.

Shredded Storage is on by by default. It can be disabled or enabled per web application. BLOBs are not shredded on an upgrade. Shredded Storage  is independent of RBS.

 

Advertisement

Restore Project server databases and instances to another farm

As I said in my previous post, today we will see how can we move project instances to another farm which including all your project server databases.

Before we delete PWA databases from sql server we need to accomplish some tasks in the order:

• Delete/remove all the pwa instances from project server provisioning center (PWA service app)
• Connect to sql server analysis services and delete the respective pwa instance cube db’s.
• Go to timer service job definition and remove any jobs related starts with  PWA*
• Verify back with powershell commands below listed if you still have any orphaned PWA instances or timer jobs and remove them.

1.   Open the SharePoint management shell and run these commands.$serviceapp = get-spserviceapplication | ? {$_.TypeName –like “*Project*”}
   This will get the project server service application
   $pwainstances = $serviceapp.Sitecollection

   $pwainstances | ft name, id
   This will list all PWA instances referenced in the config DB

2.  

   Repeat these steps for each PWA site to delete them individually

   $toberemoved = $pwainstances | ? {$_.Id –eq “a1a29814-983e-4cad-a730-9a80d40737f7”}
   Enter the instance ID from query results in the previous step
   $toberemoved
   This will confirm the instance you want to remove
   $toberemoved.Delete()
   This will delete the instance

We can now go forward and backup the pwa db’s and restore them to this farm.  follow steps to restore db’s

Now comeback to Project Service Application and create a new PWA instance and provide the same PWA instance name which exists in your other farm (eg: http://spserver-webapp/PWA-name ) so PWA-name should be same as restoring farm pwa-name – *important*. Then provide the database names while creating the pwa instance as you restored from source farm. Once the pwa instance is created we need to create the PWA root site. Note: do not backup and restore the root site db from source farm, rather create a new db and assign max site count to 1. Basically we are storing each PWA instance root site separately for each PWA site.

Post Update tasks after the PWA instance and root site are created:

• Open the PWA instance site and go to server settings -> manage users and add the service account or your admin account to the list or users and administrators group, as the current db does not contain the destination farm service account it will hold the source farm farm account.
• Then open up the “Basic Project Plan” under workflow and project detail pages –> Enterprise project Types. Open the Basic project plan and add the project detail pages as below.
•  
• Either disable notifications E-mail settings or modify them to suit this farm. This setting under operational policies –> Alerts and Reminders
• Go to OLAP database management which you can find under Database Administration. Edit the existing one listed and change the database server and instance details, give it a couple of seconds and click “build Now” and watch the status there it self as it refreshes.

We should be good, if every thing went well. Also follow the below links for further troubleshooting.

http://social.technet.microsoft.com/Forums/sqlserver/en-US/61979d9a-59f5-49bf-b047-724f4c859a22/migrating-project-server-2010-to-new-farm

http://pwmather.wordpress.com/category/migration/

http://technet.microsoft.com/en-us/library/gg128952.aspx#section4

 

Can you move a single large site collection into multiple content databases?

Although single content databases of upto 200GB is possible in Sharepoint 2010, administering and managing such a db would be a nightmare. What would you suggest for options in a case where there is one site collection and one corresponding content database. Can you have more than one content db for that one site collection? Can you expand the table to be hosted on other sql servers/machines? Does RBS help?

Expert Comments:

Officially there is support up to 4TBs with optimization, but realistically that is difficult to support and should only be used in extreme exceptions. Technically there were no real changes made to support the additional sizes, it was just an update to guidance. I still try and work with my customers to maintain databases no larger than 75-100GBs unless absolutely necessary. I do have customers with multi-terabyte farms.

A single site collection can only use 1 Content DB. It is possible though to create solutions that use a single site collection that interacts with multiple site collections for content storage. Its transparent to the users, but splits the content across multiple sites, multiple content dbs.

RBS can also help. The big advantage there is it reduces storage within the content db. I’m not as sold on RBS though in most scenarios. There are benefits, but there are also costs and added complexity. If you have an extremely large data source that MUST be in a single site collection and content cannot be archived, then this may be a good solution.

As for multiple SQL servers, you can leverage multiple SQL servers for a single farm, but my understanding is that a single database and all supporting data/log files must be part of the same instance. Using multiple data files on separate disk partitions though is part of the guidance to increase performance on those content dbs above 200GB.

Recover Sharepoint 2013 databases from suspect mode.

This Post courtesy to: Lydia Bronze
Original Post from: Blogs.cloudshare.com

I restarted my SharePoint server, opened Central Administration and encountered the following error:
Server Error in ‘/’ Application
Runtime Error
Description: An application error occurred on the server.

In order to troubleshoot this issue I had to check couple of thing:

• Make sure SQL Server services are up and running
• Make sure the IIS application pools are started
• Review Windows logs and gather more information about the server. I noticed the following event:

SQL Database ‘SharePoint_Config’ on SQL Server instance ‘C4968397007′ not found. Additional error information from SQL Server is included below.
Cannot open database “SharePoint_Config” requested by the login. The login failed. Login failed for user ‘DC07SQLSvc’.

This event made me suspect something is wrong with my SQL Server. I opened SQL Server management studio and noticed that some of my most critical SharePoint databases are not accessible and set to suspect mode.
What is a suspect mode in SQL Server database?
Suspect mode might be caused by many reasons like unavailable or corrupted database files, hardware failure etc.
Don’t worry! This situation is reversible.
Here’s a quick guide of how to recover your SharePoint databases from suspect mode:
Open your SQL Server management studio and execute the following queries one after another:

• Run the following query. sp_resetstatus command will turn off suspect flag on the database.

EXEC sp_resetstatus ‘SharePoint_Config’;

After executing this query you’ll see the following warning. Don’t worry, this doesn’t mean you did something wrong.

• The next step is to set the database to an Emergency mode. This can be done by executing following query:

ALTER DATABASE SharePoint_Config SET EMERGENCY

After executing this query your database should look like this:

Once we set the database to an Emergency mode it temporarily becomes a Read Only database.

• Execute the following query in order to check the logical and physical integrity of the objects in the database.

DBCC checkdb(‘SharePoint_Config’)

• To complete the process, run the following queries:

ALTER DATABASE
SharePoint_Config SET SINGLE_USER
WITH ROLLBACK IMMEDIATE
DBCC CheckDB (‘SharePoint_Config’, REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE SharePoint_Config SET MULTI_USER
DBCC CheckDB (‘SharePoint_Config’)

Repeat this action for each one of the affected databases.

I ran some basic tests to make sure my SharePoint server is working properly again, looks like everything is back to track.

January 29th, 2013 | Author: Lydia Bronze | Filed under: CloudShare, Dev / Test, SharePoint | Tags: CloudShare, Database, How-To, server error, SharePoint, SharePoint 2013, SharePoint Configuration, SharePoint Server, SQL, SQL Server, SQL Server 2012