All of a sudden one day (on my DEV PC) my Microsoft SQL Server 2012 instance (installed as instance name "SQL2012") would not start (all my other installed instances did). Trying to start it manually under Services failed. I don't recall making any recent changes prior to this. The cause of the failure was a mystery.
On inspecting Event Viewer, under System it showed a rather amusing error message [emphasis mine]:
The SQL Server (SQL2012) service terminated with the following service-specific error:
WARNING: You have until SQL Server (SQL2012) to logoff. If you have not logged off at this time, your session will be disconnected, and any open files or devices you have open may lose data.
checking under Application Event Log, I found these 2 error messages (preceded by a number of MSSQL$SQL2012 informational messages):
Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 200, state 7, severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
followed by:
Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online.
Fearing having lost my system databases (and not having a backup of them to restore - who makes backups of their system dbs anyway??) and needing to access the instance, and attached databases - I was willing to try anything. Even the possible restore of the system databases: Restoring the SQL Server Master Database Even Without a Backup - but that looked quite complex.
Fortunately, I was eventually able to start the instance (thank you to this answer: https://stackoverflow.com/a/59676743/4993856 which I trusted, because Pinal Dave also mentions that particular switch in: SQL SERVER – Script level upgrade for database ‘master’ failed because upgrade step msdb110_upgrade.sql encountered error 926, state 1, severity 25) if I ran:
net start mssqlserver$SQL2012 /T902
This pointed to some issue with the upgrade script... (Remember SQL is installed with instance name: SQL2012, hence the mssqlserver$SQL2012 used above for the named instance).
After some more searching I discovered this post: Installing service pack / cumulative update on SQL Server 2016 / 2017 breaks database engine (not exactly the same SQL version as mine) which pointed to the following possible Region Settings setting (Control Panel [when viewed by 'icons'] > All Control Panel Items > Region > Administrative > "Change system locale..."):
"Beta: Use Unicode UTF-8 for worldwide language support" in Region Settings
THAT WAS IT!!! After de-selecting that option (and possibly restarting my computer), the MSSQL Server 2012 Instance started up without any issue, and I was able to access all my previously attached databases.
I assume the pending upgrade scripts ran successfully. Thinking back about it now, it is possible that I agreed to installing a SQL Update, and never bothered to test access to the instance afterwards.
I also don't recall exactly why I chose to enable that specific setting under Region Settings, possibly due to some Linux compatibility, but it looks like it has become defaulted 'on' in recent Windows builds.
I got the same problem SQL2017 after update Windows Patch Hotfix3391(KB5001228)
after restart server MSSQL Fail to start and event viewer shown error below
Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 200, state 7, severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
Solution
Fix by remove Beta:Use Unicode UTF-8 for Worldwide lang.. in the Region Settings
Then it require restart server. After restart MSSQL can start as normal.
The problem is the msdb_110.sql update script, the script is a bit of a mess, with mixed tabs and spaces (wtf?).
It tries to run a couple of procedures that fail, on startup of sql-server. They fail when the code-page is 65001 (usually because the BETA utf-8 code page option has been selected) and so SQL server fails to start.
This appears to happen any time a SQL Server update is installed. I only experience this error with SQL Server 2017, not 2019
Why?
Don't know? The script is a mess.
Solution
Deselect the use utd-8 code page option
Restart the machine
Start sql server and let it run the script
(optional) reselect the use utd-8 code page option
Restart machine again and sql server
(optinal but recommended) uninstall windows, install a unix and run postgres
Related
I am trying to install SAP R/3 ABAP, where databse instance is on one machine and central instance on different machine.
Database instance installation is finished but when trying to install central instance when sapinst tries to connect from Central Instance to database instance following error comes up
WARNING 2009-05-02 07:53:08.490
CJSlibModule::writeWarning_impl() Execution of the command "/usr/sap/E64/SYS/exe/run/startsap all DVEBMGS00 hpvm-202" finished
with return code 6.
Output: Database B11 must be started on remote
server Log on to remote server and start database
So, I went to database server and verified and database was indeed running (mounted and open).
ghoul3:e64adm 3> lsnrctl start
LSNRCTL for HPUX: Version 10.2.0.4.0 - Production on 02-MAY-2009 07:18:11
Copyright (c) 1991, 2007, Oracle. All rights reserved.
TNS-01106: Listener using listener name LISTENER has already been started
ghoul3:e64adm 4> /oracle/B11/startdb
Trying to start B11 database ...
Log file: /home/e64adm/startdb.log
B11 database started
R3trans –d from adm user runs perfectly
ghoul3:e64adm 8> R3trans -d
This is R3trans version 6.14 (release 701 - 26.01.09 - 12:46:00).
unicode enabled version
R3trans finished (0000).
I tried with shutdown database, restarting both systems but to no avail.
I don’t want to initiate a re-install as its consumes long time and chances are that same error crops up again, so better tackle it the first time itself.
Kindly advise how could we troubleshoot further or resolve this issue.
Just in case anyone faces the same issue, the problem lies with profile files, in profile files- Check for parameter named "SAPDBHOST" in DEFAULT.PFL.
Entry should be as
SAPDBHOST =
if it doesn't exit add hostname of the database instance.
Also, do check DEFAULT.PFL if the file name is "DEFAULT" only then rename it to DEFAULT.PFL.
My SSIS Package works, but fails as a SSMS job (Error: 0xC0016016)
I am posting this question and sharing my solution to this issue as my own question because I didn't see the posed problem match the specific issue I encountered and the answers seemed to be scattered in different forum questions.
Background:
I have four SSIS packages on SQL Server 2012 that import a table from SQL Server 2008 R2, 2008, or 2005, depending on the specific package. I use a designated sql server login and password for the source database and integrated Windows security for the target database.
Within SSIS I am able to run each package without a problem.
To ensure this package ran on a schedule, I set up a SSMS job on the same server as the SSIS package. In Job step properties, I chose: SQL Server Integration Services Package > run as SQL Sever Agent Service Account > Package source: File system).
The Symptom:
When manually running the job to make sure it worked, I got an error and saw this in the Log File Viewer. This was the first of several errors, but as this was chronologically the first error, I looked into this one first.
Error: 2014-10-24 09:52:34.48
Code: 0xC0016016
Source: [Redacted -- the correct name of the table I was importing]
Description: Failed to decrypt protected XML node "DTS:Password" with
error 0x8009000B "Key not valid for use in specified state.". You may
not be authorized to access this information. This error occurs when
there is a cryptographic error. Verify that the correct key is
available.
End Error
I looked up the error code on Google and started looking at resolutions. Rather than retelling how I found the bits and pieces of the resolution, I am presenting an actionable result in sequence -- at least for me and the network infrastructure I'm working with.
In the "properties" panel of the SSIS solution (do this first) and each package in that solution, reset the "ProtectionLevel" attribute to EncryptSensitiveWithPassword and set a password. The package passwords must match the solution password.
Just a double-check, run your packages in debug mode to make sure that no other new issues arise. In my case, I needed to re-enter the sql server password for the source server database.
Rebuild your SSIS solution.
In SSMS, open your job and open the job step properties for the task in question.
Select the "Command Line" tab. A "Package Password" popup appears. Enter the password that you entered in step 1.
Select "Edit the command line manually" and place the same password from step 1 immediately after /DECRYPT.
Repeat steps 4-6 for each job step that runs this type of package.
Press the "OK" button and re-run your job.
I was able to run my job successfully after that.
I'm hoping to configure and use SQL Server 2014's Managed Backup to Azure feature. I've tested a manual backup to URL T-SQL query, and it worked. But, the backups created by the managed backup to Azure feature are failing to finish.
The managed backup process leaves a bunch of 0 byte backup files on Azure storage, and they're all locked (active leases) because of the failed backup process. I'm trying to figure out what the issue is. My SQL Server 2014 edition is the Web edition, which apparently does not support compression. The SQL Server Management Studio dialog for configuring the managed backup to Azure feature does not provide any options for compression, though. So, perhaps it's trying to compress the backup file and failing? I don't know how to see what's actually being tried by SQL Server while it does its automated backup to Azure, though. Anybody have any ideas there?
I'm seeing the following errors in the event log ...
Date 10/1/2014 3:10:39 PM
Log SQL Server (Current - 10/1/2014 2:42:00 PM)
Source Backup
Message
BACKUP failed to complete the command BACKUP LOG CaseLaw. Check the backup application log for detailed messages.
Date 10/1/2014 3:12:01 PM
Log SQL Server (Current - 10/1/2014 2:42:00 PM)
Source spid71
Message
Error: 18210, Severity: 16, State: 1.
Date 10/1/2014 3:12:01 PM
Log SQL Server (Current - 10/1/2014 2:42:00 PM)
Source spid71
Message
BackupVirtualDeviceFile::DetermineFileSize: SetPosition(0,EOF) failure on backup device 'https://caselaw.blob.core.windows.net/sqldb01-mssqlserver/CaseLaw_d68e6c91feba4f7f891a66cb86fcce8d_20141001151038-05.log'. Operating system error Backup to URL received an exception from the remote endpoint. Exception Message: The remote server returned an error: (409) Conflict..
I can't read the full 409 error message, so I've got no idea what the actual 409 error is. According to MSDN, there are multiple possible 409 responses.
I have been struggling with this issue for several days. I tried a manual scheduled task that runs my T-SQL query, which works, but I can't have it automatically clean itself up after X days, using that method. Any ideas? Thanks!
This is indeed related to COMPRESSION being set on the backup command that gets called by the Managed Backup process.
Enabling debug messages pointed me to the stored procedure getting called: [msdb].[smart_admin].[sp_do_backup]. If you look inside this stored procedure you will see "COMPRESSION" hard coded into the various backup commands that it issues.
A find and replace for "COMPRESSION" to "NO_COMPRESSION" should fix your issue.
Note this only need apply to SQL 2014 Web Edition, as other versions support compression, and this shouldn't even come up.
I am for the first time trying to setup transactional replication. This is from an sql 2000 server sp3a to an sql 2005 server which I believe should work.
I did a quick test on my local machine (sql 2005) using it as both the publisher and subscriber and had no trouble setting it up. I repeated a similar process for the real servers using enterprise manager for the 2000 publisher parts and management studio to setup the PULL subscriber. This all seemed to work and the publisher logs seem to be indicating it was preparing the initial data however I am not getting anything coming over as of yet. I checked the logs and am getting an os error 3. I have included the two log sections I think are important below.
2009-07-21 21:37:42.043 The process could not read file 'D:\Program Files\Microsoft SQL Server\MSSQL\ReplData\unc\DOMINO_qlsdat_DOMINO qlsdat to PONGOSQL\20090721164816\enbhostname_1.sch' due to OS error 3.
Message
The replication agent encountered an error and is set to restart within the job step retry interval.
See the previous job step history message or Replication Monitor for more information.
Looks to me like I need to give share permission to the replication data, should I have setup the replication data to go to a share using unc path.
OS Error 3 is no a permission problem, is a path correctness problem: Error code: (Win32) 0x3 (3) - The system cannot find the path specified.. A permission problem would be error 5: Error code: (Win32) 0x5 (5) - Access is denied..
The path D:\Program Files\Microsoft SQL Server\MSSQL\ReplData\unc\DOMINO_qlsdat_DOMINO qlsdat to PONGOSQL\20090721164816\enbhostname_1.sch is incorrect on the server that executes it. Usually one has to use UNC paths in replication, I can't know for sure if that is the problem, but it likely is.
We've been having some issues with a SharePoint instance in a test
environment. Thankfully this is not production ;) The problems started
when the disk with the SQL Server databases and search index ran out
of space. Following this, the search service would not run and search
settings in the SSP were not accessible. Reclaiming the disk space did
not resolve the issue. So rather than restoring the VM, we decided to
try to fix the issue.
We created a new SSP and changed the association of all services to
the new SSP. The old SSP and it's databases were then deleted. Search
results for PDF files are no longer appearing, but the search works
fine otherwise. MySites also works OK.
Following the implementation of this change, these problems occur:
1) An audit failure message started appearing in the application event log, for 'DOMAIN\SPMOSSSvc' which is the MOSS farm account.
Event Type: Failure Audit
Event Source: MSSQLSERVER
Event Category: (4)
Event ID: 18456
Date: 8/5/2008
Time: 3:55:19 PM
User: DOMAIN\SPMOSSSvc
Computer: dastest01
Description:
Login failed for user 'DOMAIN\SPMOSSSvc'. [CLIENT: <local machine>]
2) SQL Server profiler is showing queries from SharePoint that reference the old
(deleted) SSP database.
So...
Where would these references to DOMAIN\SPMOSSSvc and the old SSP
database exist?
Is there a way to 'completely' remove the SSP from the server, and
re-create? The option to delete was not available (greyed out) when a
single SSP is in place.
As Daniel McPherson said, this is caused when SSPs are deleted but the associated
job are not and attempt to communicate with the deleted database.If the SSP
database has been deleted or a problem occurred when deleting an SSP, the job may
not be deleted. When the job attempts to run, it will fail since the database no
longer exists.
Follow the steps Daniel mentioned:
1. Go to SQL Server Management Studio
2. Disable the job called SSPNAME_JobDeleteExpiredSessions, right click and choose Disable Job.
I suspect these are related to the SQL Server Agent trying to login to a database that no longer exists.
To clear it up you need to:
1. Go to SQL Server Management Studio
2. Disable the job called <database name>_job_deleteExpiredSessions
If that works, then you should be all clear to delete it.
Have you tried removing the SSP using the command line? I found this worked once when we had a broken an SSP and just wanted to get rid of it.
The command is:
stsadm.exe -o deletessp -title <sspname> [-deletedatabases]
The deletedatbases switch is optional.
Also, check in Central Administration under Job Definitions and Job Schedules to ensure no SSP related jobs are still running