Recent comments

None


İçerik Ara











Yasal Uyarı
Bu sitede sunulan tüm bilgi ve dökümanlar Turgay Sahtiyan tarafından yazılmaktadır. Yazıların kaynak göstermek şartıyla kullanılması serbesttir.

© Copyright 2009-2013
Takvim
<<  Haziran 2017  >>
PaSaÇaPeCuCuPa
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789
Keywords

Bu makalemde sizlere küçük batch size’lı DML komutları çalıştırılmasını anlatacağım.

Örneğin bir tablomuz var ve 1 milyon kayıt içeriyor, bunun tamamını delete veya update etmemiz durumunda çok gereksiz bir transaction log üretimi yapılır. Delete için truncate kullanabiliriz fakat bununda loglanmayacağı gerçeğini unutmamak lazım. Bunun için kayıtların tamamını silmek yerine belirli miktarlarda bir kaç kere delete çalıştırabiliriz.

[more]

Aşağıdaki aşağıda bunun için bir örnek bulabilirsiniz.

Örnek için 1 milyon kayıtlı bir temp tablo yaratacağım ve bu tablodan her seferinde 1000 kayıt silen bir delete scripti yazacağım.

-- 1 milyon tane sample kayıt yaratalım
create table #temptablom(a int,b int);
insert into #temptablom 
select top 1000000 a.object_id,b.object_id from 
sys.columns a 
cross join 
sys.columns b 
cross join 
sys.columns c

-- Kayıtları istenilen kadar miktarlarda(örnek için 10000) silme
declare @DeletedRowCount int=10000
delete top(@DeletedRowCount) from #temptablom
while @@ROWCOUNT=@DeletedRowCount
	delete top(@DeletedRowCount) from #temptablom

 

İyi çalışmalar

Kadir Evciler

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server da başarılı olan her backup işlemi bildiğiniz gibi SQL Server Log’a yazılmaktadır. TLog backup kullanımınız var ise ve çok sıklıkla backup alıyorsanız SQL Server Log a çok fazla sayıda kayıt yazılacaktır ve bu da Log’un okunmasını zorlaştıracaktır. Bugünkü yazımda başarılı backup işlemlerinin SQL Server Log’a yazılmasını nasıl engelleyeceğimizi görüyor olacağız.

[more]

Konumuz SQL Server Log olduğu için daha önce Kadir Evciler arkadaşımın yazmış olduğu aşağıdaki makaleyi okumanızı tavsiye ederim.

http://www.turgaysahtiyan.com/post/SQL-Server-Loglarc4b1e28099nc4b1-Okumak-Icin-Ozellestirilmis-Log-Arama-Stored-Precedure-u.aspx

Giriş paragrafında söylediğim gibi default davranış olarak SQL Server başarılı bütün backup işlemlerini log’lar. Buda Log’un okunmasını güçleştirebilir. Örneğin bir production ortamında bulunan 20 DB 5 dk da bir Tlog backup alındığından aşağıdaki gibi bir manzara ile karşılaşabilirsiniz.

Clipboard01

Burada 2 seçeneğiniz olabilir. Ya Filter özelliği ile aramak istediğiniz hatayı arayacaksınız ki burada exclude mantığı gibi bir çalışma mantığı yok (Bu konuyla ilgili yukarıda belirttiğim Kadir Evciler’in yazısını okumanızı tavsiye ederim) ya da backup işlemlerinin loglanmasını engellemeliyiz.

SQL Server da bu engellemeyi yapabilmek için 3226 no’lu Trace Flag i aktif hale getirmemiz yeterli.

Hemen bir örnekle durumu daha açık hale getirelim.

  1. İlk örneğimizde trace flag’ı açmayacağız ve bunun log’landığını izleyeceğiz.
    Use master
    GO
    backup database AdventureWorks2008 to disk='C:\backup1.bak'
    GO


    Error Log’a baktığımızda

    Clipboard02

  2. Şimdi aynı işlemi birde Trace Flag’i açarak yapalım.

    --Flag i açalım
    DBCC TRACEON(3226)
    GO
    Use master
    GO
    backup database AdventureWorks2008 to disk='C:\backup2.bak'
    GO
    --Flag i tekrar kapayalım.
    DBCC TRACEOFF(3226)
    GO

    Error Log’a baktığımızda gerçektende backup işleminin loglanmadığını göreceğiz.

    Clipboard03


Trace Flag’i açma işlemi sadece ilgili sessionda gerçekleştiği için bu yöntemle her defasında açmanız gerekmektedir. Bu sıkıntıyıda aşmak için bu trace flag’i –T parametresi ile Servis açılışına ekleyebilirsiniz.

 

İyi çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server Management Studio da sık kullanılan SQL Server scriptlerini SQL Server Template lerinde saklayabilmekteyiz. Hatta SSMS default kurulumunda yüzlerce template ile beraber gelmekte ve syntax ını hatırlayamadığımız scriptler de bize yardımcı olmakta. Bugünkü yazımda SQL Server Template e kaydettiğimiz scriptleri nasıl Export – Import edeceğimizi görüyor olacağız.

[more]

SSMS te SQL Server Template açık değilse View >> Template Explorer kısmını yada Ctrl + Alt + T kısayolunu kullanarak açalım.

