[SQL] Omgaan met meerdere SQL versies

[Anoshky]

Situatieschets: wij bieden een zelfgeschreven applicatie aan die in de achtergrond steunt op een Microsoft SQL Server database.
Deze applicatie wordt bij de klant zelf gedeployed.

Probleem: door de jaren heen hebben we een wildgroei gekregen aan SQL Server versies.
We hebben klanten die onze databases draaien op 2008 (5%), 2008R2 (65%), 2012 (5%), 2014 (15%), 2016 (5%) en 2017 (5%).
We moeten deze databases soms terug naar onze servers halen voor troubleshooting, bijbestellingen, ...
Wat er voor zorgt dat we dus zelf een SQL server moeten draaien van al deze versies.

Klanten vragen om te upgraden is geen mogelijkheid, meerderheid van die klanten zijn te klein om een degelijke IT'er te betalen en bijgevolg weten de meeste van die lokale IT-contacten niet eens wat Management Studio is.

De exacte vraag is nu: hoe zouden jullie omgaan met SQL Server installaties?
Nu Microsoft jaarlijks nieuwe versies uitbrengt zal er nog een grotere variatie komen in gebruikte versies.
Zouden jullie de verschillende versies allemaal op één Windows Server installatie zetten of zouden jullie deze allen gaan opsplitsen?
Of de meest gebruikte versies op één server en de minder gebruikte versies allemaal samen op een andere server?

_{(Ik ga er van uit in bovenstaande dat wie hier op antwoord wel weet dat je een .bak file gemaakt op een nieuwere SQL versie niet kunt restoren op een oudere versie)}

[MAX3400]

N-1 ondersteunen voor betere patch- en lifecycle-management; en als klanten dat niet snappen (of kunnen betalen), hosted/SaaS aan gaan bieden.

Hou je dus je versioning, troubleshooting, monitoring en lifecycle voor 95% in eigen hand.

[GieltjE]

De grote vraag is of je die versies wel wilt ondersteunen, je kan je klanten minder goed helpen, het kost vaak meer voor de klant als er iets is (al is het maar aan tijd).

Je hebt ook niet een full-time ict'er nodig als klant om sporadisch een update uit te laten voeren, je zou het zelfs kunnen aanbieden tegen betaling (mooi stukje marketing erbij, sneller, veiliger (doet het tegenwoordig al beter als vroeger). Het lijkt mij (persoonlijk) echt geen toevoeging voor jullie of de klant om op oude versies te blijven hangen.

Wij ondersteunen zouzo niets wat microsoft zelf niet meer ondersteund (nog even en we kunnen windows 7 droppen.....), onze software forceerd de klants machines ook naar de laatste windows updates e.d. wat ons door de jaren heen regelmatig ellende heeft bespaard en het software onderhoud drastisch heeft versimpeld.

[Evilslayer]

Is één virtuele machine per SQL versie een mogelijkheid? Op die manier kan je ook het onderliggende OS afstemmen op de meest gebruikte SQL versie. Ik kan mij voorstellen dat de combinatie Windows 2008R2 vooral zal gebruikt worden icm SQL 2008(R2), terwijl SQL 2017 vooral zal Windows Server 2016 gebruiken (of Linux :-)). Deze virtuele machines zou je in theorie ook kunnen opstarten op het Microsoft Azure platform & enkel aanzetten wanneer nodig.
Licentiegewijs kan je de onderliggende hypervisor licentieren (Enterprise) of de individuele VM's. (Standard of Enterprise)
Verder, wat is de levensduur van jullie applicatie? Hoe gaan jullie om met nieuwe versies? Wat bij veel leveranciers gebeurd is dat er per applicatieversie ook een overeenkomstige SQL Supportability matrix hoort. Zo zullen de laatste versies niet meer ondersteund worden op 10j oude database platformen & hou je zelf ook meer controle over het geheel.

[desmond]

Je kunt databases in beperkte mate (een of twee versies terug, meen ik) in 'compatibility mode' draaien. Met de zes genoemde versies zit je dus aan maximaal 3 MSSQL installaties. Ik zou sowieso virtuele machines inzetten en één MSSQL installatie per VM doen - al dan niet in de cloud. Zo kun je alle configuraties goed van elkaar onderscheiden.

