TechNet Szeminárium előadások 2002 tavasz 2002. 02. 20. SQL Server adatbázisok adminisztrációja 2002. 03. 06. Windows alapú webes alkalmazások 2002. 03. 20. Biztonságos Windows 2002. 04. 03. Vállalati szintű projektmenedzsment 2002. 04. 17. Üzemeltetői konferencia 2002. 05. 08. A Windows .NET Server technikai újdonságai

SQL Server 2000 adminisztráció 2002. február 20. SQL Server 2000 adminisztráció Kószó Károly rendszermérnök Microsoft Magyarország

Napirend SQL Server 2000 Rendelkezésre állás A magas rendelkezésre állás áttekintése Katasztrófa megelőzés Katasztrófa utáni helyreállítás A magas rendelkezésre állás fenntartása SQL Server 2000 teljesítmény hangolás Méretezés Zárolás A Query Processor A lekérdezések hangolása Az SQL Server konfigurációs paraméterei Teljesítmény adatok gyűjtése és elemzése

SQL Server 2000 rendelkezésre állás 2002. február 20. SQL Server 2000 rendelkezésre állás Kószó Károly rendszermérnök Microsoft Magyarország

Napirend A magas rendelkezésre állás áttekintése Katasztrófa megelőzés Hibatűrő diszk megoldások Fürtözött SQL Server Katasztrófa utáni helyreállítás Napló alapú szinkronizálás (log shipping) Replikáció Mentés és helyreállítás (Backup/Restore) A magas rendelkezésre állás fenntartása

A rendelkezésre állás meghatározása A = ((F) - (R))/(F) F = a meghibásodások közötti (átlagos) idő R = a javítás (átlagos) ideje A javításra fordítható idő egy év alatt, adott rendelkezésre állás esetén 99% 87 óra 99.9 8,7 óra 99.99 52 perc 99.999 5 perc

Célok és korlátok Hány kilences rendelkezésre állást szeretnénk? Mik a korlátozó tényezők, hibaforrások? Számítógép hardware Kommunikáció, adatkapcsolat Környezet (telephely, tápellátás, gépterem, ...) Szolgáltatások (szerviz, termék támogatás) Software (Windows, SQL Server, Service Pack, egyéb sw) Folyamat (üzemeltetési előírások, katasztrófa terv, …) Alkalmazás hibák, felhasználói tévedések Alkalmazottak (képzett rendszergazdák, programozók, …) Veszteség – költség összevetés Mi az adott hiba felmerülésének valószínűsége

SQL Server szolgáltatások Fürtözés (failover clustering) Napló alapú szinkronizálás (log shipping) Replikáció Mentés, helyreállítás (backup, restore)

A tartalék rendszerek típusai Meleg (hot) tartalék Az adatok tranzakcionálisan aktuális másolata Automatikus hiba észlelés Automatikus átállás Langyos (warm) Az elsődleges adatok konzisztens, esetleg nem teljesen aktuális másolata Fél-automatikus hiba észlelés és átállás Hideg (cold) Szükség esetén felhasználható tartalék hardware, telepítő készletek

A tartalék megoldások jellemzői A tartalék típusa A hiba észlelés módja Automatikus átkapcsolás Védelem diszk hibák ellen Meta adatok védelme Tranzakcionális konzisztencia Tranzakcionálisan aktuális Hatása a teljesítményre Az átállás ideje Telephelyek távolsága Bonyolultság Számítógépek száma Egyéb hasznosítási lehetőség (pl. jelentés készítés) Az adatok újra partícionálhatósága

Öt kilences példa Elvárt rendelkezésre állás: 99.999% 5.26 perc kiesés lehet évente Évente egy (!) szerviz csomagot kell telepíteni 20 perc kiesés Évente egy software frissítés várható 1 óra kiesés Lehetséges megoldás: Failover Clustering Tartalék adatbázis másolat (Log Shipping, tükrözés, stb.) A cluster karbantartás idejére az alkalmazások a tartalék adatbázis másolatot használják

Hibatűrő diszk megoldások Redundant Array of Independent Disks (RAID) A RAID előnyei Teljesítmény, tároló kapacitás, megbízhatóság RAID szintek 0, 1, 5, 0+1, 1+0 (10) Hardware és software RAID

RAID 0 Diszk csíkozás (striping) Több meghajtó Az írások egyenletesen elosztódnak a meghajtók között Nem hibatűrő! Kiváló teljesítmény data DISK3 DISK2 DISK1

RAID 1 A második (harmadik) meghajtó az első pontos másolata Diszk tükrözés A második (harmadik) meghajtó az első pontos másolata N-1 meghajtó elvesztését elviseli Kiváló olvasási teljesítmény Jó írási sebesség A tranzakció napló számára jó DISK3 data copy ´ DISK2 data DISK1 data copy ´´

RAID 5 Min. 3 meghajtó Egy meghajtó elvesztését elviseli Diszk csíkozás paritással Min. 3 meghajtó Egy meghajtó elvesztését elviseli Jó olvasási, rossz írási sebesség, különösen soros írás esetén A tranzakció naplót NE tegyük RAID 5-re! parity data DISK3 DISK2 DISK1

RAID 0+1 Csíkozott diszkek tükrözése Min. 4 meghajtó Csíkkészletenként egy meghajtó elvesztését tűri (A RAID 5-höz hasonló) Kiváló teljesítmény; jó hibatűrés Adat file-ok számára ajánlott DISK6 DISK5 DISK4 data DISK3 DISK2 DISK1

RAID 1+0 (RAID 10) Min. 4 meghajtó Tükrözött diszkek csíkozása Min. 4 meghajtó Minden tükör pár egyik felének elvesztését elviseli – a RAID 1-hez hasonlóan Jó teljesítmény - kisebb mint a 0 + 1 esetén; kiváló hibatűrés Adat file-ok számára ajánlott DISK6 DISK4 DISK2 data DISK5 data DISK3 parity DISK1 data data data parity data data data parity data data data data data data data data data parity data data data parity data data data parity data data data data data data data

Példa: RAID az SQL Serverrel FileA File csoport FileB FileC Diszk vezérlő FileD Diszk vezérlő FileE FileF FileG FileH Diszk vezérlő Tranzakció napló Op. rendszer

Fürtözött rendszerek A fürtözés (clustering) különböző formái Windows Cluster Infrastruktúra szervizek, szolgáltatások számára SQL Server Failover Cluster Magas rendelkezésre állást biztosító SQL Server szolgáltatás a Windows Cluster alapján Federated SQL Server Cluster Független SQL Serverek „szövetsége”; partícionált adatok, nagy OLTP teljesítmény Network Load Balancing cluster Magas rendelkezésre állás és skálázhatóság TCP/IP alapú szolgáltatások számára

SQL Server 2000 Failover Cluster Nyilvános hálózat SQL Server 2000 Virtual Server MSCS MSCS Heartbeat Node A Node B Osztott diszk tömb

Az SQL Server 2000 Failover Cluster működése Az operációs rendszer ellenőrzi a csomópontok és virtuális kiszolgálók létezését Heartbeat Az SQL Server ellenőrzése: Looks-alive – gyors ellenőrzés, 5 másodpercenként IsAlive - SELECT @@SERVERNAME Ha az IsAlive sikertelen, 5 újabb próbálkozás Failover (áttérés) másik csomópontra A Windows Clustering megkísérli az SQL Server újraindítását az eredeti helyén; sikertelen újraindítás esetén egy másik csomóponton próbálkozik. Az SQL Server Service elindul Az SQL Server helyreállítja az adatbázisokat (recovery) Az alkalmazások újra rákapcsolódnak az SQL Serverre

SQL Server 2000 újdonságok Az SQL Server Setup telepíti (és szünteti meg) a virtuális SQL kiszolgálókat A szerviz csomagok a virtuális szerverre telepíthetők Több (max. 16) példány Failover és Failback bármely csomópontra Az SQL Server 2000 EE + Windows 2000 Datacenter Server 4 csomópontos fürtöket támogat Az SQL Server eszközök minden csomópontra feltelepülnek A Setup program aktualizálja a Cluster konfigurációt Az SQL Server Service Manager és az SQL Server Enterprise Manager használható az SQL Server szerviz indítására, leállítására A full-text keresés is fürtözhető

Az SQL Server fürtözés jellemzői A tartalék típusa Meleg (hot) A hiba észlelés módja Automatikus Automatikus átkapcsolás Igen Védelem diszk hibák ellen Nem; közös diszk Meta adatok védelme Tranzakcionális konzisztencia Tranzakcionálisan aktuális Hatása a teljesítményre Nincs / minimális Az átállás ideje Néhány perc, az újraindulás idejétől függ Telephelyek távolsága Közeli, max. kb. 150 km Bonyolultság Nem egyszerű Számítógépek száma 2 - 4 Egyéb hasznosítási lehetőség (pl. jelentés készítés) Nem Az adatok újra partícionálhatósága

Napló alapú szinkronizálás (log shipping) Az SQL Server Enterprise Edition szolgáltatása A mentés egy formája Célja: a katasztrófa utáni helyreállítás meggyorsítása Langyos (warm) tartalék Másodlagos megoldás, a Failover Clustering mellett

A Log Shipping működése Felügyelő kiszolgáló SQL Server Agent ütemezett Job-ok Elsődleges kiszolgáló Másodlagos kiszolgáló(k) 1. Log BACKUP 3. Log RESTORE WITH STANDBY 2. Log Copy (“Pull”) Log Backup

Telepítés, konfigurálás SQL Server 2000 2002. február 20. Telepítés, konfigurálás A Database Maintenance varázslóval Egyszerre egy adatbázisra A varázslóval konfigurálható A log mentések gyakorisága A log-ok átküldésének gyakorisága Az log átmásolása és a betöltés közötti idő Milyen régi legyen a log, mielőtt betöltjük A varázsló létrehozza a mentések ütemezését az adatbázisokat a fogadó kiszolgálókon Demo log shipping set up…

Clustering vagy Log Shipping? Jellemző Failover Clustering Log Shipping A tartalék típusa Meleg (hot) Langyos (warm) A hiba észlelés módja Automatikus Kézi, de NLB-vel … Automatikus átkapcsolás Igen Védelem diszk hibák ellen Nem; közös diszk Igen, de … Meta adatok védelme Csak adatbázison belül Tranzakcionális konzisztencia Tranzakcionálisan aktuális Nem, de … Hatása a teljesítményre Nincs / minimális File másolás Az átállás ideje Néhány perc, az újraindulás idejétől függ Másodpercek (a helyreállítás mértékétől függően több lehet) Telephelyek távolsága Közeli, max. kb. 150 km Tetszőleges Bonyolultság Nem egyszerű Egyszerű Számítógépek száma 2 - 4 Korlátlan (32 NLB-vel) Egyéb hasznosítási lehetőség (pl. jelentés készítés) Nem Az adatok újra partícionálhatósága

A replikáció Replikációs formák: Előfizető (subscriber) Kiadó (publisher) Elosztó (distributor) Publikáció Replikációs formák: pillanatfelvétel, tranzakcionális, összefésülő

Tartalék képzés replikációval Ha a Failover Clustering nem megvalósítható, vagy a fürtözés mellett Ha a Log Shipping nem megfelelő, például mert a tranzakciókat azonnal továbbítani akarjuk A meta adatokat nem másolja A hiba észlelés és az átállás nem automatikus A tartalék kiszolgáló nem azonos az eredetivel Az adatok aktualitása nem garantált A merge replikáció tranzakcionálisan nem konzisztens Az adatbázis újra partícionálható a fogadó gépen A tartalék adatbázis hasznosítható

Clustering, Log Shipping, replikáció Jellemző Failover Clustering Log Shipping Transactional Replication A tartalék típusa Meleg (hot) Langyos (warm) A hiba észlelés módja Automatikus Kézi, de NLB-vel … Automatikus átkapcsolás Igen Védelem diszk hibák ellen Nem; közös diszk Igen, de … Meta adatok védelme Csak adatbázison belül Nem Tranzakcionális konzisztencia Igen (kivéve: merge) Tranzakcionálisan aktuális Nem, de … Nem, de közel

Clustering, Log Shipping, replikáció Jellemző Failover Clustering Log Shipping Transactional Replication Hatása a teljesítményre Nincs / minimális File másolás Log reader Az átállás ideje Néhány perc, az újraindulás idejétől függ Másodpercek (a helyreállítás mértékétől függően több lehet) Telephelyek távolsága Közeli, max. kb. 150 km Tetszőleges Bonyolultság Nem egyszerű Egyszerű Számítógépek száma 2 - 4 Korlátlan (32 NLB-vel) Egyéb hasznosítási lehetőség (pl. jelentés készítés) Nem Igen Az adatok újra partícionálhatósága

Mentési stratégiák Mennyire fontosak az adatok? Mi veszhet el? File copy (?) – jobb, mint a semmi SQL Server leállítás, vagy detach database után Teljes adatbázis mentés DB Recovery Model = Simple Adatbázis mentés (ritkábban) és gyakori tranzakció napló mentések DB Recovery Model = Full, vagy BULK_LOGGED Differenciális mentés, a gyorsabb helyreállítás érdekében File csoport, vagy file mentés

Adatbázis és tranzakció napló Az adatbázis mentés NEM üríti a tranzakció naplót! Helyreállítás Az utolsó adatbázis mentés (2) és 3 + 1 tranzakció napló mentés betöltése Ha az utolsó adatbázis mentés nem olvashatatlan, használhatjuk a régebbi (1) mentést, csak több tranzakció napló mentést kell rátölteni Backup db 1 Backup Log Backup Log Backup db 2 Backup Log Backup Log Backup Log Hiba Backup Log with NO_TRUNCATE

Differenciális mentés Backup db 1 Helyreállítás Az utolsó adatbázis mentés (2) + a differenciális mentés + az utolsó tranzakció napló mentések betöltése A differenciális mentés gyorsíthatja a helyreállítást A tranzakció napló mentésekre szükség van a helyreállításhoz! Backup Log Backup Log Backup db 2 Backup Log Differential Backup Log Hiba Backup Log with NO_TRUNCATE

A magas rendelkezésre állás fenntartása SQL Server 2000 2002. február 20. A magas rendelkezésre állás fenntartása Számítóközpont gyakorlat biztonság, megfelelő helyiség, … A változások felügyelete (Change Control) Megfelelő személyzet biztosítása A „katasztrófa” utáni hereállítás tervezése Működési napló vezetése These will be gone into detail on the slides following

A működés folyamatos ellenőrzése SQL Server 2000 2002. február 20. A működés folyamatos ellenőrzése System Monitor/Performance Monitor Riasztások (alert-ek) SQL Profiler Az operációs rendszer és az SQL Server naplók rendszeres ellenőrzése Biztonsági auditálás Betörési kísérletek, sikertelen bejelentkezések naplózása SysMon – capture logs, mark down trends. Know how it performs at peak, at low volume, so that you can detect abnormalities that may be problems Establish a normal workload; identify SQL statements Be proactive … set levels of alerts so you do not find out when the system goes down that there is a problem Logs are key – not all events show up in PerfMon Audits can trap unauthorized access or rogue SQL Server users doing bad things

Mentés, helyreállítás Rendszeres mentés SQL Server 2000 2002. február 20. Mentés, helyreállítás Rendszeres mentés Biztonsági másolatok, a hordozók cseréje, archiválás A mentések visszatölthetőségének ellenőrzése Dokumentálás This one is pretty self explanatory – this is the admin aspect, not the solution, which is later.

A változások felügyelete SQL Server 2000 2002. február 20. A változások felügyelete Külön rendszer a fejlesztők számára, és legalább egy teszt gép a módosított alkalmazás tesztelésére Tervezés Bevezetési terv Visszagörgetési terv A változások követése 2nd, 3rd bullets – Know when something has been fully tested and can be deemed worthy. Staging environments are important for this reason. Come up with an execution plan, assign people, get signatures. Put expected timelines. The contingency plan is important – if you get to a point where your window is shriking and what you are doing is not working, know how to get back to your prior state, and make sure you know ho w long that takes

Katasztrófa terv Pontosan dokumentált lépések SQL Server 2000 2002. február 20. Katasztrófa terv Pontosan dokumentált lépések Az értesítendő személyek adatai Eszkalációs lépések Teszteljük a tervet! Pivotal – this is the execution plan for downtime (generally unplanned) … keep it up-to-date, make sure it’s well tested, and pray you never have to use it. But if it is tested, you should have the conifdence that it will work.

Működési napló Központi dokumentum tár (intranet, file-share) SQL Server 2000 2002. február 20. Működési napló Központi dokumentum tár (intranet, file-share) A katasztrófa utáni helyreállítási terv Mentési információk Személyi információ A telepítő készletek tárolási helye, licencek, kulcsok, terméktámogatók telefonszámai Rendszer konfiguráció (Op.rsz., SQL Server, SP-k, Registry beállítások, diszk konfiguráció, drive betűk) Adatbázis sémák, job-ok, spec. adatbázis opciók … These are examples, and their reasons, but there could be more depending on their environment IMPORTANT IMPORTANT IMPORTANT to have the DRP documented AND kept up-to-date Know where your backups are – don’t guess in the heat of the moment – and also record if they were good, etc. Contact – This includes a list of all personnel and all relevant contact information for them. This should include everyone: administrators, developers, help desk employees, users, and also other related systems that depend on information in this system If you need to rebuild a server … better have access to the SW & Keys Support – same basic deal – expediance is the key The rest is pretty self explanatory

Összefoglalás, mit láttunk? A magas rendelkezésre állást a hardware, a software, a folyamatok és az emberek megfelelő „együttműködése” biztosítja Katasztrófa megelőzés Hibatűrő diszk megoldások Fürtözött SQL Server Katasztrófa utáni helyreállítás Napló alapú szinkronizálás (log shipping) Replikáció Mentés és helyreállítás (Backup/Restore) A magas rendelkezésre állás fenntartása

Előadások a Weben Microsoft SQL Server 2000 Log Shipping http://support.microsoft.com/servicedesks/webcasts/wc021501/wcblurb021501.asp Introduction to Microsoft SQL Server 2000 Clustering http://support.microsoft.com/servicedesks/webcasts/wc051001/wcblurb051001.asp New Features in Microsoft SQL Server 2000 Transactional Replication http://support.microsoft.com/servicedesks/webcasts/wc111601/wcblurb111601.asp

Néhány perc szünet…

SQL Server 2000 teljesítmény hangolás 2002. február 20. SQL Server 2000 teljesítmény hangolás Kószó Károly rendszermérnök Microsoft Magyarország