Clipboard11

Ekranın sağ tarafına Template Explorer gelecektir.

Clipboard12

Şimdi yazımızın konusu olan bu template leri nasıl Export – Import ettiğimize bakalım.

Template ler Windows7 için C klasöründe aşağıdaki folder da tutulmaktadır.

C:\Users\turgay\AppData\Roaming\Microsoft\Microsoft SQL Server\100\Tools\Shell\Templates\Sql\DBA\

WinXP için ise;

C:\Documents and Settings\turgay\Application Data\Microsoft\Microsoft SQL Server\100\Tools\Shell\Templates\Sql\DBA\

Diğer windows sürümlerinde de buna benzer klasörler olacaktır.

Clipboard13

Buradaki file ları alıp istediğiniz PC ye taşıyarak template export – import u gerçekleştirebilirsiniz.

 

İyi Çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server Data Collector Hata - ODS - Get current snapshot of dm_exec_query_stats yazımda Data Collector de bulunan Query Statistics collection set inin verdiği “arithmetic overflow” hatasından bahsetmiş ve Microsoft’un bu hata çözümü için önerdiği yöntemin cumulative update 5 i yapmak olduğuna değinmiştim.

Cumulative update geniş ölçekli yapılarda evet diyilince yapılacak bir işlem değildir. Bu tarz güncelleştirmeler için sizin de firmanızda bazı prosedure ler bulunabilir. Ayrıca Microsoft dahi “ölümcül” bir hata olmadığı sürece cumulative update in production ortamına yapılmasını önermemektedir.

Bu yüzden bugünkü yazımda bahsi geçen hatayı cumulative update yapmadan “unsupported” bir yöntemle nasıl aşacağımızı anlatacağım. Unsported diyorum çünkü normalde bu hatanın çözümü için Microsoft cumulative update 5 in yapılmasını önermekte ve biz collection set in SSIS paketiyle oynayacağımız için bu durum unsupported bir durum oluşturmaktadır.

[more]

Bu kadar giriş cümlesinden sonra şimdi işleme dönelim. Dediğim gibi Query Statistics collection set inin SSIS paketinde oynama yapacağız ve hata veren kısmı çözmeye çalışacağız.

Bu collection set in upload işleminde hata olduğunu biliyorum. Dolayısıyla değişiklik yapacağım SSIS paket upload SSIS paketi olacak. Pakette değişiklik yapmak için Microsoft Visual Studio yu çalıştırıyorum.

File>>New>>Project>>Integration Service Project kısmından yeni bir Integration Service projesi başlatıyorum.

Clipboard01

SSIS Packages yazısına sağ tıklayıp Add Existing Package a tıklayalım.

Clipboard02

Gelen ekranda Server Name bilgisini yazarak ve Authentication Type ı seçerek Package Path in yanında bulunan butona basalım.

Clipboard03

Clipboard04

Değiştirmek istediğimiz paket olan QueryActivityUpload u seçerek OK e basalım. Bir önceki ekrandada OK e basalım ve ana ekrana düşelim.

Şimdi Solution Explorer kısmından bu paketi çift tıklayalım ve açalım.

Bizim hatamız DFT - Create Interesting Queries Upload Batch isimli Data Flow Task ta.

Clipboard05

Bu task ı çift tıklayarak Data Flow kısmına geçelim. Bu kısımda ise hata veren adım ODS - Get current snapshot of dm_exec_query_stats isimli OleDB Source ta.

Clipboard06

Bu objeyi çift tıklayarak properties ine erişelim.

Clipboard07

Şimdi can alıcı noktaya geliyoruz. Bu ekrandaki SQL Command ı alıp SSMS ten çalıştırdığınızda “arithmetic overflow” hatası alacaksınız. Dediğim gibi değişiklik yapacağımız kısım burası.

Hatanın sebebide 4 farklı satırda geçen aşağıdakine benzer çarpımlar.

r.total_elapsed_time * 1000 AS total_elapsed_time

 

Bu çarpım “arithmetic overflow” hatası vermekte. Cast kullanarak ufak bir trik le hatayı çözmeye çalışacağız.

cast(r.total_elapsed_time as float) * 1000 AS max_elapsed_time

 

Script in son hali aşağıdaki gibi olmalı.

SET NOCOUNT ON
DECLARE @p1 datetime
SET @p1 = GETDATE()

