<\/div>\n

Merhaba,<\/p>\n

Bildi\u011finiz \u00fczere SQL Server’da iki farkl\u0131 veri silme y\u00f6ntemi vard\u0131r. Bunlar “delete” ve “truncate table” sorgular\u0131d\u0131r. Bu iki y\u00f6ntem aras\u0131ndaki temel fark “delete” sorgusu ile veriler sat\u0131r sat\u0131r silinmekte ve identity de\u011feri s\u0131f\u0131rlanmamaktayken, “truncate table” sorgusu ile tek seferde blok halinde silme i\u015flemi ger\u00e7ekle\u015ftirilmekte ve tablonun identity de\u011ferini s\u0131f\u0131rlanmaktad\u0131r.<\/p>\n

Hadi konumuzun detay\u0131na girmeden \u015fu sorgularla ilgili biraz daha detayland\u0131rma yapal\u0131m. “delete” sorgusu, tablomuzun tamam\u0131n\u0131 silmek i\u00e7in kullan\u0131labilecekken bir yandan da sorguya \u015fart ko\u015farak silme i\u015flemi i\u00e7in belirli bir filtre uygulayabiliriz. Bunlar\u0131n yan\u0131nda “delete” sorgusu, silinen verileri “Transaction Log” dosyas\u0131na aktarmakta, bu sayade bir seyir defteri olu\u015fturmaktad\u0131r. Ee haliyle bu i\u015flemler ek bir performans gerektirdi\u011fi i\u00e7in \u00e7al\u0131\u015fma maliyetini y\u00fckseltmekte ve sorgunun i\u015fleyi\u015f s\u00fcresini uzatmaktad\u0131r.<\/p>\n

“Trancate table” sorgusuna gelirsek e\u011fer yukar\u0131da bahsetti\u011fim gibi verileri tek tek de\u011fil bir b\u00fct\u00fcn halinde silmesi ve bu i\u015flemi yaparken bir .log olu\u015fturmamas\u0131ndan dolay\u0131 “delete” sorgusuna nazaran kat be kat h\u0131zl\u0131d\u0131r. “truncate” verileri tutuldu\u011fu sayfalardaki referanslar\u0131ndan sildi\u011fi i\u00e7in ayr\u0131ca h\u0131z\u0131na h\u0131z katmaktad\u0131r. Bu da bize veri boyutu ve sat\u0131r say\u0131s\u0131 ne kadar fazla olursa olsun, milyonlarca veriyi birka\u00e7 saniyede silmemizi sa\u011flamaktad\u0131r.<\/p>\n

\u0130\u015fte bu yapt\u0131\u011f\u0131m\u0131z ufak mukayeseden anla\u015f\u0131l\u0131yor ki, tablomuzdaki kay\u0131tlar\u0131n t\u00fcm\u00fcn\u00fc silmek istiyorsak e\u011fer “delete” sorgusu yerine “truncate table” sorgusunu tercih etmemiz hem daha maliyetli, hem daha h\u0131zl\u0131 ve hemde di\u011fer a\u00e7\u0131lardan daha performansl\u0131 olacakt\u0131r.<\/p>\n

\u015eimdi konumuza gelirsek e\u011fer “truncate table” sorgusunun bir dezavantaj\u0131n\u0131 ele almam\u0131z gerekecektir. O dezavantajda t\u00fcm verileri silmesidir. Evet, biraz \u00f6nce \u00f6vd\u00fc\u011f\u00fcm\u00fcz \u00f6zellik \u015fimdi dezavantaj olarak de\u011ferlendirilmektedir. \u00c7\u00fcnk\u00fc “truncate table” sorgusunun h\u0131z ve performans\u0131n\u0131 biz tablomuzda istedi\u011fimiz veriler \u00fczerinde g\u00f6rmek istiyoruz ama genel \u00fczerinde kullan\u0131yorsak bu bir dezavantaj olarak nitelendirilebilir.<\/p>\n

SQL Server 2016 ile Truncate Table Partition \u00f6zelli\u011fi bu dezavantaj\u0131 \u00e7ok g\u00fczel kamufule etmekte ve verilerimizi belirli periyotlara b\u00f6lerek, istedi\u011fimiz par\u00e7aya truncate uygulama imkan\u0131 vermektedir. Haliyle art\u0131k tablomuzdaki t\u00fcm veriyi de\u011fil, verinin sadece belli k\u0131sm\u0131n\u0131 i\u00e7eren partitionlardan birini yahut birka\u00e7\u0131n\u0131 silebiliriz.<\/p>\n

