Discussion :

[Mont73]

Bonjour,

Je me permets de poster ce petit message. Je n'ai trouvé de réponse sur la toile (peut-être que j'ai mal cherché ?).

A chaque redémarrage du serveur SQL SERVER, toutes les applications qui pointe dessus sont peu réactive.

J'ai regardé les performances du Server Hébergeant SQL SERVER. Je suis tombé sur une consommation poussé par le service SQL SERVER au niveau du process.
Aucun job ne se lance au démarrage de SQL SERVER.

Je n'arrive pas à voir plus d'information.

Je ne trouve pas la cause de cette monté en charge.

Je viens vous solliciter pour trouver la cause et une solution.
Merci d'avance,

[SQLpro]

C'est parfaitement normal qu'au redémarrage les applications soient très lente. Il est d'ailleurs fortement déconseillé d'arrêter un serveur SQL que ce soit au niveau de la machine (physique ou virtuelle) comme au niveau du service.

En effet, un SGBDR de type client/serveur comme Oracle, SQL Server ou DB2, place le maximum de données en cache (donc en mémoire) pour éviter des accès disques. Toutes les requêtes, lectures comme écritures, sont donc réalisées en mémoire, avant d'être reportées ultérieurement sur le disque (de manière asynchrone).
En arrêtant votre serveur SQL, vous détruisez toute le mise en cache et recommencez par "bouffer" du disque au lieu d'accéder à la mémoire… Sachant que le disque est, au bas mot, 1000 fois moins rapide que la RAM, les lenteurs seront immédiatement visible par tous les utilisateurs.

En conclusion, un serveur SQL ne doit JAMAIS être arrêté !

Et pour apprendre bien des choses sur SQL Server, lisez notre livre :


A +

[Mont73]

C'est parfaitement normal qu'au redémarrage les applications soient très lente. Il est d'ailleurs fortement déconseillé d'arrêter un serveur SQL que ce soit au niveau de la machine (physique ou virtuelle) comme au niveau du service.

En effet, un SGBDR de type client/serveur comme Oracle, SQL Server ou DB2, place le maximum de données en cache (donc en mémoire) pour éviter des accès disques. Toutes les requêtes, lectures comme écritures, sont donc réalisées en mémoire, avant d'être reportées ultérieurement sur le disque (de manière asynchrone).
En arrêtant votre serveur SQL, vous détruisez toute le mise en cache et recommencez par "bouffer" du disque au lieu d'accéder à la mémoire… Sachant que le disque est, au bas mot, 1000 fois moins rapide que la RAM, les lenteurs seront immédiatement visible par tous les utilisateurs.

En conclusion, un serveur SQL ne doit JAMAIS être arrêté !

Et pour apprendre bien des choses sur SQL Server, lisez notre livre :


A +

Bonjour,
Si je vous suis dans votre réflexion.
Le comportement est normal.

Et donc il ne faut pas mettre l'application sur le même serveur que la base de données.
Car la maintenance de l'application qui demanderait un reboot serveur pénaliserait les performances de la base de données au démarrage.

Merci de votre aide à la compréhension.

P.s. j'ai acheté le livre que vous citez mais j'ai pas encore eu le temps de le lire.

[Michel.Priori]

Et donc il ne faut pas mettre l'application sur le même serveur que la base de données.
Car la maintenance de l'application qui demanderait un reboot serveur pénaliserait les performances de la base de données au démarrage.

Comment justifier la position inverse ???

Ça parait évident que d'avoir 2 machines au lieu d'une permettra de bénéficier de plus de puissance (du delta près du réseau)
De plus d'un point de vue sécuritaire, la compromission du serveur applicatif (ça c'est déjà vu ) n'atteindra pas directement les données en base (à condition que les accès ne soient pas faits en tant qu'un Sysadmin bien sûr, et que ...plein de choses trop longues à lister ce soir)

Il ne faudra pas imaginez non plus que la séparation va complètement éviter les reboot de maintenance du serveur SQL dédié.

Quand vous parlez de :
* "ralentissement", c'est de quel ordre ?
* "toutes les applications qui pointent dessus", il y en a combien ?

Avez vous testé la consommation CPU et disque lors du redémarrage des applis avec SQL serveur éteint ?

[SQLpro]

Bonjour,
Si je vous suis dans votre réflexion.
Le comportement est normal.

oui

Et donc il ne faut pas mettre l'application sur le même serveur que la base de données.

jamais et pas que pour cette raison...