SELECT 
    [sql_handle],
    statement_start_offset,
    statement_end_offset,
    -- Use ISNULL here and in other columns to handle in-progress queries that are not yet in sys.dm_exec_query_stats.  
    -- These values only come from sys.dm_exec_query_stats. If the plan does not show up in sys.dm_exec_query_stats 
    -- (first execution of a still-in-progress query, visible in sys.dm_exec_requests), these values will be NULL. 
    MAX (plan_generation_num) AS plan_generation_num,
    plan_handle,
    MIN (creation_time) AS creation_time, 
    MAX (last_execution_time) AS last_execution_time,
    SUM (execution_count) AS execution_count,
    SUM (total_worker_time) AS total_worker_time,
    MIN (min_worker_time) AS min_worker_time,           -- NULLable
    MAX (max_worker_time) AS max_worker_time,
    SUM (total_physical_reads) AS total_physical_reads,
    MIN (min_physical_reads) AS min_physical_reads,     -- NULLable
    MAX (max_physical_reads) AS max_physical_reads,
    SUM (total_logical_writes) AS total_logical_writes,
    MIN (min_logical_writes) AS min_logical_writes,     -- NULLable
    MAX (max_logical_writes) AS max_logical_writes,
    SUM (total_logical_reads) AS total_logical_reads,
    MIN (min_logical_reads) AS min_logical_reads,       -- NULLable
    MAX (max_logical_reads) AS max_logical_reads,
    SUM (total_clr_time) AS total_clr_time,
    MIN (min_clr_time) AS min_clr_time,                 -- NULLable
    MAX (max_clr_time) AS max_clr_time,
    SUM (total_elapsed_time) AS total_elapsed_time,
    MIN (min_elapsed_time) AS min_elapsed_time,         -- NULLable
    MAX (max_elapsed_time) AS max_elapsed_time,
    @p1 AS collection_time
FROM
(
    SELECT  
        [sql_handle],
        statement_start_offset,
        statement_end_offset,
        plan_generation_num,
        plan_handle,
        creation_time,
        last_execution_time,
        execution_count,
        total_worker_time,
        min_worker_time,
        max_worker_time,
        total_physical_reads,
        min_physical_reads,
        max_physical_reads,
        total_logical_writes,
        min_logical_writes,
        max_logical_writes,
        total_logical_reads,
        min_logical_reads,
        max_logical_reads,
        total_clr_time,
        min_clr_time,
        max_clr_time,
        total_elapsed_time,
        min_elapsed_time,
        max_elapsed_time 
    FROM sys.dm_exec_query_stats AS q
    -- Temporary workaround for VSTS #91422.  This should be removed if/when sys.dm_exec_query_stats reflects in-progress queries. 
    UNION ALL 
    SELECT 
        r.[sql_handle],
        r.statement_start_offset,
        r.statement_end_offset,
        ISNULL (qs.plan_generation_num, 0) AS plan_generation_num,
        r.plan_handle,
        ISNULL (qs.creation_time, r.start_time) AS creation_time,
        r.start_time AS last_execution_time,
        1 AS execution_count,
        -- dm_exec_requests shows CPU time as ms, while dm_exec_query_stats 
        -- uses microseconds.  Convert ms to us. 
        --r.cpu_time * 1000 
        cast(r.cpu_time as float) * 1000 AS total_worker_time,
        qs.min_worker_time,     -- min should not be influenced by in-progress queries
        --r.cpu_time * 1000 
        cast(r.cpu_time as float) * 1000 AS max_worker_time,
        r.reads AS total_physical_reads,
        qs.min_physical_reads,  -- min should not be influenced by in-progress queries
        r.reads AS max_physical_reads,
        r.writes AS total_logical_writes,
        qs.min_logical_writes,  -- min should not be influenced by in-progress queries
        r.writes AS max_logical_writes,
        r.logical_reads AS total_logical_reads,
        qs.min_logical_reads,   -- min should not be influenced by in-progress queries
        r.logical_reads AS max_logical_reads,
        qs.total_clr_time,      -- CLR time is not available in dm_exec_requests
        qs.min_clr_time,        -- CLR time is not available in dm_exec_requests
        qs.max_clr_time,        -- CLR time is not available in dm_exec_requests
        -- dm_exec_requests shows elapsed time as ms, while dm_exec_query_stats 
        -- uses microseconds.  Convert ms to us. 
        --r.total_elapsed_time * 1000 
        cast(r.total_elapsed_time as float) * 1000 AS total_elapsed_time,
        qs.min_elapsed_time ,    -- min should not be influenced by in-progress queries
        --r.total_elapsed_time * 1000 
        cast(r.total_elapsed_time as float) * 1000 AS max_elapsed_time
    FROM sys.dm_exec_requests AS r 
    LEFT OUTER JOIN sys.dm_exec_query_stats AS qs ON r.plan_handle = qs.plan_handle AND r.statement_start_offset = qs.statement_start_offset 
        AND r.statement_end_offset = qs.statement_end_offset 
    WHERE r.sql_handle IS NOT NULL 
) AS query_stats 
OUTER APPLY sys.dm_exec_sql_text (sql_handle) AS sql
GROUP BY [sql_handle], plan_handle, statement_start_offset, statement_end_offset 
ORDER BY [sql_handle], plan_handle, statement_start_offset, statement_end_offset

 

İşimiz bitti. Bu ekranı OK diyerek kapatabiliriz. Daha sonrada değişiklik yaptığımız paketi save ediyoruz.

Şimdiki adımımız bu paketi hata aldığımız sunucuya deploy etmek.

Bunun için Integration Server a SSMS kullanarak bağlanıyoruz.

Clipboard08

Stored Packages >> MSDB >> Data Collector yazısına sağ tıklayıp Import Package ı seçiyoruz.

Clipboard09

Gerekli Import bilgilerini aşağıdaki gibi dolduruyorum ve paketi import ediyorum.

Clipboard10