Napirend SQL Server 2000 teljesítmény hangolás Méretezés Zárolás A lekérdezés feldolgozó A lekérdezések hangolása Az SQL Server konfigurációs paraméterei Teljesítmény adatok gyűjtése és elemzése

Méretezési előírások Legjobb az alkalmazás készítőjétől! Hardware gyártók eszközei: Compaq ProLiant Sizer for Microsoft SQL Server 2000 Transaction Application http://activeanswers.compaq.com/ActiveAnswers/Render/1,1027,536-6-100-225-1,00.htm Compaq ProLiant Sizer for SQL Server 2000 Data Marts http://activeanswers.compaq.com/ActiveAnswers/Render/1,1027,5276-6-100-225-1,00.htm Új alkalmazás esetén: tesztelés

Napirend SQL Server 2000 teljesítmény hangolás Méretezés Zárolás A lekérdezés feldolgozó A lekérdezések hangolása Az SQL Server konfigurációs paraméterei Teljesítmény adatok gyűjtése és elemzése

A Lock Manager feladatai SQL Server 2000 2002. február 20. A Lock Manager feladatai A zárak megszerzése és felszabadítása A zárolási módok közötti kompatibilitás fenntartása Négy ANSI / ISO izolációs szint biztosítása Serializable (3) Repeatable Read (2) Read Committed (1) - default Read Uncommitted (0)

Adat zárolási szintek Tábla Lap Lap Lap Sor Sor Sor SQL Server 2000 2002. február 20. Adat zárolási szintek Tábla Lap Lap Lap Sor Sor Sor

A megosztott (shared) zár SQL Server 2000 2002. február 20. A megosztott (shared) zár Automatikusan megszerezzük az adat olvasásakor Tábla, lap, kulcs vagy sor szintű Több adatbázis folyamat szerezhet megosztott zárat ugyanarra az adatra Read Committed izoláció esetén az adat feldolgozása után a megosztott zár felszabadul; magasabb izolációs szinteken a tranzakció végéig megmarad

A kizárólagos (exclusive) zár SQL Server 2000 2002. február 20. A kizárólagos (exclusive) zár Automatikusan megszerezzük az adat módosításakor Egyidejűleg csak egy folyamat birtokolhatja A tranzakció végéig megőrizzük A többi folyamat minden zárolási kérése várakozni kényszerül Lekérdezési „tippek” (locking hints) használhatók

A módosítás (update) zár SQL Server 2000 2002. február 20. A módosítás (update) zár A megosztott és a kizárólagos keveréke Az adat módosítás előtti keresés idején megosztott zárként viselkedik A tényleges módosításkor kizárólagos zárra vált Egy adaton több megosztott de csak egyetlen módosítás zár lehet Update locks are really not a separate kind of lock; they are a hybrid between shared and exclusive locks. They are acquired when SQL Server executes a data modification operation but first needs to search the table to find the resource that will be modified. Update locks provide compatibility with other current readers of data, allowing the process to later modify data with the assurance that the data hasn't been changed since it was last read. An update lock is not sufficient to allow you to change the data—all modifications require that the data resource being modified have an exclusive lock. An update lock acts as a serialization gate to queue future requests for the exclusive lock. (Many processes can hold shared locks for a resource, but only one process can hold an update lock.) As long as a process holds an update lock on a resource, no other process can acquire an update lock or an exclusive lock for that resource; instead, another process requesting an update or exclusive lock for the same resource must wait. The process holding the update lock can acquire an exclusive lock on that resource because the update lock prevents lock incompatibility with any other processes. You can think of update locks as "intent-to-update" locks, which is essentially the role they perform. Used alone, update locks are insufficient for updating data—an exclusive lock is still required for actual data modification. Serializing access for the exclusive lock lets you avoid conversion deadlocks. Don't let the name fool you: update locks are not just for update operations. SQL Server uses update locks for any data modification operation that requires a search for the data prior to the actual modification. Such operations include qualified updates and deletes, as well as inserts into a table with a clustered index. In the latter case, SQL Server must first search the data (using the clustered index) to find the correct position at which to insert the new row. While SQL Server is only searching, it uses update locks to protect the data; only after it has found the correct location and begins inserting does it escalate the update lock to an exclusive lock.

SQL Server 2000 2002. február 20. A szándék (intent) zár Nem igazán zár, inkább egy potenciális zárolási szándékot jelez Például, ha egy folyamat zárol egy sort, akkor a sort tartalmazó lapon és táblán egy-egy „szándék” zár keletkezik Megakadályozza, hogy a zárolt sort tartalmazó lapot, vagy táblát egy másik folyamat kizárólagosan lefoglalja Intent locks are not really a separate mode of locking; they are a qualifier to the modes previously discussed. In other words, you can have intent shared locks, intent exclusive locks, and even intent update locks. Because SQL Server can acquire locks at different levels of granularity, a mechanism is needed to indicate that a component of a resource is already locked. For example, if one process tries to lock a table, SQL Server needs a way to determine whether a row (or a page) of that table is already locked. Intent locks serve this purpose.

Speciális zár típusok Schema Stability Scheme Modification Bulk update SQL Server 2000 2002. február 20. Speciális zár típusok Schema Stability egy lekérdezés kiértékelése idején kizárja a schema modification zárakat Scheme Modification tábla szerkezet módosításakor használjuk Bulk update BULK INSERT és BCP esetén SQL Server offers three additional lock modes: schema stability locks, schema modification locks, and bulk update locks. When queries are compiled, schema stability locks prevent other processes from acquiring schema modification locks, which are taken when a table's structure is being modified. A bulk update lock is acquired when the BULK INSERT command is executed or when the bcp utility is run to load data into a table. In addition, the copy operation must request this special lock by using the TABLOCK hint. Alternatively, the table can set the table option called table lock on bulk load to true, and then any bulk copy IN or BULK INSERT operation will automatically request a bulk update lock. If multiple connections have requested and received a bulk update lock, they can perform parallel loads into the same table.

