Migration 2005 2012 Accès concurrents

Bonjour,
Nous venons juste de remplacer le SQL Server 2005 d'une application java hibernate avec un SQL server 2012. Depuis ce changement, l'application génère des erreurs :( : Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect). N'y aurait il pas une modification des paramètres d'isolation par défaut entre 2005 et 2012 ? Auriez-vous une idée du (des) paramètres sur lesquels je pourrais agir sur le 2012 afin de retrouver un fonctionnement nominal de mon application svp ?

Bonjour en quel niveau d'isolation était votre base avant la migration ?

Essayez de la passer dans le mode suivant :

Code:

---

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

---

Attention c'est le niveau de transaction le plus restrictif possible !

un peu de doc :

https://msdn.microsoft.com/fr-fr/library/ms173763.aspx

rorgmanche ,

Notez que le message que vous avez indiqué n'est pas un message SQL Server. Ce message ne provient donc pas du moteur SQL Server.
Ce message provient de vos composants ORM Java hibernate etc.

Le niveau d'isolation par défaut que ce soit sous Server 2005 ou sous sous SQL Server 2012 est READ COMMITED. Ce mode d'isolation convient très bien à la plus part des situations.

Le mode d'isolation "Sérialisable" indiqué par julien94320 est le niveau d'isolatio le plus élevé. Il est comme cela a été indiqué très "contraignant"; il peut être requis mais uniquement pour certains traitements très particuliers, généralement pour l'attribution de numéros "fonctionnel" uniques, lorsque les autres techniques telle que IDENTITY, SEQUENCE, GUID Etc.. ne peuvent être appropriés, compte tenu des considérations généralement d'ordre métier fonctionnel.
ou lors de traitement très critiques où la cohérence et la consistance des données sont requises.

Personnellement, je n'ai jamais rencontré ni vu une application qui fonctionne uniquement et tout le temps en mode d'isolation Sérialisable, quelle que soit la nature du traitement !

Parmi les effets secondaires de la concurrence d'accès, la lecture non renouvelable reste possible sous le niveau d'isolation READ COMMITED, mais ni la "lecture incorrecte" ni l'apparition des "Fantômes" ne sont tolérées dans ce mode.

A+

Bonjour à tous les 2.

@hmira: S'il s'avère bien que la configuration par défaut n'a pas été modifiée entre SQL Server 2005 et 2012, je me demande bien ce qui entraîne ce probleme. D'après votre réponse hmira, vous semblez m'indiquer de chercher du côté d'hibernate. Le problème est que l'application fait + de 16000 lignes de code et qu'il y a des tags hibernate de partout. Certes ce n'est pas un message du server mais le server peut générer ce message...

@julien94320: j'essaie votre proposition

Citation:

---

Envoyé par rorgmanche

Bonjour à tous les 2.

@hmira: S'il s'avère bien que la configuration par défaut n'a pas été modifiée entre SQL Server 2005 et 2012, je me demande bien ce qui entraîne ce probleme. D'après votre réponse hmira, vous semblez m'indiquer de chercher du côté d'hibernate. Le problème est que l'application fait + de 16000 lignes de code et qu'il y a des tags hibernate de partout. Certes ce n'est pas un message du server mais le server peut générer ce message...

@julien94320: j'essaie votre proposition

---

Pour vous assurer que la configuration est identique entre les deux serveurs, lisez les données de la vue
sys.configurations
des deux serveurs et comparez... Postez vos différences

Pour vous assurer que la configuration des bases est identique entre les deux bases, lisez les données de la vue :
sys.databases
pour la base considérée et notez les différences

En principe vous ne devriez rien trouver de significatif.

Par expérience, je peut vous dire que la majorité des problèmes viennent de Hibernate qui est la pire merde que l'on pouvait faire en matière de dev !

Je parierait sur le fait d'une différence de fonctionnement lié à de mauvais accès réseau, middleware ou OS
les crétins qui ont développés Hibernate ayant utilisé la plupart du temps des éléments totalement obsolète (par exemple le fameux SET NOCOUNT ON obligatoire pour les PS !).

Les nombreux audit que j'ai mené avec cette merde infâme (et je pense que Julien me contrediras pas... ;-)) montre que c'est une catastrophe et que l'on est toujours emmerdé par cette horreur...

A +


A +

Citation:

---

Envoyé par rorgmanche

@hmira: S'il s'avère bien que la configuration par défaut n'a pas été modifiée entre SQL Server 2005 et 2012, je me demande bien ce qui entraîne ce probleme. D'après votre réponse hmira, vous semblez m'indiquer de chercher du côté d'hibernate. Le problème est que l'application fait + de 16000 lignes de code et qu'il y a des tags hibernate de partout. Certes ce n'est pas un message du server mais le server peut générer ce message...

---

Oui, c'est exactement ce que je voulais dire.

Sinon, côté instance et base de données SQL Server, en plus des remarques et les demandes de vérifications pertinentes formulées par SQL Pro, il est, en outre, fortement conseillé, si ce n'est pas déjà fait, d'effectuer, à minima, les opérations suivantes :
1 - Vérifier le mode de compatibilité de la base et le cas échéant, le changer en mode de compatibilité SQL Server 2012.
2 - Et, c'est le plus important, Effectuer immédiatement, avant même d'utiliser les applications, un "Rebuid" de tous les indexes de la base, ce qui aura pour effet de mettre à jour les statistiques, du moins les statistiques des colonnes impliqués dans les indexes cluster ou non cluster, d'invalider les plans en cache.
Les plans d'exécutions seront ensuite recrées au moment de leur prochaine exécution, mais cette fois-ci, ceux-ci seront basés sur des statistiques exactes, conformes aux stratégie du moteur SQL Server 2012.