Yapacaklarımız bu kadar :) Bende bu işlemlerden sonra collection set im şıkır şıkır çalışmaya başladı. Darısı sizin başınıza. :)

 

İyi çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server TempDB veritabanı yanlış yapılan join sorgularının order by clause ile beraber kullanımı ile plan dışı büyüyebilir. Bu büyüme disk size ı dolduracak kadar olursa servis kullanılmaz duruma gelebilir. Bugünkü yazımda TempDB boyutunu küçültme amaçlı yapılabilecek shrink operasyonlarını inceliyor olacağız. Bu kapsamda 3 farklı shrink metodu anlatıyor olacağım.

[more]

Anlatacağım 3 farklı shrink operasyonundan ilkinde “size” tamamen kontrolünüz altında olmakla beraber service restart ı gerektirmektedir. Diğer 2 yöntemde ise shrink komutları kullanılacak ve bu komutlar kullanılırken tempdb üzerinde bir action olmaması gerekmektedir.

Yöntemleri anlatırken örnekler üstünden gidiyor olacağız. Bu örnekler de aşağıdaki 2 script i kullanacağız.

TempDB File Boyutları Sorgusu (1.Script)

Bu sorgu ile TempDB veritabanı dosyalarının aktif boyutlarını sorgulayabiliriz. Değerler MB cinsindendir.

use tempdb
select (size*8)/1024 as FileSizeMB from sys.database_files

 

Örnek sorgu sonucu aşağıdaki gibidir.

res1

TempDB Boyutunu Arttırmak İçin Kullanılacak Script (2.Script)

Bu script ile AdventureWorks2008 de bulunan 6 tablo join clause kullanmadan birbirine bağlanacak ve cross join olması sağlanacaktır. Ayrıca order by clause kullanılacak ve order işlemi tempdb de yapılacağından dolayı tempdb boyutunun büyümesi sağlanacaktır. File larının boyutlarının yeteri kadar büyüdüğünü düşündüğünüzde sorgunun tamamlanmasını beklemeden kapatabilirsiniz.

use AdventureWorks2008
select * 
from Production.TransactionHistory
	,Production.TransactionHistoryArchive	
	,Sales.SalesOrderDetail
	,Production.WorkOrder
	,Production.WorkOrderRouting
	,Person.BusinessEntity
order by 1,2,3

Yöntem 1

  1. TempDB file larının şu anki boyutuna bakmak için 1.Script i çalıştıralım. 

    res1
  2. 2.Script i kullanarak tempdb file larının boyutlarını arttıralım.
  3. 1 nolu script i kullanarak tempdb file larının aldığı boyutu görelim. 

    res2
  4. SQL Server service ini Configuration Manager den stop edelim. 

    res3
  5. Command Prompt u kullanarak SQL Server service ini –c –f parametresi ile tekrar start edelim. Bu parametreler SQL Server ın minimum configuration lar la açılmasını sağlayacaktır. TempDB data file ı 1MB , log file ı 0.5MB olarak açılacaktır. 

    Res4
  6. SSMS üzerinden aşağıdaki sorguyu kullanarak TempDB dosyalarının boyutunu set edelim. Ben örneğimde data file ını 100 MB a, log file ını 10 MB a set edeceğim. 

    Res5
  7. Command Prompt ekranında CTRL+C ye basarak ekranı kapatalım ve Configuration Manager dan SQL Server Service ini start edelim.
  8. 1.Script i tekrar çektiğimizde Data file ın 100 Mb log file ın 10 MB olduğunu göreceğiz. 

    Res6

 

Yöntem 2  - DBCC SHRINKDATABASE

Bu yöntemde DBCC SHRINKDATABASE komutunu kullanarak tempdb veritabanını shrink edeceğiz. Bu komut “target_percent” adında bir parametre almaktadır. Bu parametre de shrink işlemi bitirildikten sonra file larda kalması planlanan boş yer miktarıdır. Örneğin parametreyi %10 olarak verirsek shrink işlemi bittikten sonra data ve log file larının içinde %10 arlık boş alanların bırakılmasını istediğimizi belirtmiş oluruz.

  1. 2 nolu script i kullanarak file boyutlarını tekrar arttıralım.
  2. 1 nolu script i kullanarak tempdb file larının aldığı boyutu görelim. 

    Res7
  3. SHRINKDATABASE komutu ile veritabanını shrink edelim.
    	
        DBCC SHRINKDATABASE (tempdb, 10)	
        
    Res8
  4. 1 nolu script i tekrar kullanarak file boyutlarını kontrol ettiğimizde boyutların düştüğünü göreceğiz. 

    Res9

 

Yöntem 3 - DBCC SHRINKFILE

DBCC SHRINKFILE ın DBCC SHRINKDATABASE den en büyük farkı DB bazında değil file bazında shrink yapabiliyor olmaktır. Bu şekilde bütün DB üzerinde shrink işlemi yapmaktansa sadece shrink yapılmak istenen file üzerinde çalışılabilir. SHRINKFILE da SHRINKDATABASE gibi parametre almaktadır. Yalnız bu sefer oran bazında değil MB bazında parametre kullanılır ve shrink yapılmak istenen file ın shrink işleminden sonra olması planlanan boyutu parametre olarak verilir.

  1. 2 nolu script i kullanarak file boyutlarını tekrar arttıralım.
  2. 1 nolu script i kullanarak tempdb file larının aldığı boyutu görelim. 

    Res10
  3. SHRINKFILE komutu ile primary file ı shrink edelim ve boyutunu 50 MB a getirelim.
    DBCC SHRINKFILE (tempdev, 50)

    Res11

  4. 1 nolu script i tekrar kullanarak file boyutlarını kontrol ettiğimizde primary file ın düştüğünü göreceğiz. 

    Res12

 