Információ a zárakról sp_lock tárolt eljárás sp_lock2 tárolt eljárás SQL Server 2000 2002. február 20. Információ a zárakról sp_lock tárolt eljárás sp_lock2 tárolt eljárás Q255596 Az sp_lock eredménye To view locks currently outstanding in the system as well as those that are being waited for, use the sp_lock or sp_lock2 stored procedures to examine the syslockinfo system table. The sp_lock stored procedure displays information similar to the displayed table, but provides numbers for the Dbid and displays all database locks including those on the system tables. The sp_lock2 procedure was used to display the information in the displayed table. It provides the database names in the Dbid field and does not display the locks on system tables. Both procedures show current and waiting locks. The information displayed shows the process requesting the lock, the database where locks are being held, an object identifier, an index identifier, the type of resource being locked, a resource description, the lock mode and its status. The sp_lock2 procedure can be found in the book Inside Microsoft SQL Server 2000. The syslockinfo table is not really a system table. It is not maintained on disk because locks are not maintained on disk. Rather, it is materialized in table format based on the lock manager's current accounting of locks each time syslockinfo is queried. Another way to watch locking activity is with the excellent graphical representation of locking status provided by SQL Server Enterprise Manager. Even those who think that GUIs are for wimps can appreciate SQL Server Enterprise Manager's view of locking. Spid Dbid Objid IndId Type Resource Mode Status 54 pubs 19723 2 TAB IS GRANT 58 19755 1 PAG 1:88 IX 52 Pubs DB S

A zárolható erőforrások SQL Server 2000 2002. február 20. A zárolható erőforrások This table provides information on the various lock types, which resources are being locked and the internal codes which are used to represent them. For instance, a table lock has an internal code of 5. There is also a description for lock types. The page lock can be described by a file number and a page number, while a row lock has a file, page and slot number. Röv. Erőforrás Belső kód Leírás / példa DB Database 2 TAB Table 5 Table id 261775902 EXT Extent 8 File/ page 1:96 PAG Page 6 File/ page 1:104 KEY Key 7 Hash ac0001a10a00 AC Row 9 File/page/slot 1:151:4 APP Application* 10 Hash MYpr8dea * sp_getapplock, sp_releaseapplock

Shared with intent exclusive SQL Server 2000 2002. február 20. A zárolási mód The sp_lock and sp_lock2 procedures only display the abbreviation of lock modes. This table displays the various lock modes and the internal codes that correspond with the abbreviations. Rövidítés Mód Belső kód S Shared 4 X Exclusive 6 U Update 5 IS Intent shared 7 IU Intent update 8 IX Intent exclusive 9 SIX Shared with intent exclusive 11 Sch-S Schema stability 2 Sch-M Schema modification 3 BU Bulk update 13

A zárak memória igénye Egy zár memória igénye SQL Server 2000 2002. február 20. A zárak memória igénye Considerable resources are required to manage locks. Recall that a lock is an in-memory structure of about 32 bytes, with another 32 bytes for each process holding the lock and each process waiting for the lock. If you need a lock for every row and you scan a million rows, you need more than 30 MB of RAM just to hold locks for that one process. Each page lock on the other hand will lock 8k of data, while a row may be much smaller than the 8k held by a page lock. Since the row level lock is dependent on row size which to use really depends on the application. Beyond the memory consumption issues, locking is a fairly processing-intensive operation. Managing locks requires substantial bookkeeping. Recall that, internally, SQL Server uses a lightweight mutex called a spinlock to guard resources, and it uses latches—also lighter than full-blown locks—to protect non-leaf-level index pages. These performance optimizations avoid the overhead of full locking. The stored procedure sp_indexoption lets you manually control the unit of locking within an index. It also lets you disallow page locks or row locks within an index. Since these options are available only for indexes, there is no way to control the locking within the data pages of a heap. (But remember that if a table has a clustered index, the data pages are part of the index and are affected by the sp_indexoption setting.) The index options are set for each table or index individually. Two options, AllowRowLocks and AllowPageLocks, are both set to TRUE initially for every table and index. If both of these options are set to FALSE for a table, only full table locks are allowed. Egy zár memória igénye Minden zár – 64 byte Minden folyamat, amely birtokolja a zárat, vagy várakozik rá – 32 byte Ha több, egymás utáni sort módosítunk, a lap szintű zárolás előnyösebb

demó Zárolás demó Query Analyzer A zárak megjelenítése

Napirend SQL Server 2000 teljesítmény hangolás Méretezés Zárolás A lekérdezés feldolgozó A lekérdezések hangolása Az SQL Server konfigurációs paraméterei Teljesítmény adatok gyűjtése és elemzése

Végrehajtási fa készítés Végrehajtási terv (optimalizálás nélkül) SQL Server 2000 2002. február 20. A fordítás Elemzés (parsing) The Query Compilation Process It's important to be aware that compilation and execution are distinct phases of query processing and that the gap between when SQL Server compiles a query and when the query is executed can be as short as a few microseconds or as long as several days. During the compilation process, SQL Server parses each statement and creates something called a sequence tree. This is one of the few data structures in SQL Server 2000 that has survived from SQL Server 6.5. The sequence tree is then normalized. The main function of the normalizer is to perform binding, which includes verifying that the tables and columns exist and loading the metadata for the tables and columns. Information about implicit conversions is also added to the sequence tree; for example, if the query is trying to add 10.0 to an integer value, SQL Server will insert an implicit convert into the tree. Normalization also replaces references to a view with the definition of that view. Finally, normalization includes a few syntax-based optimizations. If the statement is a DML statement(Select, Insert, Update, Delete), SQL Server extracts information from the sequence tree about that query and creates a special structure called a query graph, which is set up to let the optimizer work on it effectively. The query graph is then optimized and a plan is produced. If the statement is not a DML statement(If, Else, While, etc.), it will be compiled. These statements are not optimized. Végrehajtási fa készítés Normalizálás Igen SQL DML utasítás? Lekérdezési gráf Nem Végrehajtási terv (optimalizálás nélkül) Optimalizálás Végrehajtási terv

