January 11, 2014 at 6:23 pm
Hi,
whenever we are moving system databases from one drive to another, do we need to move the path physically? or it automatically moves.
I want to try the rebuild the sql server. So I want to corrupt the master database so, I deleted the master mdf file and restore it back but instead of database corruption it is giving the following error message. Please let me know how can I corrupt the master database and can practice the rebuild the server.
And one more thing when I try to use the repair option I couldn't able to get all the things back to normal. The database engine service, replication is not working but SSAS, SSRS things are showing successfully repaired.
2014-01-10 21:34:26.44 Server Error: 26055, Severity: 16, State: 1.
2014-01-10 21:34:26.44 Server The SQL Server failed to initialize VIA support library [QLVipl.dll]. This normally indicates the VIA support library does not exist or is corrupted. Please repair or disable the VIA network protocol. Error: 0x7e.
2014-01-10 21:34:26.44 Server Error: 17182, Severity: 16, State: 1.
2014-01-10 21:34:26.44 Server TDSSNIClient initialization failed with error 0x7e, status code 0x60. Reason: Unable to initialize the VIA listener. The specified module could not be found.
2014-01-10 21:34:26.44 Server Error: 17182, Severity: 16, State: 1.
2014-01-10 21:34:26.44 Server TDSSNIClient initialization failed with error 0x7e, status code 0x1. Reason: Initialization failed with an infrastructure error. Check for previous errors. The specified module could not be found.
2014-01-10 21:34:26.44 Server Error: 17826, Severity: 18, State: 3.
2014-01-10 21:34:26.44 Server Could not start the network library because of an internal error in the network library. To determine the cause, review the errors immediately preceding this one in the error log.
2014-01-10 21:34:26.44 Server Error: 17120, Severity: 16, State: 1.
2014-01-10 21:34:26.44 Server SQL Server could not spawn FRunCM thread. Check the SQL Server error log and the Windows event logs for information about possible related problems.
January 12, 2014 at 4:10 am
When you move databases from one place to another (any database), you have to move the files, SQL doesn't automatically move files around for you.
Looks like you may want to reinstall. Repair wasn't the correct fix for a missing master database in the first place.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 12, 2014 at 11:37 am
Thanks Gail. I restored the data file again but still it is showing me that error.
January 12, 2014 at 12:12 pm
To corrupt a user database or the master database check my article at this link
Are there any other errors from the windows app log?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 12, 2014 at 12:53 pm
ramana3327 (1/12/2014)
Thanks Gail. I restored the data file again but still it is showing me that error.
I suggested reinstalling, not restoring a data file.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 14, 2014 at 5:25 am
IMHO moving a system database on a test server can be a useful part of educating yourself in how SQL Server works, what can break, and what needs to be done to fix it.
Moving a system database on a production server is not necessary, adds risk to your installation, and takes time away from doing productive tasks.
Just IMHO, not cast in stone...
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
January 14, 2014 at 1:11 pm
EdVassie (1/14/2014)
IMHO moving a system database on a test server can be a useful part of educating yourself in how SQL Server works, what can break, and what needs to be done to fix it.Moving a system database on a production server is not necessary, adds risk to your installation, and takes time away from doing productive tasks.
Just IMHO, not cast in stone...
It isn't necessary until it is 😉
I've had to move tempdb due to space issues (for example, on a production server where the drive space for tempdb wasn't allocated large enough) and it's a good idea to at least know how to move them, just in case.
January 14, 2014 at 1:28 pm
Moving TempDB is easy. The other three, not so much.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 14, 2014 at 1:52 pm
On many occasions I've been asked by clients to reconfigure a sql server and move the system databases, mainly because a vendor has deployed a server with mal configured local storage and the client has preferred to move the sql server drives to consolidated storage. It's deeply involved and you have to know exactly what needs to be moved, its not just the system databases usually 😉
I'll leave you to work out what else is required, if you get stuck shout.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 14, 2014 at 1:54 pm
GilaMonster (1/14/2014)
Moving TempDB is easy. The other three, not so much.
+1
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
January 14, 2014 at 3:03 pm
Just recently, I've had to move the system databases to a drive separate from the user databases due to a requirement from a 3rd party tool. We are evaluating using the backup process that our SAN vendor provides. That tool requires that the system databases be on their own SAN drive in order for the tool to work.
It was interesting running through the process. I learned a lot that I wasn't necessarily planning on learning, specially in the test environment. 🙂 For example how to recover SQL when I didn't do things in the right order, or got too click happy, or fat fingered something.
January 16, 2014 at 3:01 pm
GilaMonster (1/14/2014)
Moving TempDB is easy. The other three, not so much.
True enough. I needed to move tempdb on our production server a few months back and even that was making me nervous 😉 Not so much the moving part (which is easy) but the "how do I get things working again if something goes wrong?" aspect of it.
The others I have moved on development boxes, where it really didn't matter. Good to know how to do them, though.
February 8, 2014 at 6:56 am
oh. I am thinking that for temp db we don't need to move physically. Once you restart the server it will take the new path
February 9, 2014 at 5:55 pm
ramana3327 (2/8/2014)
oh. I am thinking that for temp db we don't need to move physically. Once you restart the server it will take the new path
Correct - when you restart SQL Server it will create tempdb at the new location. The only catch is that if for whatever reason the new location isn't accessible, SQL won't start and you'd need to restore master.
February 9, 2014 at 10:27 pm
cphite (2/9/2014)
The only catch is that if for whatever reason the new location isn't accessible, SQL won't start and you'd need to restore master.
SQL won't start in that case, but you don't need to do anything as extreme as restoring master.
http://www.simple-talk.com/sql/backup-and-recovery/the-sql-server-instance-that-will-not-start/
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply