I am using sql-server this is my query:
select asst_id,camp_asst.amp_asst_id,asst.camp_asst_id,lyty_no,campaign_id
into camp.asst_respy
from camp.asst_respy respy
inner join camp.camp_wave wave on wave.wave_cd=resp.camp_id
inner join camp.camp_cust custy on cust.cust_lyty_no=resp.big_id
inner join camp.camp_asst assty on asst.sst_trck_url=resp.dum_url
inner join camp.camp_camp_assty camp_asst on camp_asst.camp_asst_id=asst.asst_id
inner join camp.camp_cust_assty cust_asst on cust_asst.camp_camp_asst_id=camp_asst.asst_id -- this table has about 16 billion rows.
inner join camp.camp_camp_custy camp_cust on camp_cust.camp_camp_cust_id=cust_asst.cust_id
please somebody guide me in doing the join,the join is taking very long time. to happen
and there are indexes defined on table,I am looking to partition the table to make this happen please guide
remaining all tables used have about >10 Million rows.
Related
SELECT
b.1, b.2, b.3, b.4, a.4, a.3, a.5
FROM
a
RIGHT JOIN
b ON a.id = b.id
This query is taking more than 7 minutes.
Both tables have around 100 000 records and just a select from each table runs around 12 seconds avg. In execution plan it is saying that table a has logical reads of around 8708 and 100% operator cost. Both tables have CI on ID.
Verify that an INDEX on the ID column exists in table A. For each row selected in B there will be a lookup of rows in A on the ID column. If an index does not exist on that column this will result in a table scan i.e. a lookup through 100k rows to find rows with that specific ID. Not efficient.
PS - General advice: write queries that don't use RIGHT JOIN, stick to INNER, LEFT and OUTER joins unless there is no other way (there almost always is).
Use this sql below to help you identify any missing indexes. My guess is you are missing at least one.
SELECT
statement AS [database.scheme.table],
column_id , column_name, column_usage,
migs.user_seeks, migs.user_scans,
migs.last_user_seek, migs.avg_total_user_cost,
migs.avg_user_impact
FROM sys.dm_db_missing_index_details AS mid
CROSS APPLY sys.dm_db_missing_index_columns (mid.index_handle)
INNER JOIN sys.dm_db_missing_index_groups AS mig
ON mig.index_handle = mid.index_handle
INNER JOIN sys.dm_db_missing_index_group_stats AS migs
ON mig.index_group_handle=migs.group_handle
ORDER BY mig.index_group_handle, mig.index_handle, column_id
Following is the scenario I have:
I have a stored procedure that returns data by joining 4 tables.
Twice in the middle of the day there is a bulk upload to one of the above 4 tables. The load continues for 10-15 minutes. I do not want the UI that invokes this stored procedure to freeze/block/slow down during this 10-15 minute window. I do not care about showing dirty/uncommitted data from the above tables. Following are my queries:
Do I need to use NOLOCK on just the table which is being loaded during the day OR NOLOCK needs to be added to all 4 tables of the join.
For e.g.
SELECT *
FROM Table1 T1 WITH (NOLOCK) --this is the table that will be bulk-loaded twice during the day
INNER JOIN Table2 T2 WITH (NOLOCK)
INNER JOIN Table3 T3 WITH (NOLOCK)
INNER JOIN Table4 T4 WITH (NOLOCK)
OR is this sufficient
SELECT *
FROM Table1 T1 WITH (NOLOCK) --this is the table that will be bulk-loaded twice during the day
INNER JOIN Table2 T2
INNER JOIN Table3 T3
INNER JOIN Table4 T4
If I add a SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED at the beginning of the retrieval procedure and reset it back to READ COMMITTED at the end, will there be any difference?
Thanks
Vikas
You only need to add NOLOCK for the tables that will be locked for prolonged periods of time, so adding NOLOCK to only Table1 is sufficient.
If you set the isolation level to READ UNCOMMITTED, you do not need to add NOLOCK at all, since it will be automatically applied to all queried tables. In other words you will create a situation similar to the first example in your question item 1 where NOLOCK is applied to all tables participating in the SELECT.
By the way, make sure you add ON conditions to your INNER JOIN clauses, because as presented they are not valid Transact-SQL.
In theory, why would inner join work remarkably faster then left outer join given the fact that both queries return same result set. I had a query which would take long time to describe, but this is what I saw changing single join: left outer join - 6 sec, inner join - 0 sec (the rest of the query is the same). Result set: the same
Actually depending on the data, left outer join and inner join would not return the same results..most likely left outer join will have more result and again depends on the data..
I'd be worried if I changed a left join to an inner join and the results were not different. I would suspect that you have a condition on the left side of the table in the where clause effectively (and probably incorrectly) turning it into an inner join.
Something like:
select *
from table1 t1
left join table2 t2 on t1.myid = t2.myid
where t2.somefield = 'something'
Which is not the same thing as
select *
from table1 t1
left join table2 t2
on t1.myid = t2.myid and t2.somefield = 'something'
So first I would be worried that my query was incorrect to begin with, then I would worry about performance. An inner join is NOT a performance enhancement for a Left Join, they mean two different things and should return different results unless you have a table where there will always be a match for every record. In this case you change to an inner join because the other is incorrect not to improve performance.
My best guess as to the reason the left join takes longer is that it is joining to many more rows that then get filtered out by the where clause. But that is just a wild guess. To know you need to look at the Execution plans.
I am trying to JOIN multiple tables to the same value in a table. So I have the table ActivityPartyBase and it has a column PartyId. I want to join COntactId in ContactBase table to PartyId and AccountId in AccountBase table to PartyId. This is the code I am using and it doesn't return anything. If I only join one it works. Any ideas?
SELECT DISTINCT Appointment.ScheduledStart, ActivityPartyBase.ActivityId
, Appointment.ActivityId AS Expr1, ActivityPartyBase.ScheduledStart AS Expr2
, Appointment.Subject, ActivityPartyBase.PartyId, ContactBase.ContactId
, ContactBase.FullName
FROM Appointment
INNER JOIN ActivityPartyBase
ON Appointment.ActivityId = ActivityPartyBase.ActivityId
INNER JOIN AccountBase ON ActivityPartyBase.PartyId = AccountBase.AccountId
LEFT OUTER JOIN ContactBase ON ActivityPartyBase.PartyId = ContactBase.ContactId
ORDER BY Appointment.ScheduledStart DESC
Your inner joins are filtering out results because there is no corresponding record on the joined table. I've always found the easiest way to debug is to "Select *" and use all LEFT JOINs. This will show you everything in your tables that relates to your main table; you should be able to look at your data and figure out what table is missing a record easily at that point.
To confirm that this is just a naming convention mismatch,
INNER JOIN AccountBase ON ActivityPartyBase.PartyId = AccountBase.AccountId
Are PartyID and AccountId the PK/FK?
Given this...
FROM Appointment
INNER JOIN ActivityPartyBase ON Appointment.ActivityId = ActivityPartyBase.ActivityId
INNER JOIN AccountBase ON ActivityPartyBase.PartyId = AccountBase.AccountId
LEFT OUTER JOIN ContactBase ON ActivityPartyBase.PartyId = ContactBase.ContactId
... you state this works (?) ...
FROM Appointment
INNER JOIN ActivityPartyBase ON Appointment.ActivityId = ActivityPartyBase.ActivityId
/* INNER JOIN AccountBase ON ActivityPartyBase.PartyId = AccountBase.AccountId */
/* LEFT OUTER JOIN ContactBase ON ActivityPartyBase.PartyId = ContactBase.ContactId */
Since the LEFT OUTER JOIN won't explicitly cause no results, that won't be your problem. Since the INNER JOIN will cause what you're seeing, we can only deduce that the join condition is incorrect.
In other words, ActivityPartyBase.PartyId is not equal to AccountBase.AccountID.
Are you sure there is data in all three tables in the inner join?
I'm guessing one of your INNER JOINs isn't picking up any data. Start with all 3 joins, then take out one of the joins at a time see which one breaks it. Then look at your join conditions and see which column isn't returning a record.
SOunds to me as if the tables are mutually exclusive. If it is ione table it is not inthe other (poor design). Try left joins to both tables.
I have query joining several tables, the last table is joined with LEFT
JOIN. The last table
has more then million rows and execution plan shows table scan on it. I have
indexed columns
on which the join is made. It is always use index scan but If I replace LEFT JOIN with INNER JOIN, index seek is used
used and execution
takes few seconds but with LEFT JOIN there is a table scan , so the
execution
takes several minutes. Does using outer joins turn off indexes? Missed I
something?
What is the reason for such behavior?
Here is the Query
Select *
FROM
Subjects s
INNER join Question q ON q.SubjectID = s.SubjectID
INNER JOIN Answer c ON a.QestionID = q.QuestionID
Left outer JOIN Cell c ON c.Question ID = q.QuestionID
Where S.SubjectID =15
There is cluster index on SubjectID in "Subject" table. and there is non-cluster index on questionID in other tables.
Solution:
I try it in other way and now I am index seek on Cell table. Here is the modified query:
Select *
FROM
Subjects s
INNER join Question q ON q.SubjectID = s.SubjectID
INNER JOIN Answer c ON a.QestionID = q.QuestionID
Left outer JOIN Cell c ON c.Question ID = q.QuestionID
AND C.QuestionID > 0
AND C.CellKey > 0
Where S.SubjectID =15
This way I did high selectivity on Cell table. :)
I just tried to simulate the same issue, however there is no table scan instead it was using the clustered index of Cell, at the same time you could try to force the index, you can check the syntax here and the issues you may face when forcing an index here. Hope this helps.