Du kan evt. slette i mindre batches. Samlet set vil IO'en vist være nogenlunde det samme, men det bliver ikke en stor intensiv klump.
Afhængigt af hvor mange rækker du har totalt, og hvor mange der er du skal slette, og hvor lang tid det må tage - så kan du evt lave et scheduleret job, der kører hvert minut (eller sjældnere), som laver følgende:
------------------------- SET ROWCOUNT 1000 DELETE FROM dinTabel WHERE <kriterie> -------------------------
Hvis du bruger SQL 2005, så kan du i stedet gøre sådan her: ------------------------- DELETE TOP (1000) FROM dinTabel WHERE <kriterie> -------------------------
Ved hver kørsel, slettes kun 1000 rækker, og vil dermed kunne eksekveres noget hurtigere. Hvis det er 200.000 rækker der skal slettes, og du tager det i klumper af 1000 via et minutligt job via SQL Agenten, så vil det tage små 4 timer.
Hvis situationen er, at du i dag har rigtig mange rækker i tabellen, og kun en lille del skal efterlades (fx hvis du har 2 års log, men kun skal gemme 3 måneder) - så kan det være væsentlig hurtigere og smartere, og kopiere de 3 måneders log over i en anden midlertidig tabel. Og så truncate den store tabel, og kopiere de 3 måneder tilbage. Men den ide er lidt afhængig af om tabellen er "aktiv" hele tiden, eller om du godt kan leve med at tabellen er tom i et kort øjeblik, inden du får kopieret dataene tilbage.
Jeg tror, du skal forfølge den løsning, kalp foreslog i den anden tråd.
Lav en select, som finder de tre måneder, der skal gemmes. Udvid derefter forespørgslen med en "insert into", så du får dem i en anden tabel. Truncate tabellen og select derefter tilbage fra backup tabellen.
Jeg kom til at tænke på. Har I forsøgt at slette de 200.000 rækker? Umiddelbart ville jeg ikke være så nervøs for den IO det giver, samt det performance impact det giver. DOG vil DELETE'n nok kræve en table lock, som kan gøre at tabellen ikke kan tilgås i x sekunder. Hvis tabellen er "hot", dvs meget aktiv, så er dette selvfølgelig et problem.
Vend evt. tilbage med lidt mere info om hvor mange rækker der findes i tabellen, samt hvor mange der skal slettes/efterlades, og hvor "hot" tabellen er. Ligeledes kunne det være interessant at høre lidt om hvilket system databasen kører på.
Som sjang skriver: "mindre batches", og jeg tror det er det jeg gør efter. Da vores system er bygget sådan op, at den table er MEGET MEGET "HOT" og kan på ingen måde tage en table lock i alt for langtid.
Men der må da være en løsning. Jeg ved man kan gøre disse ting i oracle, slette og slå transaction fra. Men det gæller måske ikke delete. mySQL har lidt samme funktion som oracle.
Hvad angår informationer, så har i ren faktisk selv beskrevet problemmet meget godt.
sjang >> jeg tror vist det er dit svar jeg bruger :) Så vis du lige sender mig en fakture, så kreditere jeg med 60 point :D
Jeg mener stadig væk at den bedste løsnin nok er at partitionere tabellen - med nogloe passende partitioer vil det være muligt at slette dele af tabellen (f.eks. det der er for gammelt) unden at det kan føles nævneværdigt på reten af systemet.
dl: at partitionere tabellen er en feature der kun findes i SQL 2005 Enterprise Edition, så hvis ikke du har den version - så er der sådan set ingen grund til at tale mere om den feature. Så derfor er det også altid en brand god ide at skrive hvilken version sql server man benytter, da mulighederne er forskellige.
Men Kimberly L. Tripp har skrevet denne artikel, der beskriver det ganske udmærket synes jeg. Artiklen fortæller om hvordan man gjorde det i ældre SQL server udgaver - via views.
Forestil dig, at du har 12 tabeller - en for januar, en for februar osv. Når du gemmer dine data, gemmer du dem i den tabel der nu er relevant. Så laver du et view ovenpå, som union'er dem alle. Når du selecter alt indhold fra view'et, får du altså indholdet fra alle dine 12 tabeller. Men view'et kan laves så smart, at hvis du kun vil selecte noget fra januar, så behøver view'et ikke selecte fra alle de andre 11 tabeller. Og det vil også sige, at hvis du vil slette al data fra januar til og med oktober, ja så kan du roligt trunkere disse 10 tabeller, og efterlade november og december tabellerne intakte.
Det er i grove træk hvad det går ud på. Det udføres i praksis anderledes end jeg lige beskrev, og er som sagt en Enterprise Edition only funktion.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