ÖZET

Bugünkü yazımda production ortamlarında sıklıkla başımıza gelebilecek olan TempDB database boyutunun artması sonucu bu boyutu nasıl düşüreceğimizi inceledik. 3 yöntemden size en uygun geleni kullanarak TempDB veritabanını shrink edebilirsiniz.

 

İyi Çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server 2008 Cluster bir ortamda node un UP olup olmadığı belirli aralıklarla check edilir. Bugünkü yazımda Windows Server level ında ve SQL Server level ında bu kontrollerin ne olduklarını ve eğer kontrol başarılı olmazsa nasıl fail edildiğini anlatıyor olacağım.

[more]

Validation amaçlı Windows Server ve SQL Server level ında farklı kontroller yapılmaktadır.

Windows Level Check

  • Pasif olan node aktif olan node a “heartbeat” sinyali göndererek UP olup olmadığını kontrol eder.

SQL Server Level Check

  • Looks Alive : SQL Server Service inin UP olup olmadığı kontrol edilir. Default kontrol sıklığı 5 sn dir. Bu değerin değiştirilmesi mümkündür. Yazımın ilerleyen bölümlerinde bunu anlatıyor olacağım.
  • ISAlive : DB Engine üzerinde “Select @@servername” gibi basit bir sql komut çalıştırılarak DB Engine in UP olup olmadığı kontrol edilir. Default kontrol sıklığı 60 sn dir ve Looks Alive gibi bunun da değiştirilmesi mümkündür. Bu kontrol ile sadece SQL Server ın ve master db nin up olup olmadığı kontrol edilir. User Database ler ile ilgili bir kontrol yapılmaz. 

SQL Server profiler dan IsAlive kontrolünün 60 sn de bir nasıl gerçekleştiğini trace edebiliriz. Bu aşamada not düşmek istediğim bir konu var. IsAlive kontrolünü Windows Cluster Service Account u yapmaktadır. Dolayısıyla bu account un SQL Server login lerinde olması ve best practise olarak sysAdmin olması önerilmektedir.

Clipboard01 

Eğer Looks Alive hata alırsa IsAlive kontrolü hemen gerçekleştirilir. Eğer IsAlive kontrolüde hata alırsa bu kontrol 5 kez daha gerçekleştirilmeye çalışır. 5 kontrolün sonucunda da hata alınmaya devam ederse SQL Server Resource grubu fail eder. Bunun neticesinde yapılan ayarlamalara göre grup restart olmaya çalışır yada diğer node a taşınmaya çalışır.

Looks Alive ve IsAlive Ayarları

Looks Alive ve IsAlive kontrollerinin ayarlandığı yer her resource grubun advance tabıdır. Örneğin SQL Server Resource Grubunun advance tab ına bakacak olursak;

Clipboard02

Interval değerlerinin resource type dan alınsın şeklinde set edildiğini görüyoruz. Bu ekranda specify value değerleri ile oynayarak bu resource gruba has interval değerleri kullanabiliriz.

Yukarıdaki örnekte olduğu gibi resource type dan bu bilgi alınsın dendiğinde ise SQL Server resource örneği için Cluster Configuration >> Resource Types >> SQL Server >> Sağ Tık >> Properties ekranından bu değerlere erişebiliriz.

Clipboard03

Bu ekranda yapacağınız değişiklikler “Use Value from Resource Type” seçeneği işaretlenmiş bütün SQL Server Resource ları için geçerli olacaktır.

 

İyi çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Merhabalar,

Bu makalemde sizlere uzun zamandır yazmak istediğim bir konu olan SSIS deki FTP Task tan bahsedeceğim. FTP Task adından da anlaşılacağı gibi, SQL Server Integration servisinin ftp sunucuları ile iletişimini sağlayan bir kontrol akış nesnesi, peki bu nesne ne amaçlı kullanılabilir.

Örneğin sürekli veritabanında sakladığınız bazı bilgiler var ve siz bunları belli zaman aralıkları ile sorgular farklı bir dosya yapısında farklı lokasyonlara yüklemek isteyebilirsiniz, bu örnekte farklı lokasyon bir ftp sitesi olduğu durumlarda bu işi artık FTP Task kontrol akış nesnesi ile otomatik sağlayabilirsiniz. Şimdi bu senaryonun gerçekleştirimini bir örnek ile anlatalım.

[more]

Visual studiomuzu açıyoruz ve yeni bir “Integration Services” projesi oluşturuyoruz.

image001

Projemiz boş olarak açıldı, ilk olarak veri kaynaklarımızı hazırlıyoruz.

Solution explorer da bulunun data sources folderında sağ tuşa basarak new datasource a basıyoruz.

