SQL Server Indonesia User Groups Community November 2008 - Posts - Baby SQL ... (^.^)
Welcome to SQL Server User Group Indonesia
Sign in JoinHelp | Sign In Live ID

November 2008 - Posts

Monitoring Resource Governor

Ada beberapa cara untuk memonitor resource governor yang telah kita apply:

Dengan menggunakan Performance Counter:
    -  SQLServer: Resource Pool Stats
    -  SQLServer: Workload Group Stats
Kita juga bisa melihat performance counter melalui DMV: sys.dm_os_performance_counters

DMVs:

  1. sys.dm_resource_governor_configuration (in memory configuration): memperlihatkan semua resource governor yang ada di instance tersebut, baik yang sudah di-"Reconfigure" maupun tidak. Untuk metadata configuration, anda bisa menggunakan sys.resource_governor_configuration
  2. sys.dm_resource_governor_resource_pools (in memory configuration): memperlihatkan kondisi, statistik dan configuration dari pool yang sudah kita buat. Untuk metadata configuration, anda bisa menggunakan sys.resource_governor_resource_pools
  3. sys.dm_resource_governor_workload_groups (in memory configuration): memperlihatkan kondisi, statistik dan configuration dari workload yang ada di instance tersebut. Untuk metadata configuration, anda bisa menggunakan sys.resource_governor_workload_groups

 

in memory configuration dan metadata configuration hanya akan berbeda apabila ada perubahan pada resource governor yang blum di-apply dengan perintah ALTER RESOURCE GOVERNOR RECONFIGURE

Posted by David | with no comments
Filed under:

Step by step: Resource Governor

Ada banyak referensi yang menjelaskan apakah resource governor, oleh karena itu, tanpa basa-basi, mari kita langsung mencoba membuat resource governor:

1.  Buat Resource Pool:

CREATE RESOURCE POOL [PoolName] WITH (

  MIN_CPU_PERCENT=[value],
  MAX_CPU_PERCENT=[value],
  MIN_MEMORY_PERCENT=[value],
  MAX_MEMORY_PERCENT=[value]

) ;
GO

Sebagai contoh, jika kita ingin membuat resource pool dengan nama NoPagingReportPool dan Max CPU 40%, maka script diatas menjadi:

CREATE RESOURCE POOL NoPagingReportPool
WITH (MAX_CUP_PERCENT = 40);
GO;

Dengan menggunakan sys.dm_resource_governor_resource_pools, anda bisa melihat daftar resource pool yang ada pada instance tersebut.
Ada 2 pool yang dibuat oleh system: internal dan default; dimana internal adalah pool yang melayani system background task dan tidak mempunyai batasan resource, "default" adalah pool yang akan digunakan oleh setiap connection secara default apabila tidak ada workload group yang terdaftar untuk connection tersebut.
Maximum jumlah pool adalah 20, tapi dengan unlimited workload group.

2.  Buat workload group

CREATE WORKLOAD GROUP [groupname]
USING [PoolName]
GO;

Sebagai contoh, untuk membuat workload group dengan nama ReportTeamGroup yang akan menggunakan  NoPagingReportPool sebagai Resource Pool-nya, maka script-nya menjadi:

CREATE WORKLOAD GROUP ReportTeamGroup
USING NoPagingReportPool;
GO;

3.  Jalankan Resource Governor Reconfigure untuk di-reconfigure sesuai dengan perubahan yang telah kita apply:

ALTER RESOURCE GOVERNOR RECONFIGURE;
GO;

4.  Buat Classifier Function baru yang mengembalikan nama dari Workload Group yang akan digunakan:

CREATE FUNCTION classfier_sql01()
RETURNS SYSNAME WITH SCHEMABINDING
AS
BEGIN

<your logic>

RETURN 'Default';

END;
GO;

Pada logic, anda juga bisa menggunakan beberapa function yang bisa membantu anda meng-klasifikasikan, seperti HOST_NAME, APP_NAME, SUSER_NAME, ORIGINAL_DB_NAME, IS_MEMBER dan CONNECTIONPROPERTY.

 

5.  Daftarkan function yang telah kita buat:

ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNTION = nama_classifier_function);
GO;

Untuk melihat daftar classfier function yang telah didaftarkan, kita bisa melihatnya melalui: sys.dm_resource_governor_configuration.

 

Untuk melakukan test terhadap resource pool yang anda gunakan, anda bisa menggunakan PerfMon. Di perfmon tool, pilih counter object yang bernama MSSQL$NAMAINSTANCE:RESOURCE GOVERNER, kemudian add "CPU Usage %" dengan instance yang dipilih adalah nama Poolnya (contoh: NoPagingReportPool).

 