Persoonlijk vind ik het bij jullie dienstverlening behoren dat je de verkochte (ingebruikzijnde) configuraties moet kunnen reproduceren binnenshuis voor troubleshooting etc. Dat zou betekenen dat je zes VM's hebt draaien, die je prima kunt pauzeren als het teveel resources kost. Je kunt een business case opstellen om verouderde versies bij klanten te elimineren - misschien loont het om dit zelf op te pakken. Je kunt afscheid nemen van klanten die niet willen upgraden, je kunt onderhoudsfees voor verouderde versies verhogen om tegemoet te komen aan de extra kosten die jullie moeten maken (incentive om te upgraden).

Als software-leverancier is lifecycle-management heel belangrijk en het loont de moeite om een matrix op te stellen met ondersteunde software-platforms, inclusief toekomst.

[Question Mark]

Is de applicatie niet op SQL Express te draaien? Dan kun je deze versie zelf meeleveren en is er geen "echte" SQL server van de klant nodig.

Een SQL Expres DB mag tegenwoordig al 10 GB groot zijn. Nu is deze versie wel op nog meer vlakken geknepen, maar het is de vraag of je applicatie dit allemaal nodig heeft.

[Saven]

Waarom niet een soort cloudservice verkopen? Waarbij de database bij jullie draait zodat jullie zelf de SQL versies kunnen kiezen.

Klinkt als een lucratief businessplan. Ik stuur mn consultancyfactuur nog wel

Dit is tevens het antwoord op je vraag hoe ik dit zou aanbieden.

[JeroenV_]

Wij zitten in hetzelfde schuitje, maar hebben gewoon een stevige vm draaien met daarop de express versie van
2008
2008r2
2012
2014
2016
2017
naast elkaar.

Als je met de oudste begint kun je ze zo allemaal naast elkaar draaien in named instances. Eventueel kun je, om resources te besparen, de services allemaal op manual zetten en alleen degene starten die je nodig hebt op dat moment.

[Henkje.doc]

Je kan meerdere SQL versies naast elkaar op 1 server zetten, maar zelf doe ik dat in een productie of acceptatie omgeving eigenlijk nooit.

De klant dwingen naar een hogere versie is idd lastig, maar bedenk wel dat er op een specifiek moment depricated features zijn die niet meer ondersteunt worden.

Daarnaast maak je het vanuit ondersteuning wel erg lastig.

Met alleen SQL versies ben het niet. Dwing je ook een specifieke Collation af? Andere moet je daar ook rekening mee houden.

Ik zou toch echt een deel van de problematiek bij de system requirements leggen. Want als Microsoft met SQL 2008 support stopt of de klant heeft geen extended support moet deze toch over.

[CAPSLOCK2000]

Anoshky schreef op dinsdag 17 april 2018 @ 09:36:
Klanten vragen om te upgraden is geen mogelijkheid, meerderheid van die klanten zijn te klein om een degelijke IT'er te betalen en bijgevolg weten de meeste van die lokale IT-contacten niet eens wat Management Studio is.

Dat is geen houdbare situatie, vroeg of laat wordt dat onmogelijk.
Als je klanten het niet zelf kunnen (laten) doen zou je kunnen overwegen om het als dienst aan te bieden.
Ieder stuk software in de wereld heeft minimumeisen en moet af en toe worden gepatched.
Als je klanten de kosten niet maken om het zelf te onderhouden, dan zullen ze moeten betalen voor de kosten die jij moet maken om die oude versies intern te blijven draaien.
Als dat meer kost dan die klanten betalen dan moet je het gewoon niet doen.

[demokert]

Ik sluit me aan bij wat meerdere al schreven. Als het bedrijf het niet aan kan, zou je dit kunnen faciliteren, of hosting aanbieden.

Is SQL Express een optie?

Ik zou als leverancier zeggen; wij ondersteunen : SQL2012/2014/2016. En dit beleid kun je natuurlijk vanaf een bepaalde datum in kunnen laten gaan.

(Van SQL2008+R2 ben je volgend jaar "af" aangezien support verloopt ;-) )