image002

Öncelikle verileri alacağım veri kaynağını tanımlıyorum.

image003

Şimdi bu bağlantıyı kullanarak SQL Server dan bir sorgu çalıştırıp bunun sonucunu bir text dosyaya aktaralım. Bunun için toolbox dan bir Data Flow Task nesnesi koyalım

image004

Şimdi bu data flow task içinden gerekli ayarlamalarımızı yapalım.

Data flow task nesnesine çift tıklayarak içine girelim ve bir OleDB Data Source nesnesi koyalım

image005

Bu OLE DB source nesnesini “select * from sys.databases” sorgusunu çalıştıracak şekilde ayarlayalım

Bunun için önce, daha önceden hazırladığımız ortak veri kaynaklarını paketimize import edelim.

image006

image007

Bu işlemden sonra Connection manager menüsünde aşağıdaki gibi ortak veri kaynağımızda tanımlanan nesneyi görmemiz gerekir

image008

Bu işlemlerden sonra OLEDB Soruce nesnemizi yapılandırabiliriz.

image009

Gerekli ayarlamalarımız yaptıktan sonra “OK” düğmesine basarak, hedef nesnemizi ayarlamaya başlayabiliriz.

Bunun için öncelikle bir “Flat File Destination” nesnesi tanımlıyorum.

image010

“Flat File Destination” nesnesi ile “OLE DB Soruce” nesnesini birbirine bağıyoruz. Ve “Flat File Destination” nesnesini yapılandırıyoruz.

image011

Not: Bu bu örnek için flat file ımı Delimited olarak ayarladım. Sizin tercihleriniz farklı olabnilir.

Öncelikle “Data Flow Task” nesnemi çalıştırtarak test ediyorum.

image012

image013

Şimdi “Control Flow” tabına dönerek bu oluşturduğum dosyayı bir ftp sunucuya yükleyeceğim. Bunun için ilk olarak paketime bir “FTP Task” nesnesi koyuyorum.

image014

Şimdi bu FTP nesnesinin ayarlamasını yapacağım.

FTP Task nesnesinin özelliklerine girdiğim zaman ilk olarak FTP nesnesinin connection özelliğini ayarlamam gerekiyor.

image015

New connection a basarak yeni bir FTP bağlantısı tanımlayacağım.

image016

Gerekli tanımlamalarımı yaptıktan sonra bağlantıyı test edebilirsiniz.

image017

image018

Bağlantı penceresini kapattıktan sonra File Transfer özelliklerinde daha önceden hazırladığımız Flat File nesnesini belirtmeliyiz.

image019

Local path özelliğine geldiğimizde çıkan listeden New Connection a tıklayarak gönderilecek dosyayı seçmeliyiz.

image020

image021

image022

Ok düğmesine basılarak FTP editörüne dönüp RemotePath özelliğini belirlemeliyiz.

Bu özellik ftp sunucusunda dosyayı upload edeceğimiz klasörü belirler, ben bu örneğimde ftp sunusunun root klasörüne veriyi koyacağımdan dolayı bu parametreyi “/” olarak belirliyorum.

image023

Bu seçimide yaptıktan sonra FTP task editör penceresinden ok düğmesine basarak çıkmalıyız.

Son olarak bu hazırladığımız FTP taskın akışını belirlemeliyiz.

image024

Artık paketimiz çalışır ve verileri kopyalar hale gelmiştir.

Şimdi paketimizi çalıştırarak ilgili dosyayı ftp sunucusuna yüklediğini görelim.

image025

Paketimiz başarı ile çalıştı, birde ftp sitesine giderek dosyanın yüklendiğini görelim.

image026

Şimdi ikinci örneğimde ilk örnekte oluşturulan paketin parametrik hale getirilmesinden bahsedeceğim.

Konfigürasyon tanımları için bir tablom var ve ftp sunucu bilgilerini bu bu tablodan belirlemek istiyorum, bu özellik bana değişen ftp sunucu bilgilerinin dinamik bir yapıda değiştirilebileceğinide gösteriyor olacak.

image027

Şimdi paketimde FTPServer ve RemotePath adında iki değişken yaratacağım.

image028

Paketin validasyonu için geçerli bir adres tanımladım, fakat çalışma zamanında bu değerleri veritabanından alıp değiştireceğim. Bunun için öncelikle FTP Connection nesnemin bu iki özelliğini bu değişkenden okumasını sağlamam gerekiyor.

Bunun için FTP connection nesnemin ve FTP task nesnemin özelliklerinden bu değerleri set etmeliyim.

Öncelikle FTP Connection Manager nesnemin Server Name parametresini set edeceğim.

image029

Expressions a tıklayarak çıkan pencerede bu özellikleri set edeceğim

image030

Burada dikkat edilmesi gereken husus ConnectionString set edilirken aşağıdaki kurallara uyulmalıdır.
FTPSunucu:FTPPort.UserName.Password

Daha sonra FTP task nesnesinin özelliklerinde “IsRemotePathVariable” = true yaparak bu nesnenin RemotePath özelliğini set edeceğim.

image031

Bu işlemide tamamladıktan sonra artık değerleri veritabanından set etmek için paketin en başına bir Execute SQL Task yerleştirip veritabanından okuduğum değerleri değişkene yazdıracağım.

