Hej! 50.000 rader är inga problem. Inte ens 5 miljoner rader. Enda som är viktigt att tänka på är att loggfilen fylls upp så en backup för att städa loggfilen mellan varven är aldrig fel. Du kan se litet prestandatips på http://msdn2.microsoft.com/en-us/library/ms190421.aspx. Tack för svaren: SET RECOVERY FULL : jag tror (är inte säker här) att RECOVERY är en database-level option som man bara kan sätta med ALTER DATABASE .. SET RECOVERY FULL.Inserta många rader på en gång.
Håller på med ett jobb som ska gå i Integration services eller liknande i sql server 2005. Jobbet kommer att köra rätt tuffa frågor o sedan göra insert på ouputen enligt:
Insert into table
select * bla bla
Uppskattningsvis kommer den sätta in 50.000+ rader. Är detta ett problem o sätta in så här många rader? Har för mig att de ska finnas ett sätt i sql 2005 för att sätta in några rader i taget. Kommer dock ej ihåg hur.
/ StefanSv: Inserta många rader på en gång.
Sv: Inserta många rader på en gång.
Som Pelle säger så är det viktigt att hantera transaktionsloggen och det kan man t.ex. göra genom att ändra recovery level (som i sin tur styr vad som hamnar i transaktionsloggen), se http://msdn2.microsoft.com/en-us/library/ms190203.aspx för en artikel där man går över i bulk-logged läge (som inte loggar bulk-operationer) under bulk-operationen.
/AndreasSv:Inserta många rader på en gång.
om man skriver typ
insert into ... SET RECOVERY FULL gäller den recovery-leveln bara för denna fråga då?
Går en insert snabbare om den slipper skriva till transloggen?Sv: Inserta många rader på en gång.
Prestanda med transaktionsloggen beror på två saker: dels så tar det tid att skriva till transaktionsloggen men framförallt så har man problemet med att den växer och kan fylla disken. Jag gjorde en gång ett indexdefragmenteringsscript som snabbt fyllde disken som transaktionsloggen låg på om man inte ändrade recovery level före och efter.
Artikeln jag nämde ovan behandlar allt detta.
/Andreas