We have a server application sitting on 'server A' that has its own database split up in to multiple database files. We have multiple users that dial in via remote desktop to 'server B' and then launch the client version of this application that accesses the database files stored on 'server A'.
Our problem is that users don't always log off properly from 'server B' - they just click the 'X' to disconnect.
This is causing the database files to be left open on 'server A' which causes us issues with licensing (only so many number of database files can be open at once). So if we were to look on 'server A' under Computer Management > Shared Folders > Open Files, we would see the database files still open even though the user is not logged in remotely to 'server B'.
Is there a way to automatically close the open files associated to the user if they disconnect or log off from their session?
We have set the remote server (server B) to end a disconnected session after 1 minute - is that enough?
Related
My backup job in Maintenance Plans has an error (Please check error encountered below) which already 3 days straight.
Job configured as follows:
(Step 1): Backup the DBs to a shared folder of Server A
(Step 2): If Step 1 Success, It will copy the backups from Server A to the shared folder of Server B.
As per error from event viewer the error stopped at Step 1. I still don't know where the error came from but as per checking the backup created in Server A are all complete which is weird.
Here are my isolation:
The shared folder of Server A and Server B are accessible (tried also the account of SQL services job as a user in windows)
Here is the error found in event viewer:
1. BackupIoRequest::ReportIoError: read failure on backup device '\\\Server_A\Shared Folder\Database.bak'. Operating system error 64(The specified network name is no longer available.)."
2. "Package "Backup Databases Directly to Server_A Shared Folder" failed."
3. "SQL Server Scheduled Job 'Backup Databases Directly to Server_A Shared Folder.Subplan_1' (0xD20650B4C8A10F41A130C734D053DB63) - Status: Failed - Invoked on: 2019-08-24 00:00:00 - Message: The job failed. The Job was invoked by Schedule 89 (Backup Databases Directly to Server_A Shared Folder.Subplan_1). The last step to run was step 1 (Subplan_1).
As per error from event viewer the error stopped at Step 1. I still don't know where the error came from
Usually, when you checking it form SQL Agent history, expand the job and select step 1 so that we can see what causing the that error, information must be printed in message section (bottom):
"BackupIoRequest::ReportIoError: read failure on backup device '\Server_A\Shared Folder\Database.bak'. Operating system error 64(The specified network name is no longer available.)
In this case, there must be something wrong with path (wrong spelled), or the SQL Server service account (not only SQL Agent service account) doesn't have permissions on the shared folder.
When you say SERVER-A and SERVER-B can access shared folder, you might have verified logging in at the server with particular user, so that logged-in user got the permissions on the shared folder, as long as same user is service account user of SQL Server then we can assume, SQL Server really have access to shared folder.
Hope, fixing permission issues would resolve the error caused.
However, do you have any issues to directly create a backup on SERVER-B shared folder as i feel like we are doing unnecessary additional step.
P.s: I personally, recommend to use custom script for maintenance tasks, especially for backups. My answer at DBA.SE might helpful in your case for better backup strategy
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.
I have 2 nodes in a SQL Server 2008 R2 Cluster that I inherited. Looking at the 'Failover Cluster Manager', under 'Services and applications', I see 13 SQL Server instances. It, and all of its resources, are owned by one node. My thought is that they should be evenly distributed between the 2 servers.
When I try to move one of these instances to the other node, everything comes back online with the exception of 'SQL Server (Name)' under Other Resources. It says 'Failed'. When I try to manually bring it online, I get an error message
The operation has failed. An error occurred while attempting to bring the resource 'SQL Server (NAME)' online.
Under see details, it says
Error Code: 0X8007139a The cluster resource could not be brought online by the resource monitor
In system event viewer on the target server, I see the events 1069 and 1205, which both basically say "cluster service or application failed". Under the folder 'FailoverClustering-Manager' > Admin, I see event 4683 - The error was 'The IP Address 10.10.9.150' is already used'. Not sure why that would make SQL Server fail, but none of the other resources. For all the 'Failover' folders in Event Viewer, none of the 'Diagnostic' logs have any events.
Generated and checked the cluster.log file on both servers. For some reason, the time is off in that log, so it's hard for me to pinpoint when the errors below occurred:
[RES] Physical Disk: Resource SQL Network Name (CSDBNAME) is not in online or pending state.
[RES] SQL Server : ResUtilSetResourceServiceEnvironment: Failed to open service key for MSSQL$NAME, error = 2.
[RES] SQL Server : [sqsrvres] OnlineThread: ResUtilSetResourceServiceEnvironment failed (status cb)
[RES] SQL Server : [sqsrvres] OnlineThread: Error cb bringing resource online.
[RHS] Online for resource SQL Server (NAME) failed.
[RCM] rcm::RcmResource::HandleFailure: (SQL Server (NAME))
That's all the log info I can find. Any other ideas to successfully move resources from one node to the other?
First
For the cluster disk you can see in "Disk manager" if it is "reserved".
Try to add a disk cluster like you have done before and see if it move.
Second
For de IP Address, you can try to stop this resource and test a ping from node 1 and form node 2 to check if this IP exist or not
Third
Check in Active Directory, to see if it didn't have a problem with security autorisation in the failover ressources
Check if cluster Name had some autorisation in the network name service
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.
I have the following set-up causing issues:
MDB or MDE frontend in msaccess 2003 (11.6566.8221) SP2
-- run from server share folder or C:\Development
Microsoft SQL Server Express Edition with Advanced Services (9.00.5000.00)
Operating System ("server"): Microsoft Windows NT 5.1 (2600) = Windows XP
I run and debug the MDB and MDE on my development machine (which is the same as the "server") connecting to it using the same Linked Table connections derived from a file DSN.
I take and run the MDB or MDE to another client (mixed client enviroment in the hospital) and it hangs and complains about odbc--connection error on the first call to a table (which is a DLookup in the start up code)
I stop the code, unhide the Database window, and
I re-link all the tables using the File DSN I am
carrying around on my USB drive (same as on the development machine)
Note: the same setting in my File DSN re-creating as a new FileDNS on client = success)
browing all the tables (opening them in Table view from Access Table tab) = works
running all the forms again = works
system runs like normal
** NOW **
I save the MDB again, close the MDB (leaving ACCESS open), open the MDB again
- everything works fine
I now close Access completely (no longer running), open access, and open the mdb
-- error now happens, and any attemp to view a linked table I get the same error
Posible hint: The error message is unusual:
Runtime Error '3151'
ODBC--connection to 'SqlServerSAH0048645' failed
The following does work
- open the file with Startup option set to open "UserValidate" form
- in OnLoad event call ResetDefaultconnections (using down DNSless code I found)
- reset all TableDefs.connection strings to:
strConnectionString = "ODBC;DRIVER={SQLServer} ;Description=RAHCC_DB; SERVER=tcp:10.19.54.64,1500; UID=RAHCC_User; PWD=XXXXXXx; APP=MSACCESS; WSID=SAH0034510; DATABASE=RAHCC_DB"
delete and then add new tabledef records for each linked table
continue to open the form ---> everthing seems to work.
BUT.. as soon as I close access, and re-open --> doesn't work again.
Note
- I am restricted to what I have (is Sql Server is installed on all clients)
- I am restricted to a connection using the Sql Server driver
- I am using Sql Server authorisation
cheers,
JonHD