\u015eimdi isterseniz makalemizi pratik uygulamayla besleyelim.<\/p>\n

Tabi ki de prototipten ba\u015flayal\u0131m. Birazdan uygulayaca\u011f\u0131m\u0131z partition yap\u0131s\u0131yla birlikte truncate komutumuz a\u015fa\u011f\u0131daki gibi bir kal\u0131pta kullan\u0131lacakt\u0131r.<\/p>\n

\r\nTRUNCATE TABLE [dbo.TabloAdi]\r\nWITH (PARTITIONS (Ba\u015flang\u0131\u00e7Par\u00e7aNo TO Biti\u015fPar\u00e7aNo))\r\n<\/pre>\nEvet, art\u0131k tablomuzda partition i\u015flemini ger\u00e7ekle\u015ftirebiliriz. Bu i\u015flem i\u00e7in Partition Function<\/em><\/strong> ve Partition Scheme<\/em><\/strong> olmak \u00fczere iki adet yap\u0131dan yararlanaca\u011f\u0131z. <\/p>\n
\nPartition Function<\/em><\/strong>
\nBu nesne sayesinde tablomuzda verinin b\u00f6l\u00fcnece\u011fi de\u011fer aral\u0131\u011f\u0131 tan\u0131mlan\u0131r.\n<\/li>\n
Partition Scheme<\/em><\/strong>
\nPartition Function nesnesi ile tan\u0131mlanan aral\u0131ktaki kay\u0131tlar\u0131 hangi FileGroup i\u00e7inde tutaca\u011f\u0131n\u0131 ise bu nesne arac\u0131l\u0131\u011f\u0131yla belirtiyoruz.\n<\/li>\n<\/ul>\n\u015eimdi s\u0131ras\u0131yla bu objeleri olu\u015ftural\u0131m.<\/p>\n
\r\nCREATE PARTITION FUNCTION VerileriParcalaraBol(int)\r\nAS RANGE LEFT FOR VALUES\r\n(1000, 2000, 3000, 4000, 5000, 6000, 7000, 8000, 9000, 10000)\r\n<\/pre>\nPartition Function ile verilerimizi binerli farkla 10 adet par\u00e7aya ay\u0131rd\u0131k.<\/p>\n
\r\nCREATE PARTITION SCHEME VeriSablonu\r\nAS PARTITION VerileriParcalaraBol\r\nTO ([PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY],\r\n [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY], [PRIMARY])\r\n<\/pre>\nYukar\u0131da par\u00e7aya ay\u0131rd\u0131\u011f\u0131m\u0131z veri bloklar\u0131n\u0131 fiziksel olarak nerede tutulaca\u011f\u0131n\u0131 Partition Scheme ile belirtiyoruz. Burada her par\u00e7a i\u00e7in ayn\u0131 FileGroup belirlenmi\u015ftir. <\/p>\n
Bu ad\u0131mdan sonra \u00f6rnek bir tablo olu\u015ftural\u0131m ve bu tablodaki verileri “VerileriParcalaraBol” isimli Partition Function nesnesi ile id de\u011ferlerine g\u00f6re par\u00e7alanacaklar\u0131n\u0131 belirtelim. Tabi ki de bu i\u015flem i\u00e7in “VeriSablonu” isimli Partition Scheme nesnesini kullanaca\u011f\u0131z.<\/p>\n
\r\nCREATE TABLE OrnekTablo\r\n(\r\n\tID INT PRIMARY KEY IDENTITY(1,1),\r\n\tKolon1 NVARCHAR(MAX),\r\n\tKolon2 NVARCHAR(MAX)\r\n) ON VeriSablonu(ID)\r\n<\/pre>\nDikkat ederseniz “ON VeriSablonu(ID)<\/em>” komutu ile Partition Scheme nesnemiz arac\u0131l\u0131\u011f\u0131yla ID kolonuna \u00f6zel verileri par\u00e7alamaktay\u0131z.<\/p>\n
\u015eimdi \u00f6rneklendirmemizi h\u0131zl\u0131 bir bi\u00e7imde icra edebilmek i\u00e7in a\u015fa\u011f\u0131daki sorguyla tablomuza 10000 adet veri girelim.<\/p>\n
\r\nINSERT INTO OrnekTablo(Kolon1, Kolon2)\r\nSELECT TOP 10000 ROW_NUMBER() OVER(ORDER BY o1.object_id), 'Gen\u00e7ay Y\u0131ld\u0131z'\r\nFROM sys.objects o1 cross join sys.objects o2\r\n<\/pre>\nBu i\u015flemden sonra Partition Function’\u0131m\u0131z\u0131 denetleyerek ne kadar par\u00e7a olu\u015fturulmu\u015f g\u00f6relim.<\/p>\n
\r\nSELECT\r\n $PARTITION.VerileriParcalaraBol (ID) [Partition ID], COUNT(*) [Eleman Say\u0131s\u0131] FROM OrnekTablo GROUP BY $PARTITION.VerileriParcalaraBol(ID)\r\n<\/pre>\n<\/a><\/p>\n
G\u00f6r\u00fcld\u00fc\u011f\u00fc gibi 10 adet partition 1000’erlik veri k\u00fcmesiyle haz\u0131r beklemektedir.<\/p>\n
\u015eimdi s\u0131ra trancate sorgumuzu kullanarak ilgili tablomuzda istedi\u011fimiz partition\u0131 silmeye geldi.<\/p>\n
\r\nTRUNCATE TABLE OrnekTablo WITH(PARTITIONS(3, 4))\r\n<\/pre>\nBu \u00f6rnekte ben 3. ve 4. par\u00e7alar\u0131n silinmesini istemi\u015f olduk. Haliyle Partition Function’\u0131m\u0131z a\u015fa\u011f\u0131daki gibi g\u00f6z\u00fckecektir.
\n<\/a>
\nBuradan anla\u015f\u0131l\u0131yor ki, 3. ve 4. par\u00e7alara denk d\u00fc\u015fen t\u00fcm veriler fiziksel olarak truncate sorgusuyla silinmi\u015ftir.
\nBenzer \u015fekilde a\u015fa\u011f\u0131daki gibi bir \u00e7al\u0131\u015fmada ger\u00e7ekle\u015ftirebiliriz.<\/p>\n
\r\n TRUNCATE TABLE OrnekTablo WITH(PARTITIONS(1, 2, 6 TO 8))\r\n<\/pre>\nBurada ise 1 ve 2. par\u00e7alarla birlikte 6 ile 8. par\u00e7alar aras\u0131nada truncate talebinde bulunmu\u015f oluyoruz.
\n<\/a>
\nG\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere truncate sorgumuzda ne belirttiysek ilgili par\u00e7alar silinmi\u015ftir.<\/p>\n
Evet, bir SQL Server 2016 yenili\u011finin sonuna daha gelmi\u015f bulunmaktay\u0131z.
\nUmar\u0131m bol bol faydalan\u0131rs\u0131n\u0131z.<\/p>\n
Sonraki yaz\u0131lar\u0131mda g\u00f6r\u00fc\u015fmek \u00fczere…
\n\u0130yi \u00e7al\u0131\u015fmalar…<\/p>\n","protected":false},"excerpt":{"rendered":"
Merhaba, Bildi\u011finiz \u00fczere SQL Server’da iki farkl\u0131 veri silme y\u00f6ntemi vard\u0131r. Bunlar “delete” ve “truncate table” sorgular\u0131d\u0131r. Bu iki y\u00f6ntem aras\u0131ndaki temel fark “delete” sorgusu ile veriler sat\u0131r sat\u0131r silinmekte ve identity de\u011feri s\u0131f\u0131rlanmamaktayken,...<\/p>\n","protected":false},"author":1,"featured_media":3415,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1412],"tags":[1467,1470,1471,245,1413,1468,126,1469,104,1466,1465],"class_list":["post-5064","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sql-server-2016","tag-partition","tag-partition-function","tag-partition-scheme","tag-sql-server","tag-sql-server-2016","tag-sql-server-partition","tag-transaction","tag-transaction-log","tag-truncate","tag-truncate-table","tag-truncate-table-partition"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/5064","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/comments?post=5064"}],"version-history":[{"count":0,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/5064\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media\/3415"}],"wp:attachment":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media?parent=5064"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/categories?post=5064"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/tags?post=5064"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}