I'm trying to to the GoldenGate on Microsoft SQL Server. The thing is stopping me from moving forward with the implementation, there is a error I always get when trying to create the cdc Cleanup setup job file from the GGSCI. Only, please feel free to participate. the error bellow, keep in mind I have done all the requirements that appears in the error.
( Command: createJob
Neither the SQL Server Change Data Capture job nor Replication Log Reader Agent are found in database test1.
Ensure that supplemental logging is enabled for database 'test1' and that either the SQL Server Change Data Capture job or the Replication Log Reader Agent exists, if the database is Published for Transactional Replication, and re-run this program.
Also, ensure that the SQL Server login is a member of the sysadmin server role.)
I was expecting the createJob file to be created on the SSMS.
Related
I have two databases, one hosted in Azure SQL Server and another one which is local on my own SQL Server instance. Both of these I manage using SSMS.
I wanted to see how I can backup the Azure DB and restore it on the local instance (where I currently have other databases as well, generated and managed by Entity Framework) of my SQL Server. For that purpose, I followed this video.
What I basically did was to export a .bacpac file and restore it on my local instance by making a reference to "Import Data-Tier application".
Everything went well. The content was successfully restored and I was able to browse through it. When I finished with my testing I manually deleted this new database.
From that moment on, I can not access my other databases at all. When I try to do whatever SQL query on those I get the following error:
Attempt to retrieve data for object failed for Server '**********'. (Microsoft.SqlServer.Smo)
ADDITIONAL INFORMATION:
Failed to retrieve data for this request. (Microsoft.SqlServer.Management.Sdk.Sfc)
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
The connection is broken and recovery is not possible. The client driver attempted to recover the connection one or more times and all attempts failed. Increase the value of ConnectRetryCount to increase the number of recovery attempts. (Microsoft SQL Server, Error: 0)
Cannot open database "{THE NAME OF THE DB THAT I MANUALLY DELETED}" requested by the login. The login failed.
Login failed for user ******'. (Microsoft SQL Server, Error: 4060)
When using SQL Server Management Studio I try to query a DB created with "Single user" restrictions.
I log in by using SQL Credentials and "sa" user and by running sp_who2 command I double check nobody is connected to the DB, nevertheless when executing a query on a DB table, the system replies:
Database 'MyDB' is already open and can only have one user at a time.
I'd like to understand why I am experiencing this issue.
Can anybody help on this?
When you set a db in "single user" mode you can only open a single connection to the database (more info here).
So when you open SSMS to navigate through database objects you open the only permitted connection. After this any other operation that requires a new connection to the db will fail, for example creating a new query window to write a query.
From MS Docs:
When you start an instance of SQL Server in single-user mode, SQL Server Management Studio can connect to SQL Server. Object Explorer in Management Studio might fail because it requires more than one connection for some operations. To manage SQL Server in single-user mode, execute Transact-SQL statements by connecting only through the Query Editor in Management Studio, or use the sqlcmd utility.
The same happens on premise if you have the SQL Server agent running.
Another advice from MS Docs (if you are running SQL Server on premise):
Stop the SQL Server Agent service before connecting to an instance of SQL Server in single-user mode; otherwise, the SQL Server Agent service uses the connection, thereby blocking it.
I have create a SSIS package to extract data from oracle source and load data into a SQL Server database. It runs successfully when run it on SSIS.
But I'm getting an error when I runs the packages on SQL Server catalog.
Errors shown below
I also changed the execution type into 64 to 32 and try again. But same error occurred.
Kindly give solution for this.
Thanks.
Make sure you change it to 32bit in the package, and in the SQL Agent job if there is one. Also, as you are using ODBC, ensure you're using the 32bit ODBC driver and not the 64bit version - There are two different ODBC Data Source Administrators, one for each.
You could always change the job to OLE DB and see if that works correct just to make sure it's not a network/firewall issue.
Based on the error message, the issue should be related to account permissions.
As per my understanding, the account that log on the SQL Agent job
may doesn’t have permission to access the database server or SSIS
engine uses the design time values of a task until it actually runs a
task when DelayValidation is not set to true.
Note: If user has sysadmin permission doesn't means he has permissions to access the database server in ODBC Connection Manager.
Error message Fix:
Make sure the account in the job step is used to run the package has permissions to access the database server in ODBC Connection Manager. And change the DelayValidation property of your Data Flow Task to true and then re-ran the job.
I have an application which is accessing sql objects(stored procs/tables) etc which are defined under a schema 'A' for example A.my_stored_proc.
This application is working fine as intended when I connect it with the test server database. But, now as the client has asked to copy the db to into a local sql server dev edition for further enhancements.
I took backup of the db from the test server and restored it back to dev system. Now when I change the connection string of the application, the application throws an error saying that unable to located 'A.my_stored_proc'
I decided to manually test all the schema, user roles and rights against the test server which I found all are same.
For testing purpose I renamed the stored proc with 'dbo' schema and the application started working.
Can someone help me with this problem of schema with sql server 2008 r2?
On the test server, the user account under which you application works probably has A as its default schema, yet the procedure is called without schema name mentioned:
exec my_stored_proc;
On the dev server, your user account may have dbo as its default schema (or it might be the owner of the restored database, which in this particular case will lead to the same behaviour).
Consult with SQL Profiler traces to determine how procedure calls look like, exactly.
I am in the process of moving all our SharePoint DB's from a SQL 2005 server to a new 2008 server, and after moving the config database, everything seems ok, except when I click on "Timer Job Status" (under Central Admin > Operations > Global Configuration) I receive a "Unable to connect to database. Check database connection information and make sure the database server is running." error.
I get the following entries in the log regarding this:
12/03/2010
13:51:41.80
w3wp.exe
(0x09E0)
0x09AC
Windows SharePoint Services
General
8e2r
Medium
Possible mismatch
between the reported error with code =
0x8107053b and message: "Unable to
connect to database. Check database
connection information and make sure
the database server is running." and
the returned error with code
0x81020024.
12/03/2010
13:51:45.61
OWSTIMER.EXE
(0x0744)
0x0DD8
Windows SharePoint Services
Database
6f8e
Critical
SQL Database
'SP_Test_Config' on SQL Server
instance 'test-server' not found.
Additional error information from SQL
Server is included below. Cannot open
database "SP_Test_Config" requested by
the login. The login failed.
It should be noted that in order to ensure that it was no longer using the config database on the old server, I detached the original SP_Test_Config database in SQL Management Studio.
Obviously there are still references to the old SP_Test_Config database on the old 2005 server. How do I remove these references? Or, barring that, how do I move the config database in such a way that no references to the old 2005 server will remain?
Thank you in advance!
Not really an answer, but what we ended up doing (basically start from scratch using SQL Aliases):
First, create the SQL Server alias. This will make it so if you need to move the databases again in the future, you can just migrate all the databases to the new SQL Server, and change your SQL Server alias to point at that server. This should save you a lot of trouble and heartache in the future.
Run SQL Server Client Configuration Utility at: C:\Windows\System 32\cliconfig.exe.
Under the Alias tab, create a SQL Server Alias for the new SQL Server.
Now, recreate the farm.
Run stsadm -o preparetomove on all content DB's Backup all content DB's and copy to new SQL server
Remove all servers from farm using SharePoint Configuration Wizard
Recreate farm using SharePoint Configuration Wizard with the alias of the SQL Server you created above
Recreate all web apps with temp content DB's
Run stsadm -o deletecontentdb on all temp content databases created in step 4
Run stsadm -o addcontentdb using copied production databases as content database
Troubleshoot ad nauseum