Bunun için bir Execute SQL Task nesnesi yerleştirip, General tabında Result set “Single Row Set” yapıp ve aşağıdaki gibi bir sorgu yazıyorum.

image032

select 
FTPServer=(select convert(varchar(100),ConfigValue) from ConfigTable where ConfigName='FTP Server'),
RemotePath=(select convert(varchar(100),ConfigValue) from ConfigTable where ConfigName='Remote Path')

 

Result Set tabına geçip parametre atama işini gerçekleştireceğim.

image033

Artık paketim dinamik olarak çalışmaya hazırdır.

image034

 

İyi Çalışmalar

Kadir Evciler

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


SQL Server DBA olarak ana görevlerimizden biride veritabanlarımızın periyodik olarak mantıksal ve fiziksel bütünlüklerini kontrol etmektir. Bugünkü yazımda CHECKDB, CHECKALLOC ve CHECKTABLE DBCC komutlarını kullanarak bu kontrollerin nasıl yapılacağını işliyor olacağız.

CHECKDB en kapsamlı check işlemidir ve CHECKALLOC,CHECKTABLE komutlarının yaptığı kontrolleri de içermektedir. Dolayısıyla sisteminizde CHECKDB çalıştırdıysanız ayriyeten CHECKALLOC ve CHECKTABLE çalıştırmanıza gerek yoktur.

[more]

DBCC CHECKDB


DBCC CHECKDB ile parametre olarak verilen database in bütünlük kontrolü yapılır. Bu kontrolde her index in içeriği validate edilir, FILESTREAM kullanılıyorsa metadata ve dosya sistemi arasındaki uyumluluk kontrol edilir ve service broker dataları validate edilir.

Şimdi gelin DBCC CHECKDB komutu çalıştırıp sonucuna göz atalım, daha sonra bu komut için kullanılabilecek parametreleri inceleyelim.

DBCC CHECKDB
GO


İlk satırlarda service broker kontrollerini görüyorsunuz. Bunun akabinde database de bulunan her table için bütünlük kontrollerinin sonuçları bulunmakta.

There are 20777 rows in 96 pages for object "Person.BusinessEntity".
DBCC results for 'Production.ProductReview'.

Her table için içerdiği kayıt bilgisine bu kayıtların kaç page e dağıldığı bilgisine erişebiliyoruz. Eğer table da bulunan datalarda ya da index lerde bulunan kayıtlarda herhangi bir problem var ise çıktıda bunu görüyor oluyoruz.

Table bütünlükleri tamamlandıktan sonra çıktının en altında şöyle bir mesaj görüyoruz.

CHECKDB found 0 allocation errors and 0 consistency errors in database 'AdventureWorks2008'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Bu mesajdan veritabanımızda herhangi bir hata olmadığı bilgisine erişiyoruz. Dediğim gibi eğer sizin veritabanınızda bu tarz bir bütünlük hatası var ise en alttaki mesaj da toplamda kaç hata oluştuğunu izliyor olacaksınız.

Şimdi DBCC CHECKDB komutunun parametrelerine bakalım.

database_name - database_id

CHECKDB komutu database_name yada database_id parametresi verilerek çalıştırılabilir. Eğer bu parametre verilmezse ya da 0 verilirse o anda aktif olan DB için bu komut çalışır.

--AdventureWorks2008 te çalıştırmak için
DBCC CHECKDB('AdventureWorks2008')
GO

 

NOINDEX

Kontrol esnasında Non-Clustered index lerin kontrol edilmemesi için bu parametreyi kullanabilirsiniz. Bu şekilde kontrol daha hızlı bir şekilde bitmektedir. Yalnız şunu ekleyelim bu parametre system table larını etkilememekte, system table larında her daim index kontrolü yapılmaktadır.

DBCC CHECKDB('AdventureWorks2008', NOINDEX)
GO

 

REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD

Index datalarında ya da table datalarında kayıt problemi var ise bunun raporlanacağını belirtmiştik. REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD parametreleri ile bu bulunan hataların düzeltilmesi sağlanabilir. Bu komutların kullanılabilmesi için database in Single User Mode da olması gerekmektedir.

  • REPAIR_ALLOW_DATA_LOSS: Bütün raporlanan hataları düzeltmeye çalışır. Bu düzeltme işleminde data kaybı ihtimali vardır. Bu yüzden bu parametrenin kullanılmasındansa en son alınmış bir full backup ın dönülmesi önerilir. Genede kullanmaya karar verirseniz başlamadan önce sisteminizin full backup ını almanızı öneririm.
  • REPAIR_REBUILD : Data kaybı olmadan hata düzeltmeye olanak sağlar. Bu hata düzeltmeye non-clustered index de ki eksik kayıdın eklenmesi ya da bir index in rebuild edilmesi örnek olarak verilebilir.
ALTER DATABASE AdventureWorks2008 SET SINGLE_USER
GO
DBCC CHECKDB('AdventureWorks2008', REPAIR_REBUILD) 
GO
ALTER DATABASE AdventureWorks2008 SET MULTI_USER
GO

 

TABLOCK

