All this talk about databases and servers and sysadmins makes me wonder if we should reconsider our choice of operating systems and databases.
At one time in the past I ran a Database support group that covered Sybase, Oracle, Microsoft SQL server, ingres and half a dozen other database systems. The UNIX side, some twenty or so servers ran software that in theory monitored the databases. In practise it never really was upto date. Microsoft also had a very nice monitoring tool that monitored and suggested solutions. I've dropped an example report below. We ran probably fifty SQL server database servers and I spent quite a lot of time maxing the memory on a server then consolidating servers. Towards the end we had far more data running on SQL server than we did on the UNIX side. The servers were cheaper for the same performance for a start. Many of the UNIX based servers had default passwords set which made security a problem. Fortunately they were protected by an air gap from the Internet. We had an IBM mainframe in the mix with an old database on it. The programmers gradually retired. I was lucky and identified another government department that was switching away from it and we managed to grab a handful of programmers etc from them. Then a couple of years later that DBA retired. You need to think of the future. Will I be able to get knowledgeable staff if I need to? We had to pay the company to run a special course in Ottawa and that was not cheap by the time we put the trainer up in a hotel and paid his airfare from the states. Initially the Microsoft side suffered from lack of security but they hardened the operating system and SQL server to a point where it was the most secure combination. Microsoft SQL server was originally Sybase but got completely rewritten over time. On the support side my staff found that once we had set the permissions to an operating system group we just had to add people to the group. For other databases each person had to be given permissions individually which made for finger problems. The classic was one secure database that was supposed to be accessed operationally by 300 people. The problem was there were 600 accounts and no one knew which ones were needed or which could be deleted to reduce the surface area for attack. The integrated Microsoft monitoring system made reliability much better. There were far fewer problems on the Microsoft SQL side than on the UNIX / other database side and they were easier to fix. One of my less expert database admins was shocked by the ease of which he caught the problem and corrected it by himself after an alert. It gave him a bit of confidence as well. We changed to PostgreSQL in 2009. The size of the database was much smaller then. One thing we noticed was on the database tuning side. SQL server worked better if you just left it alone and didn't try to tune it. It would check what was in memory rather than go out to the disk drives and that made a big difference to performance. We measure disk access in milliseconds and memory access in nanoseconds. One is ten thousand times smaller than the other. On the reliability side there is a set of guidelines that are basically common sense. I forget the formal (ISO?) name but many organisations have seen considerable savings in money and in reliability by using them. I met the English guy who originated them at a Microsoft presentation. They can be applied to any environment. I think we either run the largest PostgreSQL database there is or it is close to it. From a reliability point of view my professional hat says this is not where you want to be. You want to be more mainstream with someone else being on the bleeding edge. So the heresy would be look at the implications of changing to Microsoft SQL server in the cloud. There is lots of documentation and given that Microsoft has worked closely with us in the past the cost might not be too bad. I do understand that we have a large investment in our current set up both as an organisation and personally and many will consider this as heresy but now is probably the time to think about it. Cheerio John Your message to rolland.desroc...@motioncares.ca couldn't be delivered. Rolland.desrocher wasn't found at motioncares.ca. jwhelan0112 Office 365 Rolland.desrocher *Action Required* Recipient Unknown To address How to Fix It The address may be misspelled or may not exist. Try one or more of the following: - Send the message again following these steps: In Outlook, open this non-delivery report (NDR) and choose *Send Again* from the Report ribbon. In Outlook on the web, select this NDR, then select the link "*To send this message again, click here.*" Then delete and retype the entire recipient address. If prompted with an Auto-Complete List suggestion don't select it. After typing the complete address, click *Send*. - Contact the recipient (by phone, for example) to check that the address exists and is correct. - The recipient may have set up email forwarding to an incorrect address. Ask them to check that any forwarding they've set up is working correctly. - Clear the recipient Auto-Complete List in Outlook or Outlook on the web by following the steps in this article: Fix email delivery issues for error code 5.1.10 in Office 365 <https://go.microsoft.com/fwlink/?LinkId=532972>, and then send the message again. Retype the entire recipient address before selecting *Send*. If the problem continues, forward this message to your email admin. If you're an email admin, refer to the *More Info for Email Admins* section below.
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
