Details:
SQL Server 2017 (Developer or Express edition)
Windows 2011 OS
I have followed this article already but no avail https://blog.sqlauthority.com/2017/01/27/sql-server-sql-installation-fails-error-code-0x851a001a-wait-database-engine-recovery-handle-failed/
Feature: Database Engine Services
Status: Failed
Reason for failure: An error occurred during the setup process of the feature.
Next Step: Use the following information to resolve the error, uninstall this feature, and then run the setup process again.
Component name: SQL Server Database Engine Services Instance Features
Component error code: 0x851A001A
Error description: Wait on the Database Engine recovery handle failed. Check the SQL Server error log for potential causes.
Error help link: https://go.microsoft.com/fwlink?LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=14.0.1000.169&EvtType=0xD15B4EB2%400x4BDAF9BA%401306%4026&EvtType=0xD15B4EB2%400x4BDAF9BA%401306%4026
WHAT IS THE CAUSE?
this is caused by the sector size of the disks.
During service startup, SQL Server begins the database recovery process to ensure database consistency. Part of this database recovery process involves consistency checks on the underlying filesystem before attempting the activity of the opening system and user database files.
On systems running Windows 11, some new storage devices and device drivers will expose a disk sector size greater than the supported 4 KB sector size.
When this occurs, SQL Server will be unable to start due to the unsupported file system as SQL Server currently supports sector storage sizes of 512 bytes and 4 KB.
You can confirm that you encounter this specific issue by running the command:
fsutil fsinfo sectorinfo E:
Look for the value PhysicalBytesPerSectorForAtomicity, returned in bytes. A value of 4096 indicates a sector storage size of 4 KB.
HOW TO FIX IT!
Simply follow the instructions on this page.
https://learn.microsoft.com/en-us/troubleshoot/sql/admin/troubleshoot-os-4kb-disk-sector-size#resolutions
if you don't want to change the os, you should try this resolution on the above site.
You can add a registry key which will cause the behavior of Windows 11 and later to be similar to Windows 10. This will force the sector size to be emulated as 4 KB in size. To add the ForcedPhysicalSectorSizeInBytes registry key, use the Registry Editor, or you can run one of the following commands in Windows command prompt or PowerShell, executed as an administrator.
After you change the registry, you must restart the device and then reinstall the program. Otherwise, this method will not work!
Related
I have a OLEDB task that connects to ms-access database on local file system and dumps data into sql database.
Access db connection string is: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.16.0;
The SSIS package runs OK in visual studio. Access 2016 32-bit runtime is installed on this computer.
After deployment to SSIS catalog, right click and execute works OK. Access 2016 64-bit runtime is installed on this computer.
When this package is scheduled to run via SQL Agent job, using proxy/credential [domain user - example: domainname\user1] (having read permission on the access db file), then the job fails. The SSIS execution report shows error as: Unexpected Termination. There is no further information.
Suppose if I add the proxy credential (domainname\user1) to the local administrators group (in computer management) then the SQL Job runs OK. What could be the solution to this so I can give only the minimum required permissions?
The error is very difficult to debug as it doesn't occur when running via visual studio. Even when deployed to the SQL server and run from the SSIS catalog, the execution works OK. The error occurs only when the package is run via SQL server agent job (via credential/proxy) - the SSIS execution report doesn't show any helpful messages; and surprisingly the error gets resolved when the credential is added as local administrator on the computer - which is a bad practice.
The solution is analyse what kind of ms access file you are using and appropriately use the correct access runtime version (2013 vs 2016) and the correct provider value in the connection string.
Access runtime:
In my case, I uninstalled Access 2016 64-bit runtime and installed Access 2013 64-bit runtime.
Provider version:
I changed the provider version from 16.0 to 15.0, as shown below-
Before: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.16.0;
After: Data Source=\\my-share\accessdbfile.accdb;Provider=Microsoft.ACE.OLEDB.15.0;
Note:
There is no need to add the user to the local administrator group.
There is no need to login to the computer using that account.
Only read permission (under windows folder security) is sufficient assuming the SSIS packge will only read the ms access database.
It's hard to debug this only with the information provided, but in general:
The user running the job requires at least write and delete access on the underlying folder in which the Access database resides. This is required to generate a lockfile for the database.
If this is undesirable because the job may be modified by a malicious user, I've seen deployments where a copy is made in a temporary folder with write access and a size quota, and that temporary folder is removed as soon as the job finishes, regardless of if the job succeeded.
Getting the following error while using mqsicvp to test connectivity to a ODBC data source from IBM Integration Console.
C:\Program Files\IBM\IIB\10.0.0.9>mqsicvp DEFAULTBRK -n MSAPP -v
BIP8299I: User 'db2admin' from security resource name 'odbc::MSAPP' will be used for the connection to datasource 'MSAPP'.
BIP2393E: Database error: ODBC return code '-1' from data source ''MSAPP'' using ODBC driver manager ''odbc32.dll''.
The integration node received an error when processing a database operation. The ODBC return code was '-1'. See the following messages for information obtained from the database about this error.
Use the following messages to determine the cause of the error. Typical problems are an incorrect data source, or table names. Correct either the database or the integration node configuration. Use the mqsicvp command to test connectivity to this database.
BIP2322E: Database error: SQL State ''IM003''; Native Error Code '160'; Error Text ''Specified driver could not be loaded due to system error 1114: A dynamic link library (DLL) initialization routine failed. (IBM DB2 ODBC DRIVER - DB2COPY1, C:\PROGRA~1\IBM\SQLLIB\BIN\DB2CLIO.DLL).''.
The error has the following diagnostic information: SQL State ''IM003'' SQL Native Error Code '160' SQL Error Text ''Specified driver could not be loaded due to system error 1114: A dynamic link library (DLL) initialization routine failed. (IBM DB2 ODBC DRIVER - DB2COPY1, C:\PROGRA~1\IBM\SQLLIB\BIN\DB2CLIO.DLL).''
This message may be accompanied by other messages describing the effect on the integration node itself. Use the reason identified in this message with the accompanying messages to determine the cause of the error. Use the mqsicvp command to test connectivity to this database.
BIP8040E: Unable to connect to the database.
The database cannot be accessed with the specified user Id and password pair.
- Check that the database is running.
- Check that the database has an adequate number of database connections available for use.
- On Windows, check that an ODBC connection has been created.
- On systems that use $ODBCINI, check that the file pointed to by $ODBCINI has been correctly updated.
- On z/OS check the BIPDSNAO member of the component's dataset, and check the DB2 64bit ODBC driver (DSNAO64C) is in the STEPLIB.
- Use mqsisetdbparms to set the password to the correct value and try again.
Software: Windows 10 / IIB 10 / DB2 Server
Steps to reproduce:
Set up ODBC (64-bit) connectivity to a new DB2 database in the form of a System DSN (using the IBM DB2 ODBC Driver version 11.01.2020.1393)
Test that connectivity works from ODBC data source administrator app
Use mqsisetdbparms from IBM Integration Console to set the user and
password
mqsisetdbparms DEFAULTBRK -n odbc::MSAPP -u uid -p pwd
Stop and start the broker
Use mqsicvp to test connectivity
mqsicvp DEFAULTBRK -n MSAPP
The DLL mentioned in the error is at C:\PROGRA~1\IBM\SQLLIB\BIN and this is included within PATH variable already.
I'm not sure why the driver manager odbc32.dll is being used - I presume this is a 32-bit version. However if I try creating a DSN in the 32-bit ODBC data source administrator app, mqsicvp fails with an error saying the architectures do not match.
Suggest you download the fix from IBM for bug IT23069. It is available (indirectly) from this page which eventually redirects to IBM fix central. Worked for me.
The newest developer edition toolkit, 10.0.0.12, seems to have fixed this.
the cmd execution of registerRExt.exe
I am trying to install RRE(Revolution R Enterprise) v7.5 with RR0 3.2.2(Revolution R Open) on a SQL Server 2016 RC0 default instance. All the steps shown in the https://msdn.microsoft.com/en-us/library/mt590808.aspx have been completed and the error occurs in the Post installation Server configuration scripts. The script has also been replaced by the updated script for RC0 shown on the msdn site but still I get the same error on running the registerRExt.exe file.
The site shows while installing the instance the account name for Server Database engine has to be MSSQLSERVER, however this had also resulted in an error stating wait on database recovery handle failed which was sorted by changing the account name of Database engine to NT AUTHORITY/SYSTEM(I provided this info as it can also be the cause of the problem) . Now I need to sort the user pool failure. Any help would be appreciated..thanks in advance
SQL 2016 RC1 was just released https://blogs.technet.microsoft.com/dataplatforminsider/2016/03/18/sql-server-2016-release-candidate-1-now-available/.
SQL RC1 has a newer version 8.0.1 version of RRE. I suggest your try to install it and reply to this thread again if you hit the same failure. https://msdn.microsoft.com/library/mt590809.aspx has the details on where to find Microsoft R Open 8.0.1 and Revolution R Enterprise 8.0.1.
If the issue persists RevoScaleR\rxLibs\x64\registerrext.log would have more details on the exact failure - do share that.
I was able to sort out the issue..It was because I was installing the SQL server on domain controller and ignored the warning while install, but then changing some rules and demoting it from Server Manager worked and the install was successful.
However I do know there may be some better solution to that as all the other user accounts got reset in the process.
I have an SSIS package that takes database backups and it runs fine in visual studio but when executed from a database job it fails with the following error. The part I can't understand is that 'GS\BOS-DBMONITOR$' isn't a user. 'BOS-DBMONITOR' is the server name.
Error:
Executed as user: NT Service\SQLSERVERAGENT. Microsoft (R) SQL Server Execute Package Utility Version 11.0.2100.60 for 64-bit Copyright (C) Microsoft Corporation. All rights reserved. Started: 10:58:03 AM Error: 2014-07-30 10:58:04.33 Code: 0xC0024104 Source: Back Up Database Task Description: The Execute method on the task returned error code 0x80131904 (Login failed for user 'GS\BOS-DBMONITOR$'.). The Execute method must succeed, and indicate the result using an "out" parameter. End Error DTExec: The package execution returned DTSER_FAILURE (1). Started: 10:58:03 AM Finished: 10:58:04 AM Elapsed: 0.593 seconds. The package execution failed. The step failed.
SQL Server Agent is the scheduler that comes with SQL Server. The first line of your error, Executed as user: NT Service\SQLSERVERAGENT specifies that your instance is running as the system user - not a "real" account. This machine is then trying to reach out to another computer and asks to log in to that SQL Server instance. SQL Server says "I'm not allowed to talk to strangers and GS\BOS-DBMONITOR$', you're strange."
How do you resolve it?
You need to let the foreign machines know about the account that's going to talk to them.
Use SQL Server Configuration Manager to change the service account from the the local account to a domain account MyDomain\NonExpiringAccount
Create a Credentialed user in the SQL Server instance on BOS-DBMONITOR and then assign them as a proxy for executing this, and any similar, SSIS packages. This allows the credentialed users' account to be presented to the foreign hosts. This has less potential impact on existing operations than changing the service account but requires more work
There's probably some voodoo you can work on all the servers you need to take a backup on to allow this user to log on but I wouldn't even go down that road. It's going to be work you have to perform on a per box basis and there's probably some security implications that go over my head
I've a recurring issue on a number of 2008 R1 servers. Replication stops completely, and any attempt to run any AD-related snap-ins or diagnostics fail.
For example:
C:\Windows\system32>dcdiag
Directory Server Diagnosis
Performing initial setup:
Trying to find home server...
Home Server = MYDC
Ldap search capabality attribute search failed on server MYDC, return
value = 81
Other tools also fail in the same manner:
C:\Windows\system32>repadmin /showreps
[d:\rtm\ds\ds\src\util\repadmin\repbind.c, 444] LDAP error 81 (Server Down) Win32 Err 58.
LDP can't connect to the server either:
ld = ldap_open("mydc", 389);
Error <0x51>: Fail to connect to mydc.
There are a couple of event log entries, but frankly I'm not sure if they are a cause or a symptom.
Event 1311:
The Knowledge Consistency Checker (KCC) has detected problems with the following directory partition.
Directory partition:
CN=Configuration,DC=ad,DC=mydomain,DC=co,DC=uk
Event 1566:
All directory servers in the following site that can replicate the directory partition over this transport are currently unavailable.
Site:
CN=MYSITE,CN=Sites,CN=Configuration,DC=ad,DC=mydomain,DC=co,DC=uk
Directory partition:
DC=ad,DC=mydomain,DC=co,DC=uk
Transport:
CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=ad,DC=mydomain,DC=co,DC=uk
A reboot always clears this up, and always after a month or two the same problem will crop up again on a different server. I've seen it on 5 different servers in different domains so far. Reboots are fine, but it always feels like a bit of a blunt instrument. I was hoping someone might have come across this before and be able to offer a fix.
thanks...
Is this related to: "All the TCP/IP ports that are in a TIME_WAIT status are not closed after 497 days from system startup in Windows Vista, in Windows 7, in Windows Server 2008 and in Windows Server 2008 R2" http://support.microsoft.com/kb/2553549