PS : La liste ci-dessous n'est pas exhaustive.

A+

Citation:

---

Envoyé par SQLpro

Les nombreux audit que j'ai mené avec cette merde infâme (et je pense que Julien me contrediras pas... ;-)) montre que c'est une catastrophe et que l'on est toujours emmerdé par cette horreur...

---

A ça non je vais pas te contredire la dessus ! :ptdr: :mouarf:

Comme l'a dit SQL Pro on s'est souvent cassé les "dents" lors d'audit car la couche supplémentaire apporté par Hibernate est un veritable frein pour le moteur (essayez de privilegier les Procedures Stockées).

Si vous avez la main sur l'ancien serveur verifier les éléments cités par SQL PRO au niveau de la couche isolation ...

Citation:

---

Envoyé par Hmira

Et, c'est le plus important, Effectuer immédiatement, avant même d'utiliser les applications, un "Rebuid" de tous les indexes de la base, ce qui aura pour effet de mettre à jour les statistiques, du moins les statistiques des colonnes impliqués dans les indexes cluster ou non cluster, d'invalider les plans en cache.
Les plans d'exécutions seront ensuite recrées au moment de leur prochaine exécution, mais cette fois-ci, ceux-ci seront basés sur des statistiques exactes, conformes aux stratégie du moteur SQL Server 2012.

---

Je suis completement d'accord avec hmira il ne FAUT SURTOUT PAS OUBLIER de mettre a jour les statistics en mode FULL SCAN et un rebuild d'index afin que le moteur trouve un comportement "approprié" (Pour info : SQL Server mets a jour les statistiques automatiquement en mode FULL SCAN lors d'un rebuild d'index)


Comme Hmira l'a cité par défaut SQL Server est en mode d'isolation READ COMMITED quelque soit la version (SQL 2005 ou 2012) mais vous avez pu le changer sur votre ancienne instance ... A vous de verifier et de reporter les réglages (idem pour le parrallélisme etc ...)

Malheureusement, j'ai hérité de cette application. Je vous accorde que l'utilisation d'hibernate semble quelque peu exotique par endroit. Je note bien tout ce que vous évoquez et vous remercie.

@Hmira: 1/ j'ai essayé tous les modes d'isolation, même résultat
2/ Concernant les opérations conseillées, je dois trouver comment faire (mode compatibilité de la base et rebuild des indexes) et posterai le résultat

@SQLpro: Je dois chercher comment faire aussi mais je compte bien rapidement comparer les configurations citées (sys.configurations et sys.databases) merci, je reviens sur le forum

A vous lire, je suis quand même inquiet

Cela me semble quand même bizarre de ne rien trouver dans la littérature sur un changement de serveur. Nous comptons éventuellement upgrader le framework hibernate une fois épuisé les recours sur le server. Il est probable que l'utilisation faite d'hibernate laisse à désirer...

Citation:

---

Envoyé par rorgmanche

Cela me semble quand même bizarre de ne rien trouver dans la littérature sur un changement de serveur.

---

1) de quelle littérature parlez vous ? Dans notre livre sur SQL Server nous en parlons bien :
Pièce jointe 213827
Et c'est normal que vous ne trouviez pas grand chose, car mise à part de recalculer les stats lors d'une migration, il n'y a rien d'autre qui pourrait poser de petites problèmes...

2) en revanche du côté d'hibernate, vous trouverez de très nombreux papier consacré à comment réparer les horreurs produite par ce système particulièrement débile !

Citation:

---

Nous comptons éventuellement upgrader le framework hibernate une fois épuisé les recours sur le server. Il est probable que l'utilisation faite d'hibernate laisse à désirer...

---

Mais entre nous et à votre avis entre la crédibilité de MS et celle de développeurs boutonneux qui ont pissé une merde comme hibernate.. De quel côté penchant les problèmes ?

A +

Bonjour à tous,
@sql pro
tu dis ceci :

Citation:

---

Je parierait sur le fait d'une différence de fonctionnement lié à de mauvais accès réseau, middleware ou OS
les crétins qui ont développés Hibernate ayant utilisé la plupart du temps des éléments totalement obsolète (par exemple le fameux SET NOCOUNT ON obligatoire pour les PS !).

---

Dans un document avec 20 requetes(http://blog.developpez.com/sqlpro/fi...onnees-SQL.pdf) pour auditer la structure de votre base de données que tu as écrit je vois ceci

Citation:

---

Le paramétrage SET NOCOUNT ON évite d'envoyer en permancence et pour chaque
requête (SELECT, INSERT, UPDATE, DELETE) un message précisant le nombre de
lignes impactées.

Ce type de message est très rarement traité par les applications clientes
mais constitue des trames d'octets qui voyagent entre le serveur et les
applications clientes.
-- En pratique toutes les routines (procédures stockées et déclencheurs)
devraient commencer par cette directive (SET NOCOUNT ON;) afin d'interdire ces
messages intempestifs.
-- Notez que le template de créaton des routines proposée par SSMS (l'IHM
associées à SQL Server pour les développeurs) propose systématiquement cette
directive.

---

Dois je comprendre que cette information est obsolète et qu'il ne faut plus agir de la sorte?

Merci d'avance,
Loïc