Ref: http://msdn.microsoft.com/en-us/library/bb933866.aspx

Dedicated Administrator Connection

Kadang kita tidak bisa menarik data / connect ke database server yang load-nya cukup padat, bahkan RDP pun kadang2 nggak memungkinkan. Beberapa orang berpikir "Lebih baik gw restart servernya dan server kembali active". Sayangnya, cara ini terlalu terburu-buru dan tidak akan menemukan sumber masalah yang potential akan berulang berkali-kali. (Kecuali kalau perintah "KILL" tidak berfungsi)

Untuk menggunakan DAC, kita harus meng-configure SQL Server untuk dapat menerima DAC secara remote, dengan menjalankan:

sp_configure "remote admin connections", 1
GO
RECONFIGURE WITH OVERRIDE
GO

tapi anda bisa juga meng-configure melalui SQL Server Surface Configuration.

Untuk masuk melalui DAC, kalau menggunakan SQL Server Management Studio, di field "Server Name" kita tinggal menambahkan "ADMIN:" + nama server, menjadi: "ADMIN:[Server\Instance Name]".

 

Setelah connect ke Server melalui DAC, ada beberapa hal yang bisa kita lakukan dalam meng-investigasi apa yang menyebabkan kita tidak bisa connect ke server tersebut melalui port biasa, antara lain:

    1. Query ke DMV [Dynamic Management View]:
      a. sys.dm_tran_locks: mengetahui resources mana yang sedang di-lock atau yang masih "waiting"
      b. sys.dm_os_memory_cache_counters: mengetahui keadaan cache (snapshot)
      c. sys.dm_exec_requests: menunjukan semua request yang sedang dieksekusi'
      d. sys.dm_exec_sessions: menunjukan semua session yang ada di serve
    2. Gunakan DBCC:
      a. DBCC FREEPROCCACHE: Membebaskan plan yang ada di plan cache
      b. DBCC FREESYSTEMCACHE: Membebaskan cache yang sudah tidak terpakai
      c. DBCC DROPCLEANBUFFERS: Menghapus semua buffer yang tidak terpakai lagi dari buffer pool
      d. DBCC SQLPERF: mengetahui detail log dari semua database
    3. Gunakan T-SQL: "KILL"

 

Informasi lebih detail, silakan ke http://msdn.microsoft.com/en-us/library/ms189595.aspx

Posted by David | with no comments
Filed under:

Performance Counter untuk Database Mirroring

Beberapa performance counter yang biasa digunakan untuk memonitor aktifitas Database Mirroring di SQL Server 2008:

  • Log Bytes Redone from Cache/sec (Higher is better) – Mirror server counter
    Banyaknya Transaction Log (Bytes) yang bisa diambil dari redo queue yang ada di cache.
  • Log Bytes Sent from Cache/sec (Higher is better) – Mirror server counter
    Jumlah Transaction log yang bisa dikirim (dalam bytes) dari principal ke mirror dengan membaca Transaction Log cache-nya. Kedua aktifitas ini, mengambil transaction log dari cache, karena lebih cepat dari pada mengambil dari disk.
  • Log Harden Time (ms) (Lower is better) – Mirror server counter
    Memonitor berapa lama waktu yang dihabiskan sejak Log diterima oleh mirror server hingga selesai ditulis ke database log disk
  • Log Compressed Bytes Rcvd/sec 
  • Log Compressed Bytes Sent/sec (Higher is better)
    Kedua Counter ini bisa digunakan untuk memonitor besarnya compressed, dengan membandingkan nilai performance counter ini dengan Log Bytes Sent dan Log Bytes Received
  • Log Send Flow Control Time (ms) (Lower is better)
  • Mirrored Write Transactions/sec (Higher is better)
  • Send/Receive Ack Time (Lower is better)

 

ref: SQL Server Books Online: http://msdn.microsoft.com/en-us/library/ms189931.aspx

Posted by David | with no comments

Error 823, 824 dan 829 pada database mirroring di SQL Server 2008

Di SQL Server 2008, apabila ada yang mencoba mengakses page yang corrupt pada principal di database mirroring, otomatis akan diperbaiki dengan mencari bagian hilang di mirror-nya (begitu juga sebaliknya). Hal ini dianggap sebagai P3K (Pertolongan Pertama Pada Kecelakaan... hehehe) yang dilakukan untuk menjaga availability dari database tersebut.

 

