SQLServer replication between windows and linux server [migrated] - sql-server

This question was migrated from Stack Overflow because it can be answered on Database Administrators Stack Exchange.
Migrated 12 days ago.
I'm trying to setup a replication between a SQLServer 2016 in a windows server and a SQLServer 2019 host in linux server.
The linux instance run in a kubernetes setup and the docker image is simcube/mssqlserver-2019.
I set my publication as a transactional pull publication and the distribution default snapshot folder is D:\Data\ReplicationData.
When I check the synchronization status, I have this error:
The process could not read file 'D:\Data\ReplicationData\unc\SUST5050_CORPORATIF PROD_WEBSITE\20230207080810\UtilisationExplosee2_100.pre' due to OS error 5.
Do you have any clues on what could be the problem?
I verified that the Agent process account and the subscriber connection credentials were correct.
I openned port 137, 138, 139, 445, 1433 on the linux server.

The process could not read file 'D:\Data\ReplicationData\unc\SUST5050_CORPORATIF PROD_WEBSITE\20230207080810\UtilisationExplosee2_100.pre' due to OS error 5.
This is indicative of a permissions issue on that folder share. Please make sure your D:\Data\ReplicationData folder (and all subfolders / files) are provisioned with Read / Write access to the account used in your replication topology.

Related

Postgresql abnormal database system shutdown

I am very new to both aws ec2 instances and postgresql. I was able to get a database up and working for a web application mainly using the phppgadmin interface. Today I was working on my web app and was abruptly disconnected from the database. In my web app I got the error " pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: Connection refused\n Is the server running on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port 5432?" I now can't log in to phppg admin or connect to postgres from my ec2 instance command line. After inspecting the log file at /var/log/postgresql/postgresql-12-main.log I am seeing the error "FATAL: could not open file "global/pg_filenode.map": Permission denied" followed by "LOG: abnormal database system shutdown" I have my pg_hba.conf and postgresql.conf files are configured correctly as I have been doing work on this database for a few days now. Any help would be appreciated.
You or something else wrecked your PostgreSQL installation by changing permissions on or ownership of PostgreSQL files. On Windows and its interesting concepts of file locking, I'd suspect an anti-virus program, but you seem to be running some kind of Unix. Little more can be said with the little information in the question.

How do you configure the SQL Server Network Configuration protocols in a MSSQL Express Docker container on a Linux server?

