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
Related
I am trying to use Copy Database Wizard to copy from my live server (shared hosting) to my local machine. Both the live and local servers are SQL 2008 R2.
I have used CDW for several years with perfect success when copying from a live SQL 2000 server to my local 2008 R2. But now that I have migrated my live database to SQL 2008 R2 the CDW is giving me this error:
Could not read metadata, possibly due to insufficient access rights.
I've learned that this error can be predicted before you even complete the CDW setup: On the page where the CDW asks you for your desired destination database name, it is SUPPOSED to populate the .mdf and .ldf files with their name-to-be and size (e.g. MB, GB).
But in my case these file names and sizes are not being shown (area is simply blank in the wizard) and then of course when I attempt to execute the package it gives me the error.
After much research I believe that reason for this error is due to the CDW requirement of "You must be a member of the sysadmin fixed server role on both the source and destination servers."
On my local server, my Windows Authentication login is listed as a Role Member for the sysadmin Server Role. However on my live server (keep in mind it is a shared SQL server with 250+ databases) the only Role Member listed is [sa].
Am I right in thinking that the only way to satisfy this requirement would be to add my specific SQL user to the live/source Server > Security > Server Roles > sysadmin role? I'm guessing that would never be done on a shared server right? Or is there some other way to make it work by messing with the specific database properties/users/roles?
I can't explain why CDW is working from the live SQL 2000 server and not the 2008 R2. I HOPE it is simply that something isn't set up right on the live database, but maybe it is due to changes that were made to SQL security over the years.
In case it matters, I must use the SMO method instead of detach/attach because it is a live database that I don't want to take down. Historically the CDW from SQL 2000 only takes 3 minutes with SMO method so speed isn't an issue anyway.
Here's my preference for a solution:
Find a way to get CDW to work, most likely by changing something on the live server. Is this possible? What would it be?
If that fails, then...
What about an idea of using CDW to create the package, but then going into to BIDS and manipulating something in the package to circumvent the sysadmin role requirement. (Does it really need the metadata? I don't need anything beside the actual data tables.) Is this possible?
UPDATE 6/14/2016: Editing a CDW package in BIDS won't work as it appears to simply use the .mdf and .ldf files, which of course I don't have access to on the shared server. I think an alternative is to use Import/Export Wizard to create a package, then edit in BIDS. The annoying part is that without access to metadata the Import/Export Wizard doesn't seem to be aware of Foreign Keys, and thus doesn't know what order to process the tables in.
If that fails, then...
Is there any other way to easily automate a daily copy from my live server to local machine? The reason I like CDW is because it is super simple to use (when it works), it can be scheduled to run daily as a SQL agent job, and requires no manual work on my part. Is there a "next best thing" if CDW can't be made to work?
You'd think that a very common scenario for all websites out there would be "how do I get a copy of my live database onto my local SQL server, daily, automatically"? But maybe I'm the weird one!
Another simple solution would be the Import/Export Wizard.
In SSMS right-click the database you want transferred and select 'Tasks' and then 'Export Data...'. It will open a wizard that is very similar to that of CDW. The difference here is that I could not find a sysadmin requirement to use it.
At the end it will give the option to run immediately and/or save the SSIS package. If you save the SSIS package (I prefer to save it to disk) you can then create a schedule via a SQL Agent job.
I'm making an Access database which will be used by multiple people, but I want to make it so that only certain people can edit,add,delete certain tables or fields so data isn't accidentally changed wrongly, and so the data is read-only to the people who don't have permission to edit. Is there any way to do this? Could I even just have access to certain tables or forms password protected?
Access used to have its own security model using an MDW file, but that went away sometime ago. So the short answer is "no". If you are able to introduce SQL Server into the equation, you could store the tables in SQL (or the free version SQL Express). SQL Server offers the security model you need, and you would then link the tables from SQL Server (ODBC) to Access. In this model, SQL Server is managing your data, and Access is your "front end". Once linked, access forms, reports, etc. really don't distinguish between local or attached tables, so all of your same Access skills apply. You can export the tables from Access to SQL using the export feature within Access, and choose ODBC. I'm not sure if you're comfortable doing this, but it's really not all that difficult.
If you do use SQL Server (or Express) you would configure the users and permissions on the tables themselves, using SQL Sever Management Studio. If a user that did not have update permissions, for example, tried to update a row from an Access form, Access would fire the statement at SQL Server which would return a permission error. You could also use SQL Security to implement Windows Authentication, and assign permission to network users. When the statements were fired at SQL Server, they would be authorized based on the users login (when they logged into the network). There would be no need for them to login again.
If you decide to go this way, let me know and I can guide you through it.
Apologies in advance for the long post, I am trying to be as clear as possible. Is there a way to disable a user / Windows AD group accessing a database via SQL Server Management Studio (SSMS)?
I have an desktop application that uses a SQL Server 2005 database. The application runs as the user logged onto the machine (unfortunately we can't change that otherwise this would be simple). The database is permissioned with groups (but it would apply to users as well) to give access to the appropriate schemas and objects that the user requires. The users have (and need) the ability to select, insert, update and delete data to complete their process.
The application carries out a series of validation and auditing steps on the user input to ensure they are entering decent data (and for some additional business processing). A user could open SSMS and make these changes through the query editor avoiding the application completely which is what we are trying to avoid. What I am looking for is a way to stop the users updating the database through any tool other than the application provided.
I have found a couple of similar posts (including How to disable SQL Server Management Studio for a user) but these don't quite cover this issue as they work on restricting user access or using different logins.
The only solution I can think of at the moment is to have a set of tables where the user data goes initially and then another process picks this up, runs the application processes on and then puts the data into the master / source tables. Then I could restrict user access to the master tables.
This appears to be a good scenario for an application role.
We're using SQL 2005 and want to identify individual users so we can trace their SQL for performance purposes, but we're finding it hard to unique identify who is who.
We're using SQL 2005 with connection pooling so every user has the same user in the Activity Monitor. Their NT user name doesn't appear to be set - maybe because we're using SQL Server users not domain users, we're also using Citrix so there is no individual IP address set. In this (very common) environement how do you identify an individual user?
If everyone is using the same username and coming from the same IP you won't be able to tell them apart. Unless you're using windows authentication MSSQL won't even be told what username on windows the user connecting has.
Have you considered changing your setup so that it uses Windows Authentication? It seems like the logical solution to the problem. Either that or setting up separate logins for everyone on SQL but that'd be duplicating your Active Directory user list...
In order to identify users in SQL Profiler, you need to provide that information to SQL Server in some way with each request or as part of the connection context. One way is to connect as different users, but if you have thousands of users, you would need thousands of accounts (SQL Auth or Windows Auth), and it becomes unmanageable quickly.
A much better way is to set the Application Name parameter in the connection string to be the name of the user. Once set, you can filter on that field in SQL Profiler: Data Source=.;Initial Catalog=Northwind;Integrated Security=SSPI;Application Name=RickNZ
The disadvantage with this approach is that connection pooling (which is enabled by default) only shares connections when the connection strings are byte-for-byte identical. So if you make them different per user, then you will have many more connections, with a resulting impact on performance. In a heavily multi-threaded environment, there's also a possibility that you could run out of available pooled connections. Even so, it might be useful for short-term debugging.
Solved the problem by tracking the Client Process Id in Sql Profiler. We can identify a particular user and their PID from within Citrix, or Task Manager in a normal setup. Then filter the output in Sql Profile by that PID.
This is brilliant when you're working on a DB but don't have access to the source of the application. Often standard reports need to be changed, SP's fixed etc, but if you don't know what's being run it's a needle in a haystack - use Sql Profile to track a user, capture the Sql, analyse/debug - fix move on.
I've seen lots of questions regarding moving data from Access to SQL Server, but I'd like to go the other route. Here's why:
I've been working on a sizable project with a SQL Server 2008 back-end and Access 2007 front-end. I'd like to be able to do some work on the front-end from home over the weekend, but I don't have access (VPN or otherwise) to SQL Server from there. I'd like to change my linked tables from SQL Server to another Access database file where I imported a snapshot of the SQL Server data. Then, come Monday morning, switch links back to SQL Server.
My problem is when I go to the Linked Table Manager and attempt to change the link, all I get is the ODBC Select Data Source dialog. If I try to link to an Access database, it tells me ODBC can't be used to link, import or export to another Access file.
One thought has occurred to me but I haven't tried yet; maybe someone could tell me if it's a good or bad idea: would I be able to delete the links, re-create them to the other Access file, and not lose any functionality in my queries/forms/reports?
My proposal would be to have SQLExpress (free) installed on your computer. You can then have all the data available on the machine. Create a publication on your main server, and have your local machine suscribe to this replication (if you don't need to save/synchronize the data changes done on your machine, you can stick to a basic 'snapshot' replication.)
You then just have to change your connection string from your network MSSQLSERVER to your localhost SQLEXPRESS server instance to have your app work.
If, for any reasons, you have to make changes to the database model while being off-line, you will then have to unsubscribe from the main server before making the changes on the local server. When you're back to the office, make sure that the same changes are done on the main server. My advice is to write your changes in T-SQL, save them in a file, and launch the file against the main server once you're back to work.
My opinion: don't work too much on weekends, or make sure your client is being billed for that.
For linking tables, you need to delete them and entirely and recreate them. Using the linked table manager to refresh ODBC links doesn't even work reliably when you're still using ODBC, as there is data cached in the table link definitions that doesn't get refreshed (e.g., if you change the number of columns in a SQL Server view, refreshing the table link with Linked Table Manager will update the number of columns, but you won't necessarily get an updateable view (assuming the original was updateable)).
But it's not clear whether or not you'll lose functionality or not. That all depends on how much of your application's logic is server-side, in SQL Server views and stored procedures. None of those will work if you link to a Jet back end.