Az optimalizálás Triviális terv optimalizálás SQL Server 2000 2002. február 20. Az optimalizálás Triviális terv optimalizálás The first step is called trivial plan optimization. The idea behind trivial plan optimization is that cost-based optimization is expensive to run. The trivial plan optimizer finds the really obvious plans that are typically very inexpensive. This saves the optimizer from having to consider every possible plan, which can be costly and can outweigh any benefit provided by well-optimized queries. If the trivial plan optimizer doesn't find a simple plan, SQL Server can perform some simplifications, which are usually syntactic transformations of the query itself, to look for commutative properties and operations that can be rearranged. SQL Server then loads up the metadata, including the statistical information on the indexes, and then the optimizer goes through a series of phases of cost-based optimization. Optimization is broken up into phases. Each phase is a set of rules. After each phase, SQL Server evaluates the cost of any resulting plan, and if the plan is cheap enough, it executes that plan. If the plan is not cheap enough, the optimizer runs the next phase, which is another set of rules. In the vast majority of cases, SQL Server finds a good plan in the preliminary phases. If the optimizer goes through all the preliminary phases and still hasn't found a cheap plan, it examines the cost of the best plan it has so far. If the cost is above a particular threshold, the optimizer goes into a phase called full optimization. Egyszerűsítés, transzformáció Nem Igen Elég olcsó? 1 Statisztika beolvasás Költség > párhuzamosítási küszöb? Igen Teljes optimalizálás, párhuzamos végrehajtáshoz Több fázisú, költség alapú optimalizálás Nem Teljes optimalizálás, soros végrehajtáshoz Van elég olcsó terv? Nem 1 Terv Igen

Az optimalizáló működése SQL Server 2000 2002. február 20. Az optimalizáló működése A lekérdezés (táblák, keresési feltételek) elemzése Index választás a kereséshez Join választás Nested loop nagy méretű lekérdezések, megfelelő indexekkel támogatva Hash nincs index, kis táblák, vagy sok memória Merge rendezett adatfolyamok The query optimizer has three main steps: First it performs a query analysis for each table involved in the query and evaluates the search conditions in the WHERE clause Next it considers which indexes are available to narrow the scan of a table. That is, the optimizer evaluates to what extent an index can exclude rows from consideration. The more rows that can be excluded, the better, because that leaves fewer rows to process. Finally, it considers Joins. Joins can be processed by one of three methods: nested iteration, hashing, or merging. For any of these methods, the optimizer decides on the order in which the tables should be accessed. Because a nested iteration is a loop, order is important. The fewer the iterations through the loops, the less processing will be required. So it is useful to start with the table (or tables) that can exclude the most rows as the outer loops. The general strategy is to have the outer table limit the search the most, which results in the fewest total iterations (scans). For each combination of join strategy, join order, and indexes, the query optimizer estimates a cost, taking into account the number of logical reads and the memory resources that are required and available. Then the optimizer compares the cost of each plan and chooses the plan with the lowest estimate.

demó Lekérdezési terv demó Query Analyzer A lekérdezési terv megjelenítése grafikus és szöveges formában Lekérdezés végrehajtási statisztikák

Napirend SQL Server 2000 teljesítmény hangolás Méretezés Zárolás A lekérdezés feldolgozó A lekérdezések hangolása Az SQL Server konfigurációs paraméterei Teljesítmény adatok gyűjtése és elemzése

A lekérdezés hangolás eszközei SQL Server 2000 2002. február 20. A lekérdezés hangolás eszközei Normalizált logikai adatbázis terv, és Rövid sorok és rövid kulcsmezők (jó fizikai terv) Hasznosnak tűnő indexek létrehozása PK (automatikus), FK Tesztelés, a valóshoz közeli terheléssel Index hangolás a fontos/lassú lekérdezésekre Tárolt eljárások kerüljük az ad-hoc lekérdezéseket Legutolsó megoldás, ha nincs más: Lekérdezés tippek De-normalizálás

A lekérdezés vizsgálata SQL Server 2000 2002. február 20. A lekérdezés vizsgálata The STATISTICS IO option provides statistics on how much work SQL Server did to process your query. When this option is set to ON, you get a separate line of output for each query in a batch that accesses any data objects. The output from SET STATISTICS IO ON includes the values Logical Reads, Physical Reads, Read Ahead Reads, and Scan Count. SET STATISTICS TIME ON is pretty self-explanatory. It shows the elapsed and CPU time required to process the query. Finally SHOWPLAN shows some basic information about how the query will be processed. The output will tell you, for each table in the query, whether indexes are being used or whether a table scan is necessary. It will also tell you the order that all the different operations of the plan are to be carried out. Query Analyzer Provides a graphical version of showplan. set statistics io on Logical Reads Physical Reads Read Ahead Reads Scan Count set statistics time on Grafikus lekérdezési terv set showplan_text / showplan_all on set statistics profile on

SQL Server 2000 2002. február 20. Lekérdezési tippek Ha másként nem tudjuk az optimalizálót „helyes” döntésre bírni Tippek: MaxDop = x Join (loop, hash, merge, remote) Index (index(), fastfirstrow) Lock (holdlock, nolock, readpast, rowlock, paglock, tablock, tablockx, xlock, updlock) Processing Hints (set forceplan on)

A blokkolás elkerülése SQL Server 2000 2002. február 20. A blokkolás elkerülése A process blocks when it stalls while waiting to acquire a lock that is incompatible with a lock held by some other process. This condition is often, but erroneously, referred to as a "deadlock." As long as the process being stalled is not, in turn, stalling the offending process you have a blocking problem, not a deadlock. Some things you can do to keep from getting into a blocking situation are Keep transactions as short as possible. The shorter the duration of the transaction, the shorter the time that locks will be held. Never add a pause within a transaction for user input. When you process a result set, process all rows as quickly as possible. For browsing applications, consider using cursors with optimistic concurrency control. An address book application is a good example of a browsing application: users scroll around to look at data and occasionally update it. But the update activity is relatively infrequent compared to the time spent perusing the data. Using scrollable cursors with the OPTIMISTIC locking mode is a good solution for such applications. Instead of locking, the cursor's optimistic concurrency logic determines whether the row has changed from the copy that your cursor read. If the row has not changed during the lengthy period in which the user is perusing the data, the update is made without holding locks. If the row has changed, the UPDATE statement produces an error and the application can decide how to respond. Rövid tranzakciók! Tranzakció közben ne várakozzunk! Az eredményhalmazokat mielőbb vegyük át az SQL Servertől Böngésző jellegű alkalmazásoknál használjunk optimista „zárolást”

