I have hunted high and low for a fix to this, but everything is saying the same - a permissions error. The error given in the replication monitor clearly states it, but I can't see what I have got wrong.
The set-up (sorry for all the red lines in the screenshots - doing my best to disguise stuff ;) ):
Publisher and distributor are on SQL Server 2012 (11.0.3128)
Subscriber is a remote SQL Server 2008 (10.50.2550) - using a pull subscription
Windows user called SQL_Replication_Dev http://screencast.com/t/mz7ZX3fCW. This user exists on both servers with the same password
Login for SQL_Replication_Dev user created in both SQL Servers http://screencast.com/t/pGmnYQTZJm
The SQL_Replication_Dev user is mapped to the publishing DB and the distribution DB on the publisher and the subscriber DB on the subscriber. In all instances, has the db_owner role assigned http://screencast.com/t/2uVfHbkf4Q
The publication is using a network share and not the default folder http://screencast.com/t/OgnUcfBWlz
The SQL_Replication_Dev user has Full Control to the share http://screencast.com/t/d5s1ZZiW
The SQL_Replication_Dev user has Full Control to the underlying folder http://screencast.com/t/T6zJaku2Cob
The SQL_Replication_Dev user is on the Public Access List (PAL) for the publication http://screencast.com/t/BQ7EEh4vfc
Both the snapshot agent and the log reader agent are set as the SQL_Replication_Dev user http://screencast.com/t/iCpytv8yjL
The subscription distribution agent is set to use the SQL_Replication_Dev user and impersonate http://screencast.com/t/onD82Zd1gU0B
The subscription creates successfully and fires the publication snapshot agent to successfully create a snapshot in the folder share.
When looking at the replication monitor on the publisher, I then see the OS error 53 (http://screencast.com/t/4ORyBkQUYVRg) with the detail of The network path was not found. The path and file exist and are accessible to the SQL_Replication_Dev user (I tested this by logging into the server and navigating to the file via the share - is that good enough?).
Any ideas?
It looks like I did have everything configured correctly and I ended up creating a VPN connection between the publisher and subscriber. I could then set the Alternate Path in the subscriber properties to \\local_ip_address_of_publisher\ReplicationDev.
As the VPN connection was only needed for the initial snapshot I could then disconnect the VPN.
In the future, should I need to pass another snapshot, I can re-connect the VPN and make sure the Alternate Path in the subscriber properties are set to use the new local ip address of the publisher.
Related
I have a strange one for you. I'm maintaining several databases prior to a migration. One of them is a 2008R2 instance. This instance has multiple errors in the logs (the infrastructure has been poorly maintained), so I set up a bunch of alerts (16-25) and tried using Database Mail to send them. But the mail registry settings keep resetting and preventing it from working. I can't tell if someone is maliciously going in behind me and reverting the settings in the registry (this is possible in the poisonous environment I'm working in) or whether it's some kind of obscure problem.
Just to confirm... I've created the same alerts with the same mail settings on the 2017 instances that I'm also monitoring with no problem. Equally, on the 2008R2 instance, I can successfully set the Database Mail parameters, send myself a test email AND execute a job, sending a 'completed' email using the same Database Mail profile and user via an Operator.
Setting the parameters using xp_instance_regwrite or sp_set_sqlagent_properties didn't work either, although I realised early on that the parameters weren't sticking because of a lack of admin rights on the server, so I got the infrastructure guys to give me access. I then:
logged in to the server
shut down the Agent (it isn't doing anything at all)
configured the registry settings (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10_50.<instance>\SQLServerAgent\UseDatabaseMail = 1, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL10_50.<instance>\SQLServerAgent\DatabaseMailProfile = <my-mail-profile>)
restarted the Agent.
I then confirmed from SSMS that the 'Mail session' parameters (Enable mail profile, Mail system and Mail profile) were correctly set. A day later, the log is full of errors, I have no emails and all of the Agent properties are empty and greyed out!
Anyone seen this before?
I am having issues finding material on how to send a snapshot to a subscriber server to apply the snapshot at a later stage.
My situation: Publisher is based in SA. Subscriber is based in Germany. To deliver a 8GB database snapshot takes almost a day and I have heard if you zip the snapshot and copy it to the subscriber server via google drive or FTP you can speed the process up. Has anyone dealt with this ? Using SQL Server 2014 Merge rep.
There is an option to deliver Snapshots via FTP, check the docs:
How to: Deliver a Snapshot Through FTP (Replication Transact-SQL Programming)
To enable FTP snapshot delivery for a merge publication
At the Publisher on the publication database, execute sp_addmergepublication. Specify #publication, a value of true for #enabled_for_internet and appropriate values for the following parameters:
#ftp_address - the address of the FTP server used to deliver the snapshot.
(Optional) #ftp_port - the port used by the FTP server.
(Optional) #ftp_subdirectory - the subdirectory of the default FTP directory assigned to an FTP login. For example, if the FTP server root is \ftpserver\home and you want snapshots to be stored at \ftpserver\home\snapshots, specify \snapshots\ftp for #ftp_subdirectory (replication appends 'ftp' to the snapshot folder path when it creates snapshot files).
(Optional) #ftp_login - a login account used when connecting to the FTP server.
(Optional) #ftp_password - the password for the FTP login.
However, if you do in-depth search for replication and FTP at SO you will find that people report some problems with snapshot delivery over FTP, namely when setting up FTP delivery Publisher or Subscriber may request a direct link between each other during initialization, like in this question: SQL Server replication using FTP .
The generic problem is as listed here SQL Maintenance Cleanup Task Working but Not Deleting but no solutions applicable. Environment: Windows Server 2012R2, AD DS (with policies of course), RDSH/TS Licensing, 1C-server. The primary problem is SQL Server generating insane amount of events per backup plan run, recording a pair of 18456+17052 errors per file to delete. Errors are as follows:
17052: [Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed for user 'DOMAIN\mssql_srv'
18456: Reason: Could not find a login matching the name provided. [CLIENT: 192.168.x.x] (matches localhost)
Given that each pair of errors appears once per file to delete (there are about 6000 files already!), the algorithm looks like this:
First, backup plan task runs xp_delete_file, it enumerates all the files in target folder;
Second, each file is deleted by creating a separate connection to machine with service's credentials;
Each connection fails due to whatever restrictions default DC policy applies, generating the pair of events. Of course the file remains in place.
The workaround is of course assign file delete task to a local script run as system, for example, but the very reason of why does SQL server fail to delete a file remains unknown. Permissions have been checked and verified that both SQL Server Agent and SQL Server service accounts have full control to the folder.
It turned out that this "login missing" is not a Windows login, but rather SQL "login" which was not present for the service account. So I needed to create a "DOMAIN\mssql_srv" login in SSMS, give it "public" access rights and voila, files started to get deleted properly. The reason is explained in comment:
If it's T-SQL step and job owner is member of sysadmin server role, the step is executed under service account.
I'm working on logs. I want to reproduce a log in which the application fails to connect to the server.
Currently the commands I'm using are
db2 force applications all
This closes all the connections and then one by one I deactivate each database using
db2 deactivate db "database_name"
What happens is that it temporary blocks the connections and after a minute my application is able to create the connection again, due to which I am not able to regenerate the log. Any Ideas how can I do this?
What you are looking for is QUIESCE.
By default users can connect to a database. It becomes active and internal in-memory data structures are initialized. When the last connection closes, the database becomes inactive. Activating a database puts and leaves them initialized and "ready to use".
Quiescing the database puts them into an administrative state. Regular users cannot connect. You can quiesce a single database or the entire instance. See the docs for some options to manage access to quiesced instances. The following forces all users off the current database and keeps them away:
db2 quiesce db immediate
If you want to produce a connection error for an app, there are other options. Have you ever tried to connect to a non-estisting port, Db2 not listening on it? Or revoke connect privilege for that user trying to connect.
There are several testing strategies that can be used, they involve disrupting the network connection between client and server:
Alter the IP routing table on the client to route the DB2 server address to a non-existent subnet
Use the connection via a proxy software that can be turned off, there is a special proxy ToxiProxy, which was designed for the purpose of testing network disruptions
Pull the Ethernet cable from the client machine, observe then plug it back in (I've done this)
This has the advantage of not disabling the DB2 server for other testing in progress.
Getting the below error while trying to configure the backup source and destination are in different domain.
Executing the query "BACKUP LOG [project_management] TO DISK = N'\\nee..." failed with the following error:
"Cannot open backup device '\\qwerty.xyz.xyzinteractive.com\backup4\Teddy\TLogs\project_management_backup_2016_05_28_020039_7840447.trn'. Operating system error 1326(The user name or password is incorrect.). BACKUP LOG is terminating abnormally.".
Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
It is usually recommended that a backup is done local and then moved. Here is a link that I think is related to the topic. Are you using a service account that has appropriate privileges on both domains?
http://www.sqlservercentral.com/Forums/Topic842263-357-1.aspx
Make sure that the account that's running the MSSQLSERVER service for your instance has access to the network share.
If you're running on a domain and the instance is running as the computer's SYSTEM account, then you'll want to grant access to the computer account instead of a user.
If you're not on a domain or are saving the file across domains that aren't trusted and the instance is running as the computer's SYSTEM account... well, then the easiest way to do it is to change the account to a real service account.