this is my SQL:
select last_row(*) from test.meters where ts now-100d group by tbname;
I have 100000000 rows of data ,and it cost me 11 seconds. like this :
I don't think it is the best performance ,may I know how to improve it .
please run this command in TDengine database shell :
select * from information_schema.ins_databases\G;
to check if 'cachemodel' is none ,if it is , set it to 'both'
Then try again.
Related
When I execute a particular query from Heidi against an MSSQL database, it takes approximately 10 times longer than executing the identical query in SSMS.
They are both being executed against the same server from the same workstation.
What can account for this difference?
Here is the exact query and relative execution times:
SELECT b.ID as BookingID, b.ReservationID, b.RoomID, b.EventName,
b.EventTypeID, b.StatusID, b.DateAdded, build.Value1 as BuildingID,
build.ValueDescription as Building
FROM EMS.dbo.tblBooking b
INNER JOIN EMS.dbo.tblRoom room
ON room.ID = b.RoomID
INNER JOIN ( SELECT deff.Value1, deff.ValueDescription
FROM tblDataExtractionFilter_Fields deff
INNER JOIN tblDataExtractionFilter def ON deff.FilterID = def.ID
WHERE def.Description = '[redacted]'
AND deff.FieldID = 28
AND deff.Show = 0) build
ON room.BuildingID = build.Value1
WHERE b.DateAdded > DATEADD(DAY,-7,GETDATE()) AND (StatusID = 1 OR StatusID = 16);
Heidi: "Duration for 1 query: 1.015 sec."
SSMS: "00:00:01"
I am obviously green, but my understanding was that the execution plan was determined server side and not application side. This leads me to suspect that there is some sort of overhead in Heidi with respect to this query (simpler queries execute MUCH faster so the overhead would not be universal).
This is just a point of curiosity for me. I am still learning. Can anyone offer a clue about what I can check/google/research to try to understand this?
Thanks!
EDIT: The times I have reported do not agree with my statement that the SSMS time is 1/10 that of Heidi. They are both approximately 1 second. My subjective wait time (wall clock time) between execution and display is MUCH faster (and much less than 1 second) in SSMS. Can this be due to SSMS caching the results?
Is there a way to get the amount of 'selects' from a mssql table?
I mean without rewriting application to log every request or without parsing sql profile logs...
Is there any build-in tool (sql request)?
SQL Server maintains index usage statistics since last restart. You can use user_reads column from query bellow to get wanted statistics:
SELECT OBJECT_NAME(ddius.[object_id], ddius.database_id) AS [object_name] ,
ddius.index_id ,
ddius.user_seeks ,
ddius.user_scans ,
ddius.user_lookups ,
ddius.user_seeks + ddius.user_scans + ddius.user_lookups
AS user_reads ,
ddius.user_updates AS user_writes ,
ddius.last_user_scan ,
ddius.last_user_update
FROM sys.dm_db_index_usage_stats ddius
WHERE ddius.database_id > 4 -- filter out system tables
AND OBJECTPROPERTY(ddius.OBJECT_ID, 'IsUserTable') = 1
AND ddius.index_id > 0 -- filter out heaps
AND database_id = DB_ID()
ORDER BY user_reads DESC
I've a server with 20 clients. If I don't use a client for 1 day, the result of query arrives after 2:30 minutes (over 1000 rows). After the execution of 5/6 queries, the result arrives after few seconds.
I think it's a scheduling problem of SQL Server. How can I resolve?
Thanks
UPDATE
this is the query
Select * from [WWALMDB].[dbo].[v_AlarmConsolidated]
Where Critico = 1 AND ApprovatoQA = 0
AND InAttesaDiRiconoscimento Like '%param1%'
AND (Tipo Like '%param2%') AND Area Like '%param3%'
AND Nome Like '%%param4%%' AND Descrizione Like '%%param5%%'
AND (([Dataora Scatto] >= CONVERT(DATETIME,'param6',105))
AND ([Dataora Scatto] <= CONVERT(DATETIME,'param7',105))
OR( ([Dataora Rientro] >= CONVERT(DATETIME,'param6',105))
AND ([Dataora Rientro] <= CONVERT(DATETIME,'param7',105)) )
OR( ([Dataora PresoInCarico] >= CONVERT(DATETIME,'param6',105))
AND ([Dataora PresoInCarico] <= CONVERT(DATETIME,'param7',105)) ))
ORDER BY AlarmID DESC
What you described is a normal SQL Server caching behavior.
More information about MSSQL Server caching mechanisms you can find here
It's impossible to tell you anything else without knowing the background (example sql queries, health status of your sql server machine and actual db data structure)
UPDATE:
Your query is probably so badly optimized, that is actually a miracle it's only 2:30
SELECT *
LIKE '%%*%%'
ORDER BY
The following linq-to-entities query throws
Entity Framework Timeout expired. The timeout period elapsed prior to
completion of the operation or the server is not responding.
after ToList()ing it.
var q = (from contact
in cDB.Contacts.Where(x => x.Templategroepen.Any(z => z.Autonummer == templategroep.Autonummer)
&& !x.Uitschrijvings.Any(t => t.Templategroep.Autonummer == templategroep.Autonummer))
select contact.Taal).Distinct();
((System.Data.Objects.ObjectQuery)q).ToTraceString() gives me:
SELECT
[Distinct1].[Taal] AS [Taal]
FROM ( SELECT DISTINCT
[Extent1].[Taal] AS [Taal]
FROM [dbo].[ContactSet] AS [Extent1]
WHERE ( EXISTS (SELECT
1 AS [C1]
FROM [dbo].[TemplategroepContact] AS [Extent2]
WHERE ([Extent1].[Autonummer] = [Extent2].[Contacts_Autonummer]) AND ([Extent2].[Templategroepen_Autonummer] = #p__linq__0)
)) AND ( NOT EXISTS (SELECT
1 AS [C1]
FROM [dbo].[UitschrijvingenSet] AS [Extent3]
WHERE ([Extent1].[Autonummer] = [Extent3].[Contact_Autonummer]) AND ([Extent3].[Templategroep_Autonummer] = #p__linq__1)
))
) AS [Distinct1]
the query from tracestring runs in under 1 seconds in sql management studio, but times out when actually to-listing it? how is that possible again?
*Update: added SQL PROFILER output for query * this runs as slow as the EF ToList() (>30seconds)
exec sp_executesql N'SELECT
[Distinct1].[Taal] AS [Taal]
FROM ( SELECT DISTINCT
[Extent1].[Taal] AS [Taal]
FROM [dbo].[ContactSet] AS [Extent1]
WHERE ( EXISTS (SELECT
1 AS [C1]
FROM [dbo].[TemplategroepContact] AS [Extent2]
WHERE ([Extent1].[Autonummer] = [Extent2].[Contacts_Autonummer]) AND ([Extent2].[Templategroepen_Autonummer] = #p__linq__0)
)) AND ( NOT EXISTS (SELECT
1 AS [C1]
FROM [dbo].[UitschrijvingenSet] AS [Extent3]
WHERE ([Extent1].[Autonummer] = [Extent3].[Contact_Autonummer]) AND ([Extent3].[Templategroep_Autonummer] = #p__linq__1)
))
) AS [Distinct1]',N'#p__linq__0 int,#p__linq__1 int',#p__linq__0=1,#p__linq__1=1
I observed this issue with EF6.
await _context.Database.SqlQuery<MyType>(sql) was timing out even when my timeout value was cranked up to 60 seconds. However, executing the exact same SQL (used profiler to confirm the sql I passed in was unmodified) in SSMS yielded expected results in one second.
exec sp_updatestats
Fixed the issue for me.
(DBCC FREEPROCCACHE)
DBCC DROPCLEANBUFFERS
made the problem go away for now, but I think that might just be a temp. solution
I know this is a little late, but I found the answer here.
Basically Entity Framework likes to track everything by default. If you don't need it (i.e. not inserting or updating or deleting entities), turn it off to speed up your queries.
If you're using Entity Framework Code First you can achieve this like so:
var q = (from contact
in cDB.Contacts.AsNoTracking()
.Where(x => x.Templategroepen.Any(z => z.Autonummer == templategroep.Autonummer)
&& !x.Uitschrijvings.Any(t => t.Templategroep.Autonummer == templategroep.Autonummer))
select contact.Taal).Distinct();
I had similar issue with EF6. When using SqlQuery function in EF, I got timeout although query was executed in milliseconds in Management Studio. I found that it happened due the value of one of the sql parameters that I used in EF query. To make it clear, below is the similar SQL query I experienced with.
SELECT * FROM TBL WHERE field1 > #p1 AND field2>#p2 AND field3<#p3
When #p1 is zero, I received timeout exception. When I made it 1 or something different, it was executed in milliseconds. By the way, the table that I queried on has more than 20M rows.
I hope it helps,
Best
You need to Add one column serves as uniqueId or key to be able to work in EF
I have a reasonably complex query that takes under a second to run once SQL server has established the query plan (satisfactory). However the first time the query runs the event ShowPlanXML according to the profiler takes about 14 seconds (not satisfactory).
Is there any way to optimise the ShowPlanXML so that the first time it runs it completes more quickly?
Or am I going to have create a plan guide ?
For info here is the SQL query (as generated by NHibernate):
SELECT top 20 this_.UserId as UserId55_0_, this_.User_Version as User2_55_0_, this_.User_ApplicationId as User3_55_0_, this_.User_DeletedOn as User4_55_0_, this_.User_CreatedOn as User5_55_0_, this_.User_ModifiedOn as User6_55_0_, this_.User_CreatedById as User7_55_0_, this_.User_CreatedByName as User8_55_0_, this_.User_ModifiedById as User9_55_0_, this_.User_ModifiedByName as User10_55_0_, this_.User_Name as User11_55_0_, this_.User_ExternalId as User12_55_0_, this_.User_DynamicFields as User13_55_0_,
this_.User_FirstName as User14_55_0_, this_.User_LastName as User15_55_0_, this_.User_Prefix as User16_55_0_, this_.User_Gender as User17_55_0_, this_.User_Language as
User18_55_0_, this_.User_Code as User19_55_0_, this_.User_Nationality as User20_55_0_, this_.User_FirstLanguage as User21_55_0_, this_.User_DrivingLicence as User22_55_0_,
this_.User_Category as User23_55_0_, this_.User_UserStatus as User24_55_0_, this_.User_UserType as User25_55_0_, this_.User_WorkPhone as User26_55_0_, this_.User_MobilePhone as
User27_55_0_, this_.User_Fax as User28_55_0_, this_.User_Mail as User29_55_0_, this_.User_Login as User30_55_0_, this_.User_Password as User31_55_0_, this_.User_BornOn as
User32_55_0_, this_.User_StartedOn as User33_55_0_, this_.User_FinishedOn as User34_55_0_, this_.User_Address as User35_55_0_, this_.User_PostalCode as User36_55_0_,
this_.User_City as User37_55_0_, this_.User_Country as User38_55_0_, this_.User_PositionTitle as User39_55_0_, this_.User_Comments as User40_55_0_, this_.User_OptionalField1 as
User41_55_0_, this_.User_OptionalField2 as User42_55_0_, this_.User_OptionalField3 as User43_55_0_, this_.User_PasswordConsecutiveFailedAttempts as User44_55_0_,
this_.User_PasswordModificationDate as User45_55_0_, this_.User_WrongPasswordAttemptDate as User46_55_0_, this_.User_PictureUrl as User47_55_0_, this_.User_PasswordModificationStatus as User48_55_0_, this_.User_SecretQuestionConsecutiveFailedAttempts as User49_55_0_, this_.User_PlatformMailTransfer as User50_55_0_, this_.User_TimeZoneId as User51_55_0_, this_.User_ConnectionState as User52_55_0_, this_.User_LastConnectionId as User53_55_0_, this_.User_TotalPercentRealized as User54_55_0_
FROM Dir_User this_
WHERE this_.UserId in (
SELECT distinct this_0_.UserId as y0_
FROM Dir_User this_0_ inner join Dir_UserDynamicGroup dynamicgro3_ on this_0_.UserId=dynamicgro3_.UsDy_UserId
inner join Dir_Group dynamicgro1_ on dynamicgro3_.UsDy_DynamicGroupId=dynamicgro1_.GroupId
WHERE dynamicgro1_.GroupId = (51904517)
and this_0_.User_ApplicationId = 65536
and this_0_.User_DeletedOn is null
and this_0_.UserId in (
SELECT distinct this_0_0_.TargetUserId as y0_
FROM Dir_UserGroupMember this_0_0_
WHERE this_0_0_.OwnerUserId = 7341195
and ( (this_0_0_.Scope & 139280) != 0 or ( (this_0_0_.Scope & 139280) != 0
and this_0_0_.GroupId = this_0_0_.SubGroupId))))
ORDER BY this_.User_Name asc
The show-plan profiler events can have a significant impact on the performance of SQL Server (see sqlserver.query_post_execution_showplan Performance Impact). If you want to get an accurate representation of the amount of time taken to compile a stored procedure you should use an alternative method.
You should be able to identify how much time the plan took to compile by looking at the plan cache directly, see Identifying High Compile Time Statements from the Plan Cache.
Unfortunately I'm not aware of many ways to reduce compilation time for SQL Server queries other than simply reducing the complexity of the query. Attempting to reduce the frequency that plan compilation is required through plan caching is the standard approach to improving performance.