A deadlock elkerülése Ciklikus deadlock: Konverziós deadlock: SQL Server 2000 2002. február 20. A deadlock elkerülése A deadlock occurs when, without some intervening action, processes cannot get the locks they need no matter how long they wait. Simply waiting for locks is not a deadlock condition. SQL Server automatically detects the deadlock condition and terminates one of the processes to resolve the situation. There are two general forms of deadlocks; cycle deadlocks and conversion deadlocks. Deadlocks can usually be avoided, although you might have to do some detailed analysis to solve the problems that cause them. Sometimes the cure is worse than the ailment, and you're better off handling deadlocks rather than totally preventing them. Preventing deadlocks (especially conversion deadlocks) requires a thorough understanding of lock compatibility. The main techniques you can use to prevent deadlocks: To prevent cycle deadlocks, make all processes access resources in a consistent order. Reduce the transaction isolation level if it's suitable for the application. To prevent conversion deadlocks, explicitly serialize access to a resource. Ciklikus deadlock: Az erőforrásokat mindig azonos sorrendben foglaljuk le Az alkalmazás számára még éppen megfelelő legalacsonyabb izolációs szintet válasszuk Konverziós deadlock: Zárolási tippek Adott erőforrás esetén sorba állíthatjuk a tranzakciókat

A lekérdezés hangolás folyamata SQL Server 2000 2002. február 20. A lekérdezés hangolás folyamata Információ gyűjtés az alkalmazás viselkedéséről SQL Profiler Az információ elemzése Query Analyzer Index Tuning Wizard Módosítás Enterprise Manager Teszt, teszt, teszt

Tesztelési segédeszközök SQL Server 2000 Resource Kit Database Generator (DBGen) Teszt adat generátor Database Hammer Testre szabható teljesítmény teszt MS Web Application Stress Tool http://webtool.rte.microsoft.com/download.asp Load Simulator Profiler A felvett terhelés visszajátszása osql.exe

demó Load Simulator demó Terhelés teszt

demó OSQL.EXE demó Terhelés teszt

Index Tuning Wizard demó Index hangolás

Napirend SQL Server 2000 teljesítmény hangolás Méretezés Zárolás A lekérdezés feldolgozó A lekérdezések hangolása Az SQL Server konfigurációs paraméterei Teljesítmény adatok gyűjtése és elemzése

Rendszer konfiguráció SQL Server 2000 2002. február 20. Rendszer konfiguráció „Maximize Data Throughput for Network Applications” beállítása a „File and Print Services”-nél (a setup beállítja) Lehetőleg ne tegyünk SQL Server adatbázisokat a PAGEFILE.sys meghajtójára

SQL Server konfiguráció (1) Enterprise Manager 2002. február 20. SQL Server konfiguráció (1) Enterprise Manager SQL Server Properties Autostart Startup parameters

SQL Server konfiguráció (2) Enterprise Manager 2002. február 20. SQL Server konfiguráció (2) Enterprise Manager Min Server Memory, Max Server Memory Fixed Memory Set Working Set Size Minimum Query Memory create index, hash join, merge join

SQL Server konfiguráció (3) Enterprise Manager 2002. február 20. SQL Server konfiguráció (3) Enterprise Manager Processor affinity Max. worker threads Boost SQL Server priority Use NT fibers Ha minden processzor 95% fölött dolgozik, kis teljesítmény jav. Parallelism Kevés processzor, sok felhasználó esetén felesleges

SQL Server konfiguráció (4) Enterprise Manager 2002. február 20. SQL Server konfiguráció (4) Enterprise Manager Recovery Interval

SQL Server konfiguráció (5) SQL 2002. február 20. SQL Server konfiguráció (5) SQL sp_configure reconfigure reconfigure with override

Adatbázis opciók Enterprise Manager, sp_dboption és alter database SQL Server 2000 2002. február 20. Adatbázis opciók Enterprise Manager, sp_dboption és alter database

Napirend SQL Server 2000 teljesítmény hangolás Méretezés Zárolás A lekérdezés feldolgozó A lekérdezések hangolása Az SQL Server konfigurációs paraméterei Teljesítmény adatok gyűjtése és elemzése

A teljesítmény problémák okai SQL Server 2000 2002. február 20. A teljesítmény problémák okai Logikai adatbázis terv (táblaszerkezet) Fizikai adatbázis (indexek, statisztikák hiánya, rosszul megírt SQL) Alkalmazás Hardware (diszk, memória, processzor, hálózat) Operációs rendszer és SQL Server hibák

SQL Server 2000 2002. február 20. A módszer Kezdetben gyűjtsünk sok információt, majd fokozatosan szűkítsük a keresést! Kérdések a felhasználók, a menedzserek és a fejlesztők felé: Mikor legkritikusabb a teljesítmény? Mihez képest lassú? Iteratív folyamat Mindig van szűk keresztmetszet Ellenőrizzük a feltételezett megoldást! Előzzük meg a problémákat!

Az adatgyűjtés eszközei SQL Server 2000 2002. február 20. Az adatgyűjtés eszközei Sqldiag.exe (output: 1-4 MB) Blocker script (1 - 20 MB/óra) Profiler (50-100 MB/óra) System monitor (20 MB/óra) System és Application event log-ok (1 MB)

Sqldiag.exe Parancssori eszköz: SQL Server 2000 2002. február 20. Sqldiag.exe Parancssori eszköz: \Microsoft SQL Server\MSSQL\Binn\sqldiag Az eredmény az sqldiag.txt file-ba kerül \Microsoft SQL Server\MSSQL\LOG\SQLdiag.txt Új futásnál felülíródik Paraméterek: sqldiag.exe /? [-U login] [-I instance name] [-P password] [-E] [-O output filename] [-X(exclude error logs)] [-M(perform dbcc stackdump)] [-C(retrieve cluster information)] Pillanatfelvétel az SQL Serverről

Az sqldiag.txt tartalma SQL Server 2000 2002. február 20. Az sqldiag.txt tartalma Az aktuális és az előző 6 errorlog (verzió, SP!) Registry információ Library verzió információ Az SQL Server konfigurációja (sp_configure) Aktuális adatbázis folyamatok (sp_who) Lock-ok (sp_lock) Adatbázisok (sp_helpdb) Termék információk (xp_msver) Kiterjesztett tárolt eljárások (sp_helpextendedproc) A sysprocesses tábla Input puffer információ (DBCC INPUTBUFFER) Deadlock információ Számítógép információ

demó SqlDiag demó

