3
DTU is a blended measure of CPU, memory, and data I/O and transaction log I/O…. This means that there is no definitive measure of equating x DTU = x CPU, X Memory etc.
Since, you have Premium P11 tier - this means that you have 1750 DTUs. Based on this blog post - By Andy Mallon, below is the CPU-to-DTU-to-Service Tier mapping :
+--------------+------+-----...
3
If each instance and the application(s) using it are just relying on the database engine, then upgrading each instance should not affect the others at all unless a reboot is needed (and usually for a SQL patch or service pack only restarting the relevant SQL services is needed, not a full machine reboot).
See https://docs.microsoft.com/en-us/sql/sql-server/...
3
Firstly, it always better to test patches in DEV environment before applying on Production.
To answer, there won't be downtime/interruption for Instance 3 while patching/removing path on Instance 1, all you need select particular instance during the wizard or command line as follows:
KBXXXX.exe /qs /IAcceptSQLServerLicenseTerms /Action=Patch /InstanceName=...
2
The OUTPUT has to go before the FROM.
DELETE tb
OUTPUT Deleted.TransactionID INTO #TransactionIDs
FROM dbo.TransactionBatch tb
INNER JOIN @BatchTransactionIDs tid
ON tb.TransactionID = tid.TransactionID
2
You have to add a parameter which indicates a database:
create function [dbo].[GetFqn](@objectId bigint, @DatabaseId INT)
returns varchar(100)
as
begin
declare @fqn varchar(100);
select @fqn = quotename(object_schema_name(@objectId, @DatabaseId)) + '.' + quotename(object_name(@objectId, @DatabaseId));
return @fqn;
end
Then call:
select Utility....
1
I am trying to explain one of reason .
Currently object_name is Non unique Clustered index.
So when data is inserted, database engine will search for empty space in each page.Because data can be store any where.So this database search will take time.
Also since it is non unique,optimizer will append unique identifier in each row to make it unique.This ...
1
How I personally would do this:
Rename TableA into TableA_Old and create a view named TableA. That way your users can keep on working.
Create a new TableB, create your indexes on it and start copying data from TableA_Old into TableB (or first copy data and then create indexes; at least I would create the clustered index first and all other indexes after ...
1
As scsimon has pointed out, you can take advantage of OUTPUT clause instead of using a flat file.
CREATE TABLE MyTable(id int identity, foo int);
CREATE TABLE MyTableDeleted(id int, foo int);
INSERT INTO MyTable VALUES
(100),(200),(300),(400),(500);
DELETE FROM
MyTable
OUTPUT
DELETED.* INTO MyTableDeleted
WHERE
foo <= 300;
SELECT * FROM ...
1
You wouldn't be able to persist this computed column, as its value needs to change over time. But having such a non-persisted computed column is a recipe for poor performance.
For this scenario you should decide how often you need to recalculate whether a row is "active" and run a scheduled batch process and/or a trigger to maintain the values.
Only top voted, non community-wiki answers of a minimum length are eligible
