Discussion :

[Tgaud]

Bonjour,


Je ne suis pas DBA, je suis développeur à Nice dans la grande consommation et mon projet fonctionne actuellement sous SYSBASE ASE.

On a une préférence pour SQL Server 2008, et l'on veut migrer (pas une vrai migration, juste recommencer sous cette nouvelle base), mais on nous demande de monter un dossier béton pour justifier ce changement, d'un point de vue développeur / DBA afin de justifier notamment le budget.

Pouvez vous m'aider à faire un inventaire des bénéfices de SQL server 2008 face à SYSBASE ASE ?
Et un bilan des grands défaults de SYSBASE ASE ?

Surtout en misant sur l'aspect volumétrie, performance, et possibilité/contraintes de dev
(même si c'est pas exclusif).

Environnement de developpement : Windows, C# Framework 4.0, SSIS
utilisation de pas mal de procédures stockées pour la restit de données
en mettant pas moins de 75 tables en utilisation à l'interieur.

Grosse base, grosse volumétrie, nombreux traitements de nuit, avec intégrations de données quotidiennes la nuit.



Merci de votre aide !

[Invité]

Grosse base, grosse volumétrie

Il faudrait quantifier ta pensée.
Une personne sur ce forum parlait d'une énorme base de données de 15 Go...
Tout est relatif...
75 tables, ce n'est rien de bien impressionnant. S'il y a 15 millions de lignes dans chaque, là, on change de registres.

[Tgaud]

600 000 lignes dans notre table principale (qui fait 83 colonnes).
soit 388 548 KB en taille.
(droppé et realimenté quotidiennement)

le reste cest juste des tables à volumétrie variable mais pas impressionante, qui viennent en jointure

les 75 tables c'est pas le total de la base, juste ce qui viens en jointure dans la même proc.

dont quelques tables à respectivement 720 140, 788000, 43 541 820 lignes
(la derniere fait 16 000 838 KB a elle seule)

(donc on sature facilement le fichier de transaction fixé a 8GO)

la charge d'un point de vue utilisateur peut monter à 100, qui chacun pourront lancer la même proc (mais en bossant chacun avec des tables temporaires).

la base fait 54 599 806 KB

Je sais pas si ça represente une grosse volumétrie ou pas..

[Ptit_Dje]

Bonjour,

Ca fait grosso-modo une base de 50GB.
Non, ce n'est pas enorme comme volumetrie...

83 colonnes ??? C'est une table de dimension ?
Pour quelle raison la dropper et la recreer quotidiennement ?

Avez vous deja une infrastructure SQL Server en place dans l'entreprise ?

Combien de stored procedure existent dans la base de donnees actuelle ?

Et... Pour quelle raison voulez-vous a priori changer de SGBD ?

[Tgaud]

_On drop et recré car les données sont actualisée totalement quotidiennement.


_On a 1000 stored procedure actuellement, mais il y en a de nombreuses obsolètes. pour ne pas dire la grande majorité.

_on a une archi sql server déjà en place, mais sur dautre projets, mais la mettre en place ne representera pas de probleme.

[Ptit_Dje]

Pour quelle raison voulez-vous a priori changer de SGBD ?

1000 stored procedure ca fait un paquet... Une migration impliquera de :
- Lister toutes les stored procedures utilisees
- Les migrer pour qu'elles soient compatible sur SQL Server

C'est un gros boulot...

Y a t'il des personnes dans la societe qui ont des connaissances SQL Server ?

[Tgaud]

On fait une refonte totale, donc aucune procedure ne restera tel quel de toute façon, on va meme recreer le schema de la base, cest donc loccasion de changer de SGBD.

En tant que dev on est habitué à utiliser SQL SERVER 2008.
(on est developpeur utilisant C# 4.0, SSIS etc.. habitué au full microsoft)
Deplus le set rowcount 100 puis le remettre à 0 car sybase sait pas faire un top100.. ou les procédure qui peuvent pas commit en plein milieu, ce qui implique des crash du au fichier de transaction trop plein.. ça nous embête pas mal.

Mais évidemment avec de tels arguments ça ne suffira pas à faire passer la migration.

Il faudrait que je prouve :
_ en Quoi Sql 2008 marche mieux avec SSIS et C# 4.0..
_ En quoi, Sql 2008 serait plus performant
_ ce qu'il apporterai en valeur ajouté de manière generale.

[Ptit_Dje]

Combien de temps en jour homme gagnez vous en terme de developpement en passant sur du SQL Server par rapport a Sybase ?
Quel cout en terme de licence/maintenance reduisez vous en passant sur SQL Server ?
Est ce que passer sur SQL Server va dans la direction de ce que fait l'entreprise en terme de technologies ?
...

Ne connaissant pas ce SGBD, je ne peux malheureusement pas vous aider a faire la comparaison alors je vous laisse quelques questions.

[Tgaud]

Bah disons que ma question n'est pas "dois je passer sur sql server"
On est certain de vouloir y passer, il faut juste pouvoir le justifier techniquement.

[Waldar]

De plus le set rowcount 100 puis le remettre à 0 car sybase sait pas faire un top100...

Je ne suis pas calé en Sybase mais ça me paraît faux :

Code :

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

1
2
3
4
5
6
7
8
select @@version;
 
-- Adaptive Server Enterprise/15.0.3 (...)
 
select top 100 *
  from <une_table>
 
--  100 enregistrement(s) sélectionné(s)

[Ptit_Dje]

En se basant sur ce document:
http://www.sybase.com/files/Data_She...trix_Nov09.pdf

Si tu as des serveurs en x64, tu peux argumenter que SQL Server le supporte beaucoup mieux, entre autre pour la high availability.
Ensuite je ne sais pas de quelles fonctions tu as besoin d'autre qui existent sur SQL Server et pas Sybase...

[Waldar]

Aucune fonction de fenêtrage sur Sybase ASE, ça peut être handicapant.

[Tgaud]

Merci, c'est ce genre de réponse que j'attend , continuez !

Waldar : le problem du top 100 sur sybase sans utiliser rowcount, cest qu'il fait d'abord un select *, puis te ramene les 100premier. Donc ça peut être super long.

Deplus je rapelle que sysbase est en version 12.5 donc il dois avoir encore plus de défaults que la version 15 !

[Tgaud]

En se basant sur ce document:
http://www.sybase.com/files/Data_She...trix_Nov09.pdf

Si tu as des serveurs en x64, tu peux argumenter que SQL Server le supporte beaucoup mieux, entre autre pour la high availability.
Ensuite je ne sais pas de quelles fonctions tu as besoin d'autre qui existent sur SQL Server et pas Sybase...

Le problème cest que les serveurs Sybase actuel sont hebergé sous unix..
Donc je pense qu'ils supporte le high availability en 64 bits (même si je sais pas cest quoi)
Reste à savoir si la version 12.5 le fait.

[Waldar]

Deplus je rapelle que sysbase est en version 12.5 donc il dois avoir encore plus de défaults que la version 15 !

Je vous bien que vous me rappeliez votre version, mais vous ne l'aviez jamais précisé

Comme indiqué, je ne suis pas féru des mécaniques internes de Sybase.
Je vous remercie pour l'information du "faux" top 100.

[Tgaud]

Je vous bien que vous me rappeliez votre version, mais vous ne l'aviez jamais précisé

C'est pas faux

[Tgaud]

A voir le nombre de réponse, on croirait que Sysbase ase 12.5 écrase ms server 2008...

[Ptit_Dje]

Je ne sais pas.
Tu peux comparer la liste des différences sur les sites des fournisseurs respectifs si c'est le point de vue technologique qui t'intéresse.
http://www.sybase.com
http://www.microsoft.com/sqlserver/2...s/default.aspx

C'est le mieux que je peux faire pour toi car je ne connais malheureusement pas Sybase.
Si tu peux ensuite partager ton rapport, ce serait vachement sympa !

[Tgaud]

Disons que c'est le point de vue pratique qui m'intéresse

[Waldar]

Sybase est relativement confidentiel : moins de 3% en 2007