We are running Azure SQL Managed Instance 2019 and need to change the max job history settings in SQL Server agent.
On a non-Azure-hosted SQL Server, it can be done by going to SQL Server Agent Properties, the History tab.
But, this tab is not available in Azure SQL Managed Instance.
Is there a different way (via SQL or Azure portal or some other way) to change the max history settings on Azure SQL Managed Instance?
Initially I thought maybe this was just SSMS conditionally not showing that page because of a specific incompatibility:
On your desktop, change the setting, then hit the Script button. It will produce the T-SQL that this pointy-clicky dialog would have issued if you pressed OK. Now tweak it and try to run that on MI. It might be that you don't have the ability to change the setting (I haven't tried it), but at least you'll get a useful error message instead of "the pointy-clicky dialog isn't there."
But it seems this is by design, and changing these properties is not possible on the current version of Managed Instance (because they are, for some reason, still stored in the registry). From T-SQL differences between SQL Server & Azure SQL Managed Instance:
SQL Server Agent settings are read only. The procedure sp_set_agent_properties isn't supported in SQL Managed Instance.
And from Automate management tasks using SQL Agent jobs in Azure SQL Managed Instance:
SQL Managed Instance currently doesn't allow you to change any SQL Agent properties because they are stored in the underlying registry values. This means options for adjusting the Agent retention policy for job history records are fixed at the default of 1000 total records and max 100 history records per job.
You can send feedback through your account rep to express a business need for this functionality, but I wonder if you can manage this retention yourself in some way:
if you want to store less history, you should be able to manually delete rows from msdb.dbo.sysjobhistory to purge data more aggressively than the defaults (also, looks like manually calling sp_purge_jobhistory is supported in MI).
if you want to store more history, you can archive rows from sysjobhistory into your own tables that you can use to review, however these rows won't get pulled into the Agent UIs. I suppose you could insert older data back into sysjobhistory frequently enough that it is available to UIs (until it gets deleted again), but that could get messy and hard to manage.
I have written about managing Agent history more effectively than the default behaviors and limits allow, but it probably isn't going to solve your entire issue:
Manage SQL Server Agent History More Effectively
We have a SQL Server database that is hosted by a 3rd party. We have access to the backup files of that SQL Server database which we grab daily and restore to an "in-house" SQL Server for the purpose of creating reports and looking at the data without the chance of affecting the "live" data on the hosted server.
At the moment our restore process only allows us to access day old data, but we would like to increase the frequency of backup/restore processes so our "sandbox" database is more up to date, like maybe 2 or 3 hours old. One issue is that during the restore process everyone has to be out of the database so restoring every couple of hours might be cumbersome.
Is it possible to setup a 3rd SQL Server for the "sandbox" database to replicate to so that when we restore the data to it, that data will then replicate to the "user" database.
Is there a better way to get the data from the actual production server?
I've got a large database of around 120GB that was migrated to temporary server a couple of weeks ago in a hurry. I should add I'm not a DBA by any stretch.
Unfortunately it was SQL 2017 rather than the original 2016 which has then caused an issue when trying to migrate it back to 2016. i.e it's not possible to migrate with drop/reattach or backup/restore.
I've tried scripting the database but as a couple of tables are 80% the size of the database it fails to import.
I've also tried APEX SQL Data Diff but I get "transaction log full" fail messages, even though transaction logging is set to simple.
Does anyone have any ideas on how to migrate this database back to the original server in a timely fashion.
You can use SSIS or Export/Import wizard in SSMS to transfer the data from the old database to the new one. Or to export the data from 2017 to flat files and use bulk insert or bcp to import these filat files into 2016.
We have an firebird database connected to our access control system and then a separate web app that I developed for our time and attendance using sql server 2005 as the data source.
I wanted to use entity framework to connect to the firebird database to access data like users, transactions, sites, etc. As this method is very complicated getting the connection using firebird .NET provider the other option I have is creating a sort of replication (Mirror) from the firebird database to sql server.
I have done this with a DTS previously (Selecting the data and then inserting it) and it worked fine but had many manual processes involved in getting the data and updates made it difficult.
Is there a simpler way to do this or any suggestions would be appreciated.
Unfortunately you need to track what to replicate at the data level. If you are only pushing it to the MS SQL database you could use a modified timestamp, or a record version field (create a generator, set a trigger to update the version field upon update) to reduce what you select. Another popular option is to update a field to current_transaction, but if you do a restore you will start counting from 0.
If you are sending data both ways it gets more complicated -- you need to have conflict resolution. You could look at something like the Microsoft Sync Framework which can use the methods above.
I have to move an entire database from a SQL Server 2008 machine to a SQL Server 2000 machine.
I created a backup using Management Studio 2008, copied it to the hard drive of the 2000 box, and from withing Management Studio 2008, I choose Restore Database to the 2000 box.
I get an error message stating, "The media family on device ... is incorrectly formed. SQL Server cannot restore this media family".
If I use Enterprise Manager 2000 I get the same error.
Is there a way to move a whole database from the newer SQL server to the older?
The only thing I can think of is to recreate the whole structure and then copy data from a live database. So, create scripts that will create the tables, views, and sp's, and then create scripts to copy the data from the existing database.
As others already said there is no default way to do this. It’s just not supported. Here are more extensive details on how to do this properly and avoid any migration issues.
You need to generate scripts for structure and data and then execute these on SQL 2000 (like others already said) but there are couple things to take into account.
Generate scripts in SSMS
Make sure to check option for scripting data for SQL 2000 to avoid issues when trying to create something like geography type column on SQL 2000.
Make sure to review execution order of scripts to avoid dependency based errors
This is a great option for small to medium size databases and requires some knowledge of SQL Server (dependencies, differences between versions and such)
Third party tools
Idea is to use third party database comparison tools such as ApexSQL Diff or Data Diff
Good side is that these will take care of script execution and differences between versions
Not so good is the fact that you’ll need to pay for these after trial ends
I’ve used these two tools successfully but you can’t go wrong with any other tool on the market. Here is a list of other tools in this category.
you can't move backups from a newer version to an older, in that case you can script your database, execute it in the 2000 box, then you can use the standard data transfer to transfer any data you want
Provided you have a network connection between the machines use SSIS. Much easier and a lot less messing around.
You can use Script Generator for your database and then select in the properties form : General-> Script for server version : SQL Server 2000.
The script generator will show you things which not compatible with your server version.
I've heard you can only do it by generating the SQL statement dump from the DB administrator tool and re-running those queries on the target older database.
You can generate a script that will recreate all the objects and transfer all the data...as long as everything in the db is valid in SQL 2000. So no ROW_NUMBER(), no PARTITION, no CTEs, no datetime2, hierarchy or several other field types, no EXECUTE AS, and lots of other goodness. Basically, there's a pretty good chance it's not possible unless your db is pretty basic.
We got a similar situation. A very low-tech but handy solution is:
backup and truncate the tables in SQL 2000.
create a LINKED server in SQL 2008, pointing to SQL 2000
run a select query at sysobjects to generate a query script for insert into LINKED SERVER.table select * from table
execute query script.