CHECKDB internal bir database snapshot kullanılarak işletilir. TABLOCK parametresi ile snapshot kullanmak yerine database exclusive lock kullanılır. TABLOCK parametresi işlemin daha kısa sürmesini sağlarken, exclusive lock sebebiyle database e erişimi bir süreliğine durdurur.

DBCC CHECKDB('AdventureWorks2008') WITH TABLOCK
GO

 

ESTIMATEONLY

CHECKDB komutu için TempDB de kullanılacak alanın tahmini değerini görmek için kullanılabilir.

DBCC CHECKDB('AdventureWorks2008') WITH ESTIMATEONLY
GO

 

PHYSICAL_ONLY

CHECKDB nin limitli versiyonudur. Full versiyona göre daha kısa sürdüğü için production ortamlarında kullanılması tavsiye edilir. Tabi genede arada bir full scan yapmak gerekir.

DBCC CHECKDB('AdventureWorks2008') WITH PHYSICAL_ONLY
GO

 

Yazının geri kalan kısmında CHECKALLOC ve CHECKTABLE DBCC komutlarını işliyor olacağız. Bu komutların parametreleri CHECKDB ye çok benzediği için parametreleri geçerek direk komut sonuçlarını inceleyeceğiz.

 

DBCC CHECKDB


Database in dosya sistemi yapısı hakkında bütünlülük kontrolü yapar.Örnek kullanımı aşağıdaki gibidir

DBCC CHECKALLOC('AdventureWorks2008')
GO

 

Daha öncede söylediğim gibi CHECKALLOC CHECKDB nin yaptığı kontrollerin tamamını yapmaktadır. Fakat CHECKDB dosya sistemi yapısı açısından daha detaylı bilgi vermektedir. Örneğin aşağıdaki rapor sonucunda sysobjects tablosunun data ve index page lerinin yapılarını detaylı olarak kontrol edebilmekteyiz.

Table sysobjects                Object ID 1.
Index ID 1         FirstIAM (1:11)   Root (1:12)    Dpages 22.
    Index ID 1. 24 pages used in 5 dedicated extents.
Index ID 2         FirstIAM (1:1368)   Root (1:1362)    Dpages 10.
    Index ID 2. 12 pages used in 2 dedicated extents.
Index ID 3         FirstIAM (1:1392)   Root (1:1408)    Dpages 4.
    Index ID 3. 6 pages used in 0 dedicated extents.
Total number of extents is 7.

 

 

DBCC CHECKTABLE


Parametre olarak verilen table veya indexed view in tüm page ve yapısı hakkında bütünlülük kontrolü yapar. Kullanımı aşağıdaki gibidir.

DBCC CHECKTABLE ('HumanResources.Employee');
GO

 

Örnek rapor sonucu ise aşağıdaki gibidir.

DBCC results for 'HumanResources.Employee'.
There are 290 rows in 7 pages for object "HumanResources.Employee".
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

ÖZET

Bugünkü makalemde periyodik olarak database lerimizin bütünlülük kontrolünün DBCC komutlarıyla nasıl yapılabileceğini gördük. Database lerin sağlıklı olarak çalışabilmesi için önemli olan bu kontrolleri maintenance planımıza eklemenin faydalı olacağını söyleyerek yazımı noktalıyorum.

 

İyi çalışmalar,

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan


Bugünkü yazımda SQL Server Analysis Service te kullanılan OLAP Database lerinin nasıl yedekleneceğini ve yedeklenen bu backup dosyaları kullanılarak nasıl restore yapılacağını görüyor olacağız.

[more]

  1. Yedeklenecek veritabanına sağ tıklayıp backup linkine tıklayalım.

    image
  2. Gelen ekranda Browse kısmından backup dosyasına bir ad verelim. Bu arada browse kısmında sadece belirli folder ların göründüğü dikkatinizi çekecektir. Bu ayarlamanın nereden yapıldığına bakmak için Instance ın üstüne sağ tıklayıp açtığınız properties kısmında ki BackupDir kısmını kullanabilirsiniz.

    image
    image 

    Tekrar backup ekranına dönecek olursak; sıkıştırma yapmak istemediğimizden dolayı Apply compression yazısının check ini kaldırıyoruz. Son olarak Şifreleme yapmak istiyorsak password bilgisini girip OK e basıyoruz ve backup işlemini tamamlıyoruz.

    image
  3. Şimdi backup ladığımız bu veritabanı restore etmeye çalışalım. Bunun için Database yazısına sağ tıklayıp restore linkine tıklayalım.

    image  
  4. Gelen ekranda browse kısmından backup dosyamızı bulup seçelim ve OK e basalım.

    image
  5. Restore Database ekranında database in ismi yani DenemeDB bilgisini girelim. Ayrıca olan bir database in üstüne restore etmek istediğimiz için Allow database overwrite yazısınıda seçerek OK e basalım ve restore ü başlatalım.

    image
  6. Restore işlemi tamamlandığında ekran kapanacaktır.

 

İyi çalışmalar

Turgay Sahtiyan

Not : Blog haricinde, faydali gördügüm yazilari ve linkleri twitter adresimden paylasiyorum. Beni twitter'da takip etmek için : twitter.com/turgaysahtiyan