The gist of the issue is that I am trying to connect to a MSSQL Express Docker container, living on a RHEL 7 server from my local Windows 10 machine using Microsoft SQL Server Management Studio. It is successfully connecting to the RHEL 7 server IP address and port (1433), using the username/password that was created for the container. However, it is throwing out an error that, after countless hours scouring Google, people have referenced back to needing to enable TCP/IP. This is easy in the Windows GUI. Not so much in a Linux environment.
The error message from SSMS:
A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 0 - The specified network name is no longer available.) (Microsoft SQL Server, Error: 64) -> The specified network name is no longer available
I know how to do this in the Windows environment:
Run SQL Server Configuration Manager
Expand SQL Server Network Configuration
Select Properties for Protocols for MSSQLSERVER
Enable TCP/IP
I have also figured out how to use mssql-conf to modify various attributes in mssql.conf, which is where this change will take place. The issue is that I want to enable TCP/IP, but I am not seeing that option under the /opt/mssql/bin/mssql-conf list | more.
Any suggestions?
For reference, these are the parameters you can use with mssql-conf (the equivalent of SQL Server Configuration Manager on Linux).
control.alternatewritethrough Enable optimized write through flush for O_DSYN
C requests
control.hestacksize Host extension stack size in KB
control.stoponguestprocessfault Stops the process if any guest process reports
unhandled exception
control.writethrough Use O_DSYNC for file flag write through request
s
coredump.captureminiandfull Capture both mini and full core dumps
coredump.coredumptype Core dump type to capture: mini, miniplus, filt
ered, full
distributedtransaction.allowonlysecurerpccalls Configure secure only rpc calls for distributed
transactions
distributedtransaction.fallbacktounsecurerpcifnecessary Configure security only rpc calls for distribut
ed transactions
distributedtransaction.maxlogsize DTC log file size in MB. Default is 64MB
distributedtransaction.memorybuffersize Circular buffer size in which traces are stored
. This size is in MB and default is 10MB
distributedtransaction.servertcpport MSDTC rpc server port
distributedtransaction.trace_cm Traces in the connection manager
distributedtransaction.trace_contact Traces the contact pool and contacts
distributedtransaction.trace_gateway Traces Gateway source
distributedtransaction.trace_log Log tracing
distributedtransaction.trace_misc Traces that cannot be categorized into the othe
r categories
distributedtransaction.trace_proxy Traces that are generated in the MSDTC proxy
distributedtransaction.trace_svc Traces service and .exe file startup
distributedtransaction.trace_trace The trace infrastructure itself
distributedtransaction.trace_util Traces utility routines that are called from mu
ltiple locations
distributedtransaction.trace_xa XA Transaction Manager (XATM) tracing source
distributedtransaction.tracefilepath Folder in which trace files should be stored
distributedtransaction.turnoffrpcsecurity Enable or disable RPC security for distributed
transactions
filelocation.defaultbackupdir Default directory for backup files
filelocation.defaultdatadir Default directory for data files
filelocation.defaultdumpdir Default directory for crash dump files
filelocation.defaultlogdir Default directory for log files
filelocation.errorlogfile Error log file location
filelocation.masterdatafile Master database data file location
filelocation.masterlogfile Master database log file location
hadr.hadrenabled Allow SQL Server to use availability groups for
high availability and disaster recovery
language.lcid Locale identifier for SQL Server to use (e.g. 1
033 for US - English)
memory.memorylimitmb SQL Server memory limit (megabytes)
network.disablesssd Disable querying SSSD for AD account informatio
n and default to LDAP calls
network.enablekdcfromkrb5conf Enable looking up KDC information from krb5.con
f
network.forceencryption Force encryption of incoming client connections
network.forcesecureldap Force using LDAPS to contact domain controller
network.ipaddress IP address for incoming connections
network.kerberoskeytabfile Kerberos keytab file location
network.privilegedadaccount Privileged AD user to use for AD authentication
network.rpcport TCP port for Rpc endpoint mapper
network.tcpport TCP port for incoming connections
network.tlscert Path to certificate file for encrypting incomin
g client connections
network.tlsciphers TLS ciphers allowed for encrypted incoming clie
nt connections
network.tlskey Path to private key file for encrypting incomin
g client connections
network.tlsprotocols TLS protocol versions allowed for encrypted inc
oming client connections
sqlagent.databasemailprofile SQL Agent Database Mail profile name
sqlagent.enabled Enable or disable SQLAgent
sqlagent.errorlogfile SQL Agent log file path
sqlagent.errorlogginglevel SQL Agent logging level bitmask - 1=Errors, 2=W
arnings, 4=Info
telemetry.customerfeedback Telemetry status
telemetry.userrequestedlocalauditdirectory Directory for telemetry local audit cache
Also for reference, this is the only thing in the mssql.conf file. If something is there be default, I have no way of knowing it, because all I have to go off of is what's listed in this file:
[sqlagent] enabled = true

SQL Server connection error - Data source name not found and no default driver specified