Error yang akan diterima apabila page yang kita akses ternyata corrupt (atau terdeteksi dengan menggunakan DBCC), yaitu:

  1. Error 823: SQL request ke OS untuk baca page-nya, tapi OS tidak bisa retrieve page tersebut; atau Error 824: OS bisa baca page-nya, tapi SQL men-deteksi kalau ternyata page tersebut corrupt.
  2. Error 829: selama perbaikan (yang otomatis dilakukan oleh SQL) masih berlangsung, apabila ada yang melakukan query ke page yang sedang diperbaiki tersebut, maka akan dikirim Error 829 ini sebagai resultnya.

 

Selama perbaikan, event log akan mencatat:

Database mirroring is attempting to repair physical page <page number> in database <database name> by requesting a copy from the partner

dan kemudian,

Database mirroring successfully repaired physical page <page number> in database <database name> by obtaining a copy from the partner

 

Pesan dari sponsor:

Perbaikan ini dilakukan secara otomatis, tapi bukan berarti perkejaan kita selesai. Kita tetap punya PR untuk mencari tahu sumber kerusakan yang menyebabkan data corrupt ini.

Posted by David | with no comments

Penyempurnaan DBCC CHECKDB di SQL Server 2008

DBCC digunakan untuk mengetahui database corruption lebih dini, yang pada umumnya terjadi karena masalah I/O. Pada saat DBCC CHECKDB diexecute, pertama-tama dia akan mengecek apakah ada corrupt pada databasenya. Kalau ada corrupt, dia akan mengecek ulang dari awal dengan lebih detail untuk mengetahui lokasi bagian yang corrupt tersebut (DEEP DIVE). Sayangnya, process ini akan memakan resource yang cukup banyak dengan waktu yang relatif lama.

Di SQL Server 2005 SP 2, apabila terjadi DEEP DIVE, DBCC akan menghasilkan error output:

DBCC CHECKDB is performing an exhaustive search of indexes for possible inconsistencies.  This is an informational message only. No user action is required.

Di SQL server 2008, nama-nama table yang sedang di scan untuk kedua kalinya (DEEP DIVE), akan tertulis di Error output tersebut. Hal ini membantu kita untuk lebih cepat mengetahui tabel mana yang memiliki bagian yang corrupt.

Posted by David | with no comments
Filed under: ,

Email : Reporting and Logging of Maintenance Plans

Di Reporting and Logging SQL server 2005 Maintenance Plans, terdapat pilihan “Send Report to an email recipient”, dimana kita bisa mengirim laporan / log dari subplan ke email address yang sudah terdaftar sebagai Agent Operator.

Yang harus disiapkan terlebih dahulu adalah Database Mail dan Agent Operator:

  1. Database Mail configuration
    • Pilih ”Configure Database Mail” dari context menu “Database Mail” yang ada di folder “Management” pada server anda
    • Kemudian Pilih “Set up Database Mail by performing the following tasks:…”
    • Masukan nama profilenya di field “Profile name” (ini tidak bisa di-edit lagi atau permanent)
    • click tombol [Add] pada bagian “SMTP accounts”
    • Apabila anda belum pernah create “Database Mail account” anda bisa click tombol [New Account] untuk create account baru.
    • Pilih account name (anda bisa menggunakan account yang baru anda buat)
    • Tekan [OK], kemudian akan muncul account yang dipilih di table “SMTP Accounts”
    • Tekan Tombol [Next] apabila anda sudah selesai
    • Anda akan melihat “Manage Profile security”, di tab “Public Profiles” pilih Profile name yang akan menjadi default profile dengan cara mengganti nilai “Default Profile” menjadi ‘Yes”
    • Tekan tombol [Next], setelah itu anda akan melihat “Configure System Parameters” wizard
    • Tekan tombol [Next] lagi kemudian tekan tombol [Finish]
  2. Agent Operator
    • Pilih menu “New Operator” pada context menu dari folder “Operators” yang ada di “SQL Server Agent” dari server anda
    • Masukan detail operator-nya, terutama “Name” dan “email name”
    • Tekan [OK]

Setelah keduanya sudah disiapkan, silakan anda ke maintenance plan-nya, tekan tombol [Reporting and Logging] di bagian atas layar. Kemudian pastikan anda memilih “Send Report to an email recipient” dan memilih agent operator yang telah anda buat. Tekan tombol [OK] dan save pekerjaan anda.

 

Untuk mengetest nya, silakan jalakan subplan job anda, yang ada di folder “Jobs” dari “SQL Server Agent”-nya.

Posted by David | with no comments
Filed under:
More Posts