Car la maintenance de l'application qui demanderait un reboot serveur pénaliserait les performances de la base de données au démarrage.
....

En effet, car un SGBDR a un fonctionnement particulier qui est en opposition totale avec tous les autres applications.
1) c'est lui et non l'OS WIndows qui génère directement la RAM : i met en cache les données, les procédures, les plans d'exécution des requêtes, etc... Il n'y a donc que lui qui sait ou se trouve telle ou telle information; Dans SQL Server il y a près d'une centaine de niveaux de cache.... ! Vous pouvez voir cela à l'aide de la commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

DBCC MEMORYSTATUS

2) c'est lui, et non l'OS Windows, qui gère les threads des différents utilisateurs, et pour un même utilisateurs les threads d'une même requête lorsqu'elle est parallélisée. Vous pouvez voir cela à l'aide de la commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM sys.dm_os_threads

3) pour des raisons d'efficacité, c'est lui et non l'OS Windows, qui effectue les E/S (Entrées/Sorties - aussi appelées IO en anglais pour Input/Output) c'est à dire les lectures et écritures disque et RAM. Vous pouvez voir cela avec la commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT DB_NAME(mf.database_id) as DATABASE_NAME, mf.name AS FILE_NAME, 
       mf.physical_name AS FILE_LOCATION, vfs.* 
FROM   sys.master_files AS mf
       CROSS APPLY sys.dm_io_virtual_file_stats(database_id, file_id) AS vfs

En conclusion, un SGBDR comme SQL Server ou Oracle ou IBM DB2 incorpore un OS et ne repose pas directement sur l'OS Windows pour la plupart des tâches, sauf pour l'accès au réseau.
Pour information, le nom de l'OS intégré à SQL Server est "SOS", c'est à dire Sql server Operating System... et c'est la raison pour laquelle vous trouverez de nombreuses vues systèmes qui contienne l'acronyme OS :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
dm_os_hosts
dm_os_memory_brokers
dm_os_memory_allocations
dm_os_loaded_modules
dm_os_memory_objects
dm_os_schedulers
dm_os_server_diagnostics_log_configurations
dm_os_dispatcher_pools
dm_os_threads
dm_os_file_exists
dm_os_waiting_tasks
dm_os_sublatches
dm_os_buffer_pool_extension_configuration
dm_os_wait_stats
dm_os_memory_node_access_stats
dm_os_spinlock_stats
dm_os_dispatchers
dm_os_stacks
dm_os_ring_buffers
dm_os_volume_stats
dm_os_memory_clerks
dm_os_cluster_properties
dm_os_child_instances
dm_os_host_info
dm_os_memory_broker_clerks
dm_os_memory_cache_clock_hands
dm_os_sys_memory
dm_os_nodes
dm_os_memory_cache_entries
dm_os_virtual_address_dump
dm_os_memory_cache_hash_tables
dm_os_worker_local_storage
dm_os_buffer_descriptors
dm_os_enumerate_filesystem
dm_os_memory_cache_counters
dm_os_memory_pools
dm_os_latch_stats
dm_os_sys_info
dm_os_performance_counters
dm_os_workers
dm_os_enumerate_fixed_drives
dm_os_tasks
dm_os_memory_nodes
dm_os_windows_info
dm_os_cluster_nodes
dm_os_process_memory

Bien entendu l'OS de SQL Server agit en toute indépendance de l'OS Windows et SQL Server ne sait pas du tout ce que font les autres applications sous le contrôle de Windows... tant est si bien que SQL Server peut prendre tous les threads, monopoliser l'accès disque et capturer toute la mémoire au détriment de toutes les autres applications !
C'est pourquoi il faut un serveur dédié et donc aucune autres application d'aucune sorte (exécutable, service....) ne doit s'exécuter dessus !

A +

[Michel.Priori]

Je suis tombé sur une consommation poussé par le service SQL SERVER au niveau du process.

et pas des disques ???

Il se passe beaucoup de choses pendant le (re)démarrage de SQL (recovery, reconstruction de Tempdb, allocation mémoire, audit, triggers, ...) mais tout ça est plus ou moins corrélé avec l'activité disque.
Il parait qu'il y a de bons livres

Aucun job ne se lance au démarrage de SQL SERVER.

ça c'est normal
Les jobs peuvent être planifiés pour démarrer au démarrage de l'agent. Et l'agent c'est pas SQL !
Si le redémarrage du serveur met le moteur à genoux, le fait de retarder le redémarrage de l'agent peut être un moyen de gérer les priorités.