Blocker Script Blocker script SQL Server 2000 2002. február 20. Blocker Script Blocker script Q271509, “INF: How to Monitor SQL Server 2000 Blocking” Q251004, “INF: How to Monitor SQL Server 7.0 Blocking” Q251175, “INF: How to Monitor SQL Server 6.5 Blocking”

A Blocker Script használata SQL Server 2000 2002. február 20. A Blocker Script használata A tárolt eljárás létrehozása Futtató script létrehozása, pl.: chk.sql DBCC TRACEON (3604) go WHILE 1=1 BEGIN EXEC sp_blocker_pss80 -- Gyors mód EXEC sp_blocker_pss80 1 -- dbcc inputbuffer és dbcc pss nélkül WAITFOR DELAY '00:00:15' END Go osql –E –Sserver –ichk.sql -ochk.out –w2000 Leállítás: CTRL+C

A Blocker Script eredménye (1) SQL Server 2000 2002. február 20. A Blocker Script eredménye (1) Start time Sysprocesses SPID, Ecid, Status, Open_tran, Lastwaittype, Waittype (Q244455),Waittime,Waitresource, Cmd, Cpu, Physical_io, Memusage, Dbid, Last_batch, Login_time, Loginame, Uid, Hostname, Program_name, Nt_domain, Nt_username, Net_address, Net_library

A Blocker Script eredménye (2) SQL Server 2000 2002. február 20. A Blocker Script eredménye (2) Spid a zárolási lánc elején Syslockinfo (sp_lock) SPID, Ecid, Dbid, Objid, Indid (0=lap,1=clustered index, 255=text/image lánc), Type, Resource, Mode, Status DBCC INPUTBUFFER (nem 0 waittype-ra) DBCC PSS (a blokkolási lánc elejére) A zárolás általában normális jelenség, a hosszú blokkolás nem A trendek érdekesek

demó Blocker Script demó

A Profiler Az SQL Server események gyűjtésére és vizsgálatára szolgál 2002. február 20. A Profiler Az SQL Server események gyűjtésére és vizsgálatára szolgál Nagyon sok adatot gyűjthetünk, célszerű a következő cikk által javasoltakat használni Q224587, “INF: Troubleshooting Application Performance with SQL Server”

demó Profiler demó Profiler trace létrehozása Kapcsolódás az SQL Serverhez Általános beállítások Események Adatok Szűrők

SQL Server 2000 2002. február 20. A Profiler eredménye Áttekintés az eseményekről és előfordulásuk gyakoriságáról Táblába menthető Elemzés: Hosszú lekérdezések keresése (> 2000 msec) „attention” és „exception” események „hash”, „sort”, „warning” „recompile” és „auto update statistics” „sp_cursoropen” és „CursorImplicitConversion” „deadlock” és „lock timeout” Hiányzó oszlop statisztikák

SQL Server 2000 2002. február 20. A System Monitor Log file-ba gyűjtjük az adatokat, majd ezeket a System monitorban vizsgáljuk Fontos objektumok: Memory, processor, process, system, object, thread, page file, physical disk, logical disk, minden (?) SQL Server objektum Elemzés: Memória, diszk I/O, processzor, hálózati I/O A „normálishoz” viszonyítva túl magas, vagy alacsony értékek keresése Összevetés a más eszközökkel gyűjtött adatokkal

demó System Monitor demó Az SQL Server teljesítmény számlálók közvetlenül is elérhetők: select * from master.dbo.sysperfinfo

Az eszközök használata (1) SQL Server 2000 2002. február 20. Az eszközök használata (1) MSDN: “Index Tuning Wizard for Microsoft SQL Server 2000” MSDN: “Microsoft SQL Server 7.0 Performance Tuning Guide” Q224587, “INF: Troubleshooting Application Performance with SQL Server” Q271509, “INF: How to Monitor SQL Server 2000 Blocking” Q251004, “INF: How to Monitor SQL Server 7.0 Blocking”

Az eszközök használata (2) SQL Server 2000 2002. február 20. Az eszközök használata (2) Q224453, “INF: Understanding and Resolving SQL Server 7.0 or 2000 Blocking Problem” Q243589, “INF: Troubleshooting Slow-Running Queries on SQL Server 7.0 or Later” Q243588, “INF: Troubleshooting Performance of Ad-Hoc Queries” Q243586, “INF: Troubleshooting Stored Procedure Recompilation” Q244455, “INF: Definition of Sysprocesses Waittype and Lastwaittype Fields for SQL Server 7.0”

Előadások a Weben How to Collect and Analyze Performance Data in Microsoft SQL Server http://support.microsoft.com/servicedesks/webcasts/wc082401/wcblurb082401.asp Microsoft SQL Server: Rapid Blocker Script Analysis http://support.microsoft.com/servicedesks/webcasts/wc011502/wcblurb011502.asp Support WebCasts (Upcoming, Past) http://support.microsoft.com/webcasts

Összefoglalás, mit láttunk? A fejlesztő és az adatbázis adminisztrátor különböző eszközökkel javíthatja az alkalmazások teljesítményét Helyes adatbázis és alkalmazás tervezés Lekérdezés hangolás Rendszer konfiguráció A teljesítmény rendszeres vizsgálata

wheredoyouwanttogotoday?

Probléma: „lassú” lekérdezés SQL Server 2000 2002. február 20. Probléma: „lassú” lekérdezés Blokkolás? Blocker script (sysprocesses, sp_who) Profiler trace Ha valóban lassú a lekérdezés: Query Analyzer, “set statistics time/io/profile on” Index Tuning Wizard

Probléma: deadlock Profiler SQL Server indítási paraméterek 2002. február 20. Probléma: deadlock Profiler Locks:Deadlock and Locks:Deadlock Chain SQL Server indítási paraméterek -T1204, -T3605 Az alkalmazás módosítása: Hibakezelés, a tranzakció újraindítása Index, vagy egyéb tipp az optimalizáló számára

Probléma: sok tárolt eljárás újrafordítás (recompile) SQL Server 2000 2002. február 20. Probléma: sok tárolt eljárás újrafordítás (recompile) Okok: WITH RECOMPILE záradék sp_recompile tárolt eljárás egy hivatkozott táblára A tárolt eljárás lekérdezési terve „kiöregszik” a gyorsítótárból Nagy tömegű adat módosult egy hivatkozott táblában Átlapolt DDL és DML (munkatáblák) „set” opciók az eljárásban Nem minősített objektum nevek