High performance jss 2012

472 vues

Publié le

Publié dans : Technologie
0 commentaire
2 j’aime
  • Soyez le premier à commenter

Aucun téléchargement
Nombre de vues
Sur SlideShare
Issues des intégrations
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • This phase of FTRA evaluation measures SQL Server performance for the FTDW workload in terms of two core metrics. The first, Maximum CPU Consumption Rate (MCR), is a measure of peak I/O processing throughput. The second, Benchmark CPU Consumption Rate (BCR) is a measure of actual I/O processing throughput for a query or a query-based workload.What Is MCR?The MCR calculation provides a per-core I/O throughput value in MB or GB per second. This value is measured by executing a predefined, read-only, nonoptimized query, from buffer cache and measuring the time to execute against the amount of data in MB or GB. Because MCR is run from cache it represents the peak nonoptimized scan rate achievable through SQL Server for the system being evaluated. For this reason MCR provides a baseline peak rate for initial design purposes. It is not intended to indicate average or expected results for a real workload. Validated FTDW architectures will have aggregate baseline I/O throughput results that are at least 100 percent of the server-rated MCR. Another way to explain this is that MCR represents the best possible SQL Server processing rate for a reasonable, worst-case workload.MCR can also be used as a frame of reference when comparing other published and validated FTDW reference architectures for SQL Server 2012.In summary: MCR is not definitive of actual results for a customer workload. MCR provides a maximum data processing rate baseline for SQL Server and a single query associated with the Fast Track workload.MCR is specific to a CPU and server. In general, rates for a given CPU do not vary greatly by server and motherboard architecture but final MCR should be determined by actual testing.MCR throughput rating can be used as a comparative value against existing, published FTDW reference architectures. This can assist with hardware selection prior to component and application testing.
  • Processus de traduction d'adresses virtuelles plus rapideLarge page support is enabled on Enterprise Edition systems when physical RAM is >= 8Gb (and lock pages in memory privilege set)SQL Server will allocate buffer pool memory using Large Pages on 64bit systems if Large Page Support is enabled and trace flag 834 is enabledLarge page for the buffer pool is definitely not for everyone. You should only do this for a machine dedicated to SQL Server (and I mean dedicated) and only with careful consideration of settings like ‘‘max server memory’. Furthermore, you should test out the usage of this functionality to see if you get any measureable performance gains before using it in production.SQL Server startup time can be significantly delayed when using trace flag 834.http://blogs.msdn.com/b/psssql/archive/2009/06/05/sql-server-and-large-pages-explained.aspxhttp://support.microsoft.com/kb/920093
  • Basé colonne : les données d’une colonne sont regroupées dans les mêmes pages. Un epage ne contient que les données d’une colonne. Pas de deux.
  • 1) Optimize for main memory data access: Storage-optimized engines (such as the current OLTP engine in SQL Server today) will retain hot data in a main memory buffer pool based upon access frequency. The data access and modification capabilities, however, are built around the viewpoint that data may be paged in or paged out to disk at any point. This perspective necessitates layers of indirection in buffer pools, extra code for sophisticated storage allocation and defragmentation, and logging of every minute operation that could affect storage. With Hekaton you place tables used in the extreme TP portion of an application in memory-optimized main memory structures. The remaining application tables, such as reference data details or historical data, are left in traditional storage optimized structures. This approach lets you memory-optimize hotspots without having to manage multiple data engines.Hekaton’s main memory structures do away with the overhead and indirection of the storage optimized view while still providing the full ACID properties expected of a database system. For example, durability in Hekaton is achieved by streamlined logging and checkpointing that uses only efficient sequential IO. 2) Accelerate business logic processing: Given that the free ride on CPU clock rate is over, Hekaton must be more efficient in how it utilizes each core. Today SQL Server’s query processor compiles queries and stored procedures into a set of data structures which are evaluated by an interpreter in SQL Server’s query processor. With Hekaton, queries and procedural logic in T-SQL stored procedures are compiled directly into machine code with aggressive optimizations applied at compilation time. This allows the stored procedure to be executed at the speed of native code. 3) Provide frictionless scale-up: It’s common to find 16 to 32 logical cores even on a 2-socket server nowadays. Storage-optimized engines rely on a variety of mechanisms such as locks and latches to provide concurrency control. These mechanisms often have significant contention issues when scaling up with more cores. Hekaton implements a highly scalable concurrency control mechanism and uses a series of lock-free data structures to eliminate traditional locks and latches while guaranteeing the correct transactional semantics that ensure data consistency. 4) Built-in to SQL Server: As I mentioned earlier – Hekaton is a new capability of SQL Server. This lays the foundation for a powerful customer scenario which has been proven out by our customer testing. Many existing TP systems have certain transactions or algorithms which benefit from Hekaton’s extreme TP capabilities. For example, the matching algorithm in financial trading, resource assignment or scheduling in manufacturing, or matchmaking in gaming scenarios. Hekaton enables optimizing these aspects of a TP system for in-memory processing while the cooler data and processing continue to be handled by the rest of SQL Server.
  • While Hekaton’s memory optimized tables must fully fit into main memory, the database as a whole need not. These in-memory tables can be used in queries just as any regular table, however providing optimized and contention-free data operation at this stage. After migrating to optimized in-memory storage, stored procedures operating on these tables can be transformed into natively compiled stored procedures, dramatically increasing the processing speed of in-database logic. Recompiling these stored procedures is, again, done through T-SQL, as shown below:
  • High performance jss 2012

    1. 1. Rejoignez la Communauté Edition 2012 – 10 et 11 décembre
    2. 2. HAUTE PERFORMANCE SQL Server Sponsors Platinum Edition 2012 – 10 et 11 décembre
    3. 3. Merci à nos Sponsors Rencontrez les dans l’espace partenaires Sponsors Platinum Sponsors Gold Sponsors Silver Edition 2012 – 10 et 11 décembre
    4. 4. PRÉSENTATION Christophe LAPORTE  ~14 ans d‟expérience sur SQL Server  Architecture système et Bases de Données  Haute disponibilité  Montée en charge  Virtualisation  Optimisation Conseil IT o Blog : http://conseilit.wordpress.com/ o Twitter : @ConseilIT Edition 2012 – 10 et 11 décembre Frédéric Pichaut  Depuis la V1 !!!  Senior Escalation Engineer Microsoft Support Microsoft
    5. 5. AGENDA • La performance ? • Matériel • Processeur • Mémoire • Disque • Architecture Fast Track • Fonctionnalités SQL Server • • • • Large Pages Lock Escalation Page Latch Minimal logging • Facteur 100 !!! • Q& R Edition 2012 – 10 et 11 décembre
    6. 6. QU’EST-CE QU’UN SYSTÈME ÉQUILIBRÉ? • Un système où toutes les ressources peuvent donner leur maximum sans qu’aucun composant ne soit un goulot d’étranglement pour un autre Le problème des évolutions: • • • • • • Bandwidth/Throughput des CPU augmentent d‟un facteur 1.5 annuellement Latency executing instructions on CPU augmentent que d‟un facteur 1.17 annuellement Bandwidth/Throughput de la RAM augmentent d‟un facteur 1.27 annuellement Latency de transfert des données de la mémoire vers le processeur augmente d‟un facteur 1.07 annuellement Bandwidth/Throughput des stockages augmentent d‟un facteur 1.28 annuellement Latency des lectures sur disque augmente que d‟un facteur 1.11 annuellement  Le problème n‟est plus réellement sur les CPU, mais plus sur les composants nourrissant les CPU en données. Edition 2012 – 10 et 11 décembre
    7. 7. DÉFINITION DE LA PERFORMANCE Ici, lorsque nous parlons de Performance, nous parlons d‟amélioration des débits des éléments utilisant le hardware en parallèle Nous ne parlons pas de Performance sur le plan de l‟amélioration de l‟exécution d‟une tache monolithique( ex: exécution d‟un requête) Lire cet article sur un retour d‟expérience client: http://blogs.msdn.com/b/saponsqlserver/archive/2010/01/24/performancewhat-do-we-mean-in-regards-to-sap-workload.aspx Edition 2012 – 10 et 11 décembre
    8. 8. SCALE UP TERMINOLOGY 64+ Logical Processor System Group (up to 64 logical processors) NUMA Node Socket Core Logical Processor/CPU Thread Edition 2012 – 10 et 11 décembre
    9. 9. MANY CORE PROCESSORS • Les hardwares classiques sur x64 sont largement assez performant pour les besoins de beaucoup d‟application et vont continuer a augmenter • Les dernières générations de processeur: o o o o o o Intel Xeon E5 26xx: 1 socket=8 cores=16 threads Intel Xeon E7 87xx: 1 socket=10 cores=20 threads AMD Opteron 617x: 1 socket=16cores=16threads 2-socket serveur à 32 CPU threads 4-socket serveur à 64 (AMD)/80 CPU threads 8-socket serveur à 160 CPU threads (Intel only) L‟Intel Ivybridge-EX, attendu pour l‟année prochaine, devrait exposer 30 CPU threads par socket Les architectures grandissent avec de plus en plus de thread par processeurs mais la performance d‟un thread unique ne s‟est pas amélioré. La performance d‟un thread est souvent vitale pour l‟exécution des requêtes simple. D‟autres composants de SQL sont liés à la performance des thread unique: Ecriture dans les Log Buffers, Lockhash, etc Edition 2012 – 10 et 11 décembre
    10. 10. MANY CORE PROCESSORS – SQL 2012 Quelques informations intéressantes sur l‟AMD Operon Processors, SQL Server 2012 et Windows • Le mode de licence de SQL Server 2012 par core. L‟ AMD Opteron est un 16-core processors • Un patch de Win7/2008R2 et Windows 8 (sans patch) laisse l‟Opteron exposer 8-core Hyper-threaded. (http://support.microsoft.com/kb/2645594 ) • Le patch ne change pas le mode de licence de l‟Opteron (16-core processeur), mais permet d‟utiliser SQL Server 2012 STD (limité a 16 cores) sur un 2-socket Opteron avec tous les cores/CPU Attention, il y a 2 versions de SQL Server 2012 Enterprise Edition • • Normalement la version EE en licence Per-Core n‟est pas limitée ou seulement par les capacités de Windows Il existe une seconde version de SQL EE qui est en licence Server + CAL. Elle est limitée a 20 sockets/40cores!! Problème: • • La description de la version limité est la même que dans le passé („Enterprise Edition (64-Bit)‟). La description de La version “illimité” est: „Enterprise Edition: Core-based Licensing (64-bit)’ • http://blogs.msdn.com/b/saponsqlserver/archive/2012/06/15/sql-server-2012-enterprise-editions.aspx Edition 2012 – 10 et 11 décembre
    11. 11. MANY CORE PROCESSORS - HYPERTHREADING • Expérience: • L’implémentation actuelle de l’Intel Simultaneous HT semble donner environ 20 à 30% d’amélioration pour la plupart des applications SQL • N‟améliore pas les batch simple n‟utilisant pas le parallélisme • Le gain n‟est visible que sur des batch s‟exécutant en parallèle • La performance intrinsèque qu‟un CPU chute. Edition 2012 – 10 et 11 décembre
    12. 12. Server Platform – NUMA Non-Uniform-Memory-Access P1 Cache1 P2 Cache2 P3 Cache3 P4 Cache4 P5 Cache1 P6 Cache2 P7 Cache3 P8 Cache4 Node Interconnect Node A MemA DiskA Cache(s) Node B MemB DiskB Quel est le problème posé par cette architecture à SQL Serveur? • • • • Le temps d‟accès à la mémoire varie en fonction de l‟endroit accédé (local ou remote) SQL doit distribuer les allocations mémoires sur les différents node NUMA Les accès „remote‟/‟foreign‟ sont 2 à 5 fois plus long que les accès „local‟ Spécialement sur des chipsets >4 sockets Un accès peut prendre 2 steps Conclusion • • • • • SQL se doit de détecter l‟architecture NUMA Les constructeurs décrivent la configuration NUMA dans la HAL via l‟interface SRAT SQL Server récupère le configuration via des API Win32 APIs se configure en fonction Windows et SQL Server se sont adaptés depuis les 10 dernières années pour bénéficier de cette architecture Chaque releases des deux produits apportent des améliorations sur ce point – et le travail continu!!! Edition 2012 – 10 et 11 décembre
    13. 13. SQL SERVER PLATFORM – NUMA • Les DMV liées à l‟ architecture NUMA à partir de SQL Server 2008 • sys.dm_os_memory_nodes o Expose les allocations pour les différents nodes NUMA (doit être à peu près la même). Une ligne par node NUMA • sys.dm_os_nodes o Expose les nodes NUMA, l‟affinité CPU, le nombre de SQL schedulers par node • DMV intéressantes sur les CPU et la mémoire: • sys.dm_os_sys_info • sys.dm_os_memory • Attention sys.dm_os_sys_info ne fait pas de différence entre Core et CPU logique Hyperthreadé • Vous pouvez aussi obtenir la configuration NUMA avec coreinfo.exe: o http://technet.microsoft.com/en-us/sysinternals/cc835722.aspx Edition 2012 – 10 et 11 décembre
    14. 14. SERVER PLATFORM – GROUPES DE PROCESSEURS Windows 2008 R2 et SQL Server 2008 R2 supportent: • Jusqu‟a 256 Processeurs logiques • Jusqu‟a 2TB Windows Server 2012 et SQL Server 2012 supportent: • Jusqu‟a 640 Processeurs logiques • Jusqu‟a 4TB Nous supportons uniquement ce que nous avons testé ( Nous n‟avons pas encore eu des hardwares > 640 Processeurs logiques) • • Nous recommandons l‟utilisation du Service Pack1 de SQL Server 2012 si > 256 CPU Il inclue des fixes de performance pour travailler avec > 256 CPUs Edition 2012 – 10 et 11 décembre
    15. 15. SERVER PLATFORM – GROUPES DE PROCESSEURS Segmented specification – “groups” of logical processors • >64 LP supported by dividing them into groups of 64 LPs o o • • • Allows backward compatibility with 64-bit affinity Permits better locality during scheduling than a “flat” specification NUMA Nodes cannot cross different processor groups Threads cannot migrate to other processor groups unless told so by user code New Win32 APIs use KGROUPAFFINITY o Applications have full LP range using new APIs Edition 2012 – 10 et 11 décembre
    16. 16. SERVER PLATFORM – GROUPES DE PROCESSEURS SQL Server 2008 (et avant) • • SQL Server 2008 sur un serveur avec >64 LP, le process SQL est positionné dans un groupe SQL Server 2008 ne voit que les processeurs de ce groupe SQL Server 2008 R2 et SQL Server 2012: Support total des groupes de processeurs • Le démarrage se fait dans un groupes de processeurs, mais peut assigner des threads dans un autre groupe • Nouvelle syntaxe pour L‟affinity mask: • ALTER SERVER CONFIGURATION SET PROCESS AFFINITY CPU=0 TO 15, 31 TO 47, 64 to 71; • Attention, si les groupes de processeurs ne sont pas au maximum de 64LP il y a gap (trou) dans la liste des processeurs. • Vérifier la colonne cpu_id de sys.dm_os_schedulers et en suite assigner les ID listé correctement http://blogs.msdn.com/b/saponsqlserver/archive/2011/04/20/changes-in-affinity-settingsof-sql-server-2008-r2-to-support-gt-64-logical-processors.aspx Edition 2012 – 10 et 11 décembre
    17. 17. SERVER PLATFORM – GROUPES DE PROCESSEURS Problème avec la nouvelle génération de processeur Intel et les Groupes de Processeurs : • Ile ne fait pas une bonne répartition en groupe de 64 CPUs • Exemple: o Un 4-socket server avec Intel Xeon E7 à 80 logical processors Démarre avec: – Un groupe de 60 – Un groupe de 20 o Un HP DL980 avec Intel Xeon E7 à 160 logical processors. Démarre avec : – Deux groupes de 60 – Un groupe de 40 Problème: Windows assigne les processes qui ne sont pas « group aware » aléatoirement au différents groupes  SQL Server 2008 or SQL Server 2005 • Solution: Hotfix http://support.microsoft.com/kb/2510206 Windows 2008 R2 OS --> Crée des groupes equilibré • Intégré à Windows Server 2012 Edition 2012 – 10 et 11 décembre
    18. 18. SERVER PLATFORM – GROUPES DE PROCESSEURS Pas de changement pour l‟affinity I/O mask. Peut uniquement être assigné dans le 1er groups – Ne pas y toucher Changements dans l‟errorlog – ID du Groupes de Processeurs: Node Node Node Node configuration: configuration: configuration: configuration: node node node node 0: 1: 2: 3: CPU CPU CPU CPU mask: mask: mask: mask: 0x00000000000fffff:1 0x00000000000fffff:0 0x000000fffff00000:1 0x0fffff0000000000:1 Active Active Active Active CPU CPU CPU CPU mask: mask: mask: mask: 0x00000000000fffff:1. 0x00000000000fffff:0. 0x000000fffff00000:1. 0x0fffff0000000000:1. Apres l‟application du http://support.microsoft.com/kb/2510206 : Node Node Node Node configuration: configuration: configuration: configuration: node node node node 0: 1: 2: 3: CPU CPU CPU CPU mask: mask: mask: mask: 0x000000fffff00000:0 0x00000000000fffff:0 0x000000fffff00000:1 0x0fffff0000000000:1 • Pour mesurer l‟utilisation CPU utiliser: Active Active Active Active CPU CPU CPU CPU mask: mask: mask: mask: 0x000000fffff00000:0. 0x00000000000fffff:0. 0x000000fffff00000:1. 0x0fffff0000000000:1. • Les compteurs „Processor Information‟ plutôt que „Processor‟ • Regarder aussi le compteur „% of maximum frequency‟ sous „Processor Performance‟ Edition 2012 – 10 et 11 décembre
    19. 19. MÉMOIRE La Mémoire pour systèmes classique est peu chère Aucune raison pour ne pas équiper ces serveurs avec suffisamment de mémoire. • Une configuration de 6-8GB par core processeur est bonne Eventuellement plus pour des applications OLAP où les données doivent rester en mémoire • SQL Server 2012 ColumnStore • • • • Les ColumnStore travaillent en segments de 4-16MB Un segment minimum par colonne Les I/Os pour charger un segment sont plus long Donc besoin de garder les segments aussi longtemps que possible dans le cache Edition 2012 – 10 et 11 décembre
    20. 20. MÉMOIRE – COMBIEN? Que regarder: • SQL Buffer Pool Cache Hit Ratio (ideal 99%) • Temps d‟attente important sur PAGEIOLATCH_xx • Maximum workspace memory, Memory grants pending (indiquent un pression mémoire) • Taux important de “spill-outs” dans tempdb • Lazy writes/sec continuellement actif Sur une configuration AlwaysOn vérifier aussi pour chaque base membre d‟un Availability Group: • • • • SQL Server:Databases  Log Pool Cache Misses/sec SQL Server:Databases  Log Pool Disk Reads/sec SQL Server:Databases  Log Pool Requests/sec SQL Server:Memory Manager  Log Pool Memory (KB) Edition 2012 – 10 et 11 décembre
    21. 21. SQL SERVER ET LES DISQUES  Les types d’I/O disque de SQL Server Operation Random / Sequential Read / Write Size Range OLTP – Log Sequential Write Very small and up to 64K OLTP – Data (Index Seeks) Random Read 8K OLTP - Lazy Writer Random Write Any multiple of 8K up to 128K OLTP - Checkpoint Random Write Any multiple of 8K up to 128K Read Ahead (DSS, Index/Table Scans) Sequential Read Any multiple of 8KB up to 256K Bulk Insert Sequential Write Any multiple of 8K up to 128K BACKUP / Restore Sequential Read/Write Multiple of 64K (up to 4MB) DBCC – CHECKDB Sequential Read 8K – 64K ALTER INDEX REBUILD (Read Phase) Sequential Read (see Read Ahead) ALTER INDEX REBUILD (Write Phase) Sequential Write Any multiple of 8K up to 128K En 10 ans, la capacité des disques a été multipliée par 100 En 10 ans, le temps d’accès aux disques a seulement été divisé par 10  Déterminer le # de disques nécessaires n’est pas une question de Edition 2012 – 10 et 11 décembre volume mais de performances
    22. 22. DISQUES ROTATIFS Regardons les cas des lectures „random‟ (8K pages): • Un disque standard 2.5‟‟ 15K RPM a de bonnes performances (I/O < 10ms) jusqu‟à 150 – 200 lectures „random‟/s • Donc si j‟ai besoin pour mon application de ~ 15K de lecture „random‟ de pages (index seek) par seconde : o Mes disques me fournissant ~1.2MB/sec (150*8k) o Il va falloir prévoir 100 disques pour tenir la charge uniquement pour les fichiers de données Regardons les cas des lectures séquentielles (64K= 1 extent): • Le cas le pire est lorsque 1 extent sur disque appartient à un objet SQL et le suivant appartient à un autre objet (cas fréquent) surtout en cas de fragmentation de table. • On comprend donc que le nombre de lectures reste sensiblement le même que dans le cas „random‟ (~150 read/s) • En réorganisant les tables  un disque lit ~10MB/sec • Pour lire 3TB il faut: o 31 jours en lecture random et 140 IO/S de 8KB o 8.3h en lecture séquentielle Edition 2012 – 10 et 11 décembre
    23. 23. DISQUES SSD Caractéristiques des disques SSD et autres medias no rotatifs: • • • • • Vitesse de lecture souvent 20-40 fois plus rapide que les disques rotatifs avec une faible latence Pour les SLCs la latence d‟écriture est proche des SAN traditionnels avec cache Des tests avec diffèrent workloads ont prouvé que de passer de disques classiques à des SSD peut réduire le nombre de disque nécessaire par 10 avec le même voir meilleur latence. Il sont très efficace pour une utilisation intensive de tempdb. Les SSD réduisent la consommation électrique. Violin: http://www.violin-memory.com/ • • • Complete Storage arrays built on Flash Connecté par Fiber Channel (Windows Failover Clustering possible) Ou connecté par PCI-X (pas de WFC possible) • • PCI-X based local Flash drive désavantages: en général local, ne peut être partagé, pas de WFC possible Fusion I/O: http://www.fusionio.com/ Note: ces périphériques peuvent avoir des comportements très diffèrent que des SSDs intégrés dans un SAN –Le plus proche de la mémoire le SDD est, le plus performant il est • Souvent pas possible d‟utiliser en HA/DR Edition 2012 – 10 et 11 décembre
    24. 24. SQL SERVER ET LES SAN/NAS • Quelques règles de bases • Un large cache améliore l‟efficacité de chaque disque • Des opérations qui ne profitent pas tant du cache car les pages sont lues une fois et pas réutilisées: o Backup online, CHECKDB, Création d‟indexes • La réplication hardware peut avoir un impacte sur les performances d‟écriture dans le Log de transaction • Penser aux solutions SRDF/S (Symmetrix Remote Data Facility) – soit un “3rd party Volume Manager” • Read et Writes Caches • Ne pas utiliser de Write cache sans batterie backup • Utiliser le Write cache pour les logs Edition 2012 – 10 et 11 décembre
    25. 25. SQL SERVER ET LES CONFIGURATIONS DISQUE • RAID Level: 0, 1, 5, 10, 0+1 • RAID 10 – recommandé pour datas et logs • RAID 5 – uniquement sur des petits systèmes • RAID 0+1 – pour les logs et Tempdb • RAID 0 – pas recommandé • Attention à la répartition sur les disques • Eviter la cohabitation des datas et logs • Eviter la cohabitation avec certaine applications (Exchange) • TOUJOURS aligner les file-systems sur une frontière de 64KB (diskpart.exe /ALIGN) Edition 2012 – 10 et 11 décembre
    26. 26. QUELLE PERFORMANCE ATTENDRE • Host Bus Adapter (HBA) • 1-Gigabit ~80-85MB/sec -- 2-Gigabit ~160-170MB/sec • Plus de contrôleur = plus de performances • Configuré le “multipathing” • Quel niveau de performance attendre: • Data Files o < 10 msec Idéal o 10 –20 msec Acceptable o > 20 msec Pb à résoudre, bottlenecks probables • Log Files o o o o o < 5 msec Idéal 5 –10 msec Acceptable 10 –15 msec Investigation nécessaire 15 –20 msec Evolution compromise > 20 msec Pb à résoudre, bottlenecks probables Edition 2012 – 10 et 11 décembre
    27. 27. ARCHITECTURE FASTTRACK • Aide à la configuration de chaque composant • Document Microsoft repris par les constructeurs avec des références matérielles • Exemple • Dual Xeon processors, 6 cores / processeur : MCR 3,168 MB/sec • 4 x 8Gbps HBAs : 3,123 MB/sec • 48 15k disques (Raid 5) : 3,146 MB/sec Edition 2012 – 10 et 11 décembre
    28. 28. ARCHITECTURE FASTTRACK o Plutôt orienté DataWareHouse o Optimiser tous les composants de la chaine IO Disque o Documents constructeurs très détaillés … Edition 2012 – 10 et 11 décembre
    29. 29. LARGE PAGES • Taille des pages = 4Kb (x64) • 2Mb avec Large Pages • Activation possible si • SQL Server Enterprise Edition • >=8Gb RAM • Privilège “Lock Pages in Memory” • Trace Flag 834 • • • • Allocation de la mémoire du Buffer Pool via le LargePageAllocator Réservation de la mémoire au démarrage de SQL Server Peut empêcher le démarrage du service … Peut ralentir le démarrage • Démo • Si le temps le permet !!!! Edition 2012 – 10 et 11 décembre
    30. 30. LARGE PAGE Edition 2012 – 10 et 11 décembre
    31. 31. LOCK ESCALATION • Partitionnement de table • • • • Améliore la concurrence d‟accès Réduit la contention niveau page Scénario Sliding Window Reconstruction d‟index granulaire • Démo Table • Si le temps le permet !!!! Partition Page Ligne Edition 2012 – 10 et 11 décembre
    32. 32. LOCK ESCALATION Edition 2012 – 10 et 11 décembre
    33. 33. PAGE LATCH • Solution : N B-Trees • Demo Edition 2012 – 10 et 11 décembre
    34. 34. PAGE LATCH - DEMO Edition 2012 – 10 et 11 décembre
    35. 35. PAGE LATCH – PFS PAGE (DB_ID().1.1) Edition 2012 – 10 et 11 décembre
    36. 36. MINIMAL LOGGING • Le journal de transaction trace • Les allocations d‟extensions • Les modifications de metadata Table Indexes Rows in table Hints Without TF 610 With TF 610 Concurrent possible Heap Any TABLOCK Minimal Minimal Yes Heap Any None Full Full Yes Heap + Index Any TABLOCK Full Depends (3) No Cluster Empty TABLOCK, ORDER (1) Minimal Minimal No Cluster Empty None Full Minimal Yes (2) Cluster Any None Full Minimal Yes (2) Cluster Any TABLOCK Full Minimal No Cluster + Index Any None Full Depends (3) Yes (2) Cluster + Index Any TABLOCK Full Depends (3) No • Démo o Si la session suivante n‟a pas commencé ! Edition 2012 – 10 et 11 décembre
    37. 37. MINIMAL LOGGING - DEMO Edition 2012 – 10 et 11 décembre
    38. 38. AUJOURD’HUI … • Autres fonctionnalités disponibles • Encoding – convert to integers • Row ordering • Compression XVELOCITY COLUMNSTORE INDEX • Full Text • 15K partitions • Compression Requêtes plus rapides • 20 pools -> 64 • CPU Hard cap • Affinité NUMA Resource Governor • 640 logicel procs • RAM 4TB • Page Allocator Mémoire é CPU Edition 2012 – 10 et 11 décembre • Répartition de charge • Offload de backups AAG Routing list
    39. 39. ET DEMAIN ???? Edition 2012 – 10 et 11 décembre Photomontage !!! Le logo n’a rien d’officiel.
    40. 40. PROJET HEKATON • Dévoilé lors du PASS Summit 2012 • ΗΕΚΑΤΟΝ, • du Grèc ἑκατόν, hekatón, 100 • Disponible dans SQL Server vNext • Bases de données « En mémoire » • xVelocity columnstore index o Analyse de données o Basé colonne • Hekatón o Applications fortement transactionnelles o Basé ligne Edition 2012 – 10 et 11 décembre
    41. 41. PROJET HEKATON • Principes architecturaux • Optimisé pour des accès en mémoire • ACID • Fréquence de CPU stagne o Etre plus efficace o Compilation + agressive et en code natif • Elimination des locks & latches • Encapsulé dans SQL Server Edition 2012 – 10 et 11 décembre
    42. 42. MIGRATION VERS HEKATON • Stockage • Compilation native • Démo • (On ferme les portes de la salle, il faut vraiment voir cette démo) Edition 2012 – 10 et 11 décembre
    43. 43. DÉMO HEKATON Edition 2012 – 10 et 11 décembre
    44. 44. CONCLUSION Bravo pour avoir résisté à cette session ! SQL Server est prêt à supporter vos scénarii Mission Critical, autant d’un point de vue disponibilité que performance … Edition 2012 – 10 et 11 décembre
    45. 45. QUESTIONS / RÉPONSES Merci à tous pour votre présence et n’hésitez pas à venir poursuivre le débat sur les stands et profiter de démos supplémentaires. Whitepapers et autres documents disponibles sur SkyDrive : http://sdrv.ms/V7zSO2 Edition 2012 – 10 et 11 décembre
    46. 46. Merci à nos Sponsors Rencontrez les dans l’espace partenaires Sponsors Platinum Sponsors Gold Sponsors Silver Edition 2012 – 10 et 11 décembre