Is there any way to keep the backups separated?
Assuming that CommVault is also taking log backups, and can't be configured to take COPY_ONLY backups, you will only be able to restore FULL backups, and not apply differentials or log backups.
I am an Oracle DBA by trade) . Is that like an oracle Image copy backup ?
No. Normally a FULL backup will write ...
Differential backups are attached to the Full. If your other backup tool takes a full, it's normal that you cannot restore your diff without that full.
You should not use 2 different backup tool in parallel. If you really need to, then you can check if it's possible to specify the "copy_only" option for the backup in CommVault (so your native ...
Both the log send queue and redo queue can be found in sys.sys.dm_hadr_database_replica_states (docs), and also available using the SQLServer:Database Replica Perfmon counters (docs).
With Perfmon counters, you'll need to collect counters individually on each replica. Each replica knows about the Send/Redo(recovery) queue affecting that replica ...
The difference between local time and UTC time can be reliably calculated by looking at the difference between GETDATE() and GETUTCDATE(), assuming the server operating system is configured in whatever the desired "local" time is (i.e. if local time for you is Central European Time, then the server must be configured to be in Central European Time)....
SQL Server 2019 Windows containers are still in preview as of this writing. If you don't join the Early Adopter program, you can create a custom image by starting with a Windows Server Core base image and then install SQL Server 2019 (and optionally CUs) to create a custom image.
The build is most easily done on a machine with internet connectivity to pull ...
To the best of my knowledge, this is a hard rule in SQL Server. See for instance here: https://docs.microsoft.com/en-us/sql/ssms/agent/job-step-properties-new-job-step-advanced-page.
You can of course wish for a change in Agent security architecture, but I don't hold my breath for that to happen: https://feedback.azure.com/forums/908035-sql-server.
In the ...
Is this what you're looking for?
At the end of this blog Bob Ward says:
There are also some factors that can affect whether these changes actually help make your execution of CHECKDB faster:
Spreading files across disks – As with the general performance of ...
Maybe this one is relevant?
If I'm understanding it correctly, the article describes how the files (named streams prior to 2014) for the CHECKDB hidden internal database snapshot are created using the paths for the database data file(s). If the database has multiple data files spread over multiple volumes, the snapshot files (and hence their IO) ...
Rolling back an in place upgrade on a distributor is pretty similar to any failed in place upgrade. Which is to say, it's not usually quick and simple.
If the failure is during the install, you'll need to uninstall, reinstall, and revert to backups. With replication, msdb is very important, in addition to the distribution database, in order to restore all of ...
I don't think you'll find a way prior to 2016.
As of 2016, you can use the DMV sys.dm_db_log_info instead. In fact, your script does just that, checks for the version and uses one or the other command (the other of course being DBCC LOGINFO, which requires sysadmin).
For sys.dm_db_log_info you can just GRANT VIEW SERVER STATE permission.
What you are ReComputing ? and how you are Recomputing is not so clear ?
Advice to Avoid DISTINCT,UNION is already given.
I don't know what is the purpose of CROSS JOIN in your query and whether it can be avoided or not.
If CROSS JOIN is producing not a row more not a row less then it will not hurt performance.
Instead of querying FROM Document again and ...
The amount of data we are talking about here is not nearly enough to be this big of a problem. Odds are, a bit of optimization will do you quite nicely.
So, opening your query plan, as I go along:
Fix your WHERE clauses. Your current query forces table scans just about everywhere because you use functions. IsNull(COALESCE(linkedlot.IsPrivate, c.IsPrivate), ...
Although @Mo64's answer pointed me in the right direction, the issue is with the alert threshold of the secondary server, not the copy speed on the primary. The link provided by Mo64 did also link to the description of the secondary metadata table in msdb. I used those docs to concoct this update statement:
update the relevant row and column (backup_threshold (in minutes)) in the log shipping config table
If we look at the actual plan, the current query is reading too much data from the table to be updated. This is from the index seek on BoxTrackInfo:
This is an index seek on btid for each row that comes out of the scan of BlueTrackEvents. Update locks are acquired as btStatusID is checked to see if the row qualifies for the update. Only 1,401 rows ...
The only way to efficiently maintain a large cache of relationships like this is to not recompute the whole lot. Unfortunately partial updates, and reliably knowing what to update, can be complex depending on the requirements dictated by your business rules.
compute a hash for all the records in the tables involved
This is your first (and possibly biggest) ...
Yes, this is working as designed.
Looking at the docs:
SQL Server Agent reads the application log and compares events written there to alerts that you have defined.
The mechanism that is used for SQL Agent alerting is to read the log. Thus, if it's not logged, there is no alert.
Instead, you can use Extended Events to capture errors, even if they aren't ...
I faced then same problem, move thousand of heaps to a different filegroup.
The way i accomplished the task was CI index create and drop.
If you are fine with this technique below is the script.
It enumerates heaps in a filegroup and generate the script for index create and drop.
Run in the context of your database, possibile during maintenance window.
Couple of weeks ago we patched to SQL2017 CU 22 in our all test and staging environment to begin with.
So far we did not see any issues. We were planning to go in prod by this weekend but from SQL 2019 CU 7 horror we prefer to make a change in our process to push updates to prod by at least a month now.
So as of now we have not see any issues on 2017. As a ...