When running a third party developed EXE located on the shared folder of Windows Server 2012 R2, which connects to SQL Server 2012 Express, the following error occurs:
[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified.
When the EXE is 'Run as Administrator' it works fine. But this application interfaces with Office and other programs, so running as administrator puts it into protected memory space that conflicts with other applications. I need it to open normally, as before.
This error has only occurred since client workstations had Windows 10 1803 and higher installed. Bizarrely, workstations that updated to 1803 and higher are unaffected. Only on new installs has the problem occurred.
There was something about 1803 which changed the network stack, client side, that caused a lot of different problems for SQL connections and I have seen a hundred different solutions but none work in our case.
Client machines connect to Server 2012 using domain login accounts. Each domain user account is given local admin rights and full administrator rights. The client workstations are normal Windows 10 Pro install with ESET antivirus. When testing the ODBC connection, it is successful and works. Only when running the program does the error occur.
On the Server side I have.... Enabled Named Pipes, Disabled and Removed SMB1.0
So what is going on here? Why from 1803 on must we run as administrator to get a connection?
Data source name not found
I would first check if the Data Source is defined below "User" or "System" .
If it is User for the Administrator there is no way to access it except if the user previously run it by using the option "Run with administrative permission"
In case it is defined as System DSN likely the user after 1803 does not have enough permission to access the registry where it is stored, so this is the most probable case scenario.
The optimal is to see if you can modify your connection using OLE or something else rather than ODBC so it can be DNSless, eventually try to define a DSN with the same name below User with the same user who is running it that should be read before the framework is going to look for the same DSN name under the system / local machine registry section.
To troubleshoot deeper registry permission issues you can use the former Sysinternals procmon downloadable from MS website, this must executed using "Run with administrative permission"

Cannot open backup device '\\Servername\backup$\Database\databasename.bak'. Operating system error 53(The network path was not found.)

I used
Microsoft SQL Server 2012 (SP3) (KB3072779) - 11.0.6020.0 (X64)
Standard Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1)
1)I have an Maintenance Plan, which backup sql database in a network share.
2) Backup execute every day in 17:00
3) Sql server services and SQL Agent services running domain accounts
Domain\SQLServer
4) Remote Network share : \\Servername\backup$\Database\databasename.bak
5) Network path "backup$" have a full rights domain accounts
Domain\SQLServer and path "Database" have a full rights domain accounts
Domain\SQLServer.
6) But i get this error
Cannot open backup device '\\Servername\backup$\Database\databasename.bak'. Operating system error 53(The network path was not found.).
7) I can't understand what could be the problem.
8) I noticed one interesting moment. When i forced update sql server in a sql management studio and run manually maintenance plan, backup run success and databasename.bak appears on remote network share, but when i start maintenance plan automatically, plan success work 2-3 days but then history again Cannot open backup device '\\Servername\backup$\Database\databasename.bak'. Operating system error 53(The network path was not found.). I have no idea what it could be.
Hey guys I have solved this problem.
The problem was in Kaspersky Endpoint Security 10. I have stopped module "protection from network attacks" and backup have success to remote network share and "lanman service" working normal. Thanks for the wireshark. Somehow module "protection from network attacks" blocked correct working lanman service and blocked 445 port which use lanman service.

Path Not Found - BULK Insert into SQL Server via VMWare Fusion

My machine is a macbook pro. However, my company's data is in SQL Server. In order to access it, I need to use VMWare Fusion to run SQL Server Management Studio 2008 on Windows XP.
When I attempt to run a bulk import (via instructions from SQLAuthority.com), I get this error:
Msg 4861, Level 16, State 1, Line 1
Cannot bulk load because the file "H:\test.CSV" could not be opened. Operating system error code 3(The system cannot find the path specified.).
I am dealing with 3 different file locations, but none of them work.
My Mac storage - "/Users/Admin/Documents/test.CSV"
My Windows XP storage - My "C:" drive. "C:\test.CSV"
My company's network location - Mapped to the "H:" drive via Windows XP. "H:\test.CSV"
Changing the script to point to all these locations provides the same error message.
Any thoughts on how to overcome this? Presently, my only alternative is to use the SQL Server Import/Export tool, but it takes a while to setup every import. Script is faster.
A bulk insert runs from the server. So it can't reach your local disk.
The server uses the account that the "SQL Server" Windows service uses. That account typically does not have any mapped drives.
Try using a full name, like:
\\server\share\test.csv
Possible other solutions:
Ask a DBA to open a share on the server for imports
Ask a DBA to place the CSV file on a disk on the server
Ask the DBA which account is used for the SQL Server service. If it's a domain account, you can give the account read rights on a network share.
I experienced this error, too.
In my case the solution was to change the path in T-SQL from a share to the actual directory: \\server\share$\file -> drive:\folder\file.
The culprit ended up being a problem with VMWare, which caused the server to have trouble authenticating with some network shares.

Resources