Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I made a script for batch uploading files, which I successfully used to upload more than 900 files (few gigs of data). Today I prepared another set of files and everything was working fine, but suddenly script started to throw exceptions. I tried to refresh my list view, but I got 302 error after some time... From another computer there was the same issue. I then made an iisreset and got Runtime Error, that farm is not accessible. When trying to run central administration, It says that it cannot connect to configuration database.

Our database consist of two servers in failover cluster, and everything there looks good, although I can't say that servers didn't switch while uploading. We are also using RBS.

EDIT:

Following IAfanasov comment, I connected via remote desktop to DB server, and looks like everything looks good there - instance is running and server is accessible from another places in the network. I also checked logs, and found this:

System.Data.SqlClient.SqlException: A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)  
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)     at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)     at System.Data.SqlClient.TdsParserStateObject.WriteSni()     at System.Data.SqlClient.TdsParserStateObject.ExecuteFlush()     at System.Data.SqlClient.TdsParser.TdsExecuteRPC(_SqlRPC[] rpcArray, Int32 timeout, Boolean inSchema, SqlNotificationRequest notificationRequest, TdsParserStateObject stateObj, Boolean isCommandProc)     at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)     at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)     at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)     at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)     at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)     at Microsoft.Office.Server.Data.SqlSession.ExecuteReader(SqlCommand command, CommandBehavior behavior, SqlQueryData monitoringData, Boolean retryForDeadLock)

and following:

Unknown SQL Exception 121 occurred. Additional error information from SQL Server is included below.  A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)

ConnectionString: 'Data Source=spdb;Initial Catalog=SharePoint_Config;Integrated Security=True;Enlist=False;Asynchronous Processing=False;Connect Timeout=15'    ConnectionState: Closed ConnectionTimeout: 15

The Execute method of job definition Microsoft.SharePoint.Administration.SPConfigurationRefreshJobDefinition (ID 6d7865a0-84c4-4427-b8f3-ce229c08b7e3) threw an exception. More information is included below.  A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)

So it looks like SPDB (db cluster) went down (maybe because of network failure or nodes switching). But now SPDB is accessible and Sharepoint can't connect to config database...

Current logs say:

Cannot connect to SQL Server. spdb not found. Additional error information from SQL Server is included below.  Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.

But ping to SPDB works, and I didn't find anything suspicious on MSSQL server...

Edit 2:

It looks like our failover cluster failed due to errors on filestream share which is shared between cluster nodes. We tried to reboot the active node in cluster and we were counting that second node would become active. Unfortunately FILESTREAM share refused to become online and SQL instance failed to go online too. Have you ever faced similar issue and could provide some guidance?

share|improve this question
    
First of all, be sure about database instance started. Next, review logs in 14 hive\logs. View current logs and logs of supposed break time. –  IAfanasov Jan 18 '12 at 12:32
    
have you checked drive space? You're moving a lot of data, transaction logs may spike. Check you RBS location space? –  David Lozzi Jan 18 '12 at 13:34
    
RBS drive has 2TB space and moved data so far has c.a. 40GB Log files are: 8,76GB for SharePoint_Config db and 2,30GB for library content database. –  jjczopek Jan 18 '12 at 14:02
    
I receive some surprise:) After about 1 year after your question I faced same issue. Have you found solution and root of problem? –  IAfanasov Dec 25 '12 at 10:36
    
As far as I remember, the root problem was that heartbeat between cluster nodes was going through the main network, which was created lag and both nodes were assuming that they are Active and gained ownership of resources, which created errors in data being saved. Then heartbeat was moved to separete network (vlan i suppose) but there were some issues also. –  jjczopek Dec 27 '12 at 0:31

2 Answers 2

Can you go to your DB server and then follow the steps,

  1. Click Start and Open up SQL Server Configuration Manager

  2. There should be a node called "SQL Server Network Configuration"

  3. Opening it could give you "Protocols for MSSQLSERVER". Here MSSQLSERVER is my SQL instance name. Similarly open your instance where SharePoint DB resides.

  4. On the right pane, you can see options for TCP/IP protocol. enter image description here

  5. Enable TCP/IP and then check your Central Admin. It should work.

share|improve this answer
    
What does this achieve? –  Russell Jan 19 '12 at 11:24
up vote 2 down vote accepted

As I wrote in my question, It turned out that file system errors occurred on database cluster and it brought database down.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.