SQL Server (RSS)

SQL Server

Unsafe LAMP? Open Source LAMP software more bugs than Microsoft's stack

After:

IIS6 has less bugs than Apache
SQL Server is more secure than MYSQL
ASP.NET is more secure than PHP

now this at http://blogs.zdnet.com/Ou/index.php?p=103

On the linux vs Windows front it's pretty much even without browsers I guess, with Firefox installed a LAMP box is definitely not a safe boat

 

 

 

SQL Server scalability perception

SQL Server scalability perception

In the last serveral consulting gigs I always came across people stating " SQL Server does not scale".
Now, I' ve tried to analyze these "opinions":


Hardware:
SQL Server does only run on Windows, which does not support proprietary CPUs like Sparc, Power or the mainframe ones.

Big Iron hardware(Midrange and Enterprise):
32 bit
> 4 way : some vendors have > 4 way support (but Dell does not anymore)
> 8 way : only IBM, Unisys and Fujitsu have servers running > 8 way (and BTW, shame on you HP, you threw away all of Compaq's technical excellence)

64 bit (still not proven despite 100 + casestudies)
AMD does not have > 8 way yet
Itaniums have excellent scalability (see HP's 64 way boxes), but are not mainstream


Software
W2K and W2k3 have 32-way 32 bit support, but are relegated to expensive Datacenter above 8-way.
W2K and W2k3 have a decent Itanium 64 bit track record, but haven't been able to wink the market, because of lack of a Standard version of Windows Server, but also because of a lack of
software and general purpose programming environments(like .NET).


What can MS do?
- push customers towards hardware vendors which "deliver" the right kind of hardware
- push 64 bit and Itanium in particular
- change the licensing/pricing to allow servers to use up to 16-way boxes with Advanced Server
- demonstrate the right kind of case studies (> 8 CPUs, 1 TB + implementations)

 

Now, back to those infidels not believing in SQL Server scalability:
with the right kind of hardware it can be done.

 

Some of my other posts:

http://dotnetjunkies.com/WebLog/stefandemetz/archive/2004/11/16/32249.aspx
http://dotnetjunkies.com/WebLog/stefandemetz/archive/2004/11/07/31275.aspx
http://dotnetjunkies.com/WebLog/stefandemetz/archive/2004/05/16/13724.aspx
http://dotnetjunkies.com/WebLog/stefandemetz/archive/2004/03/04/8474.aspx

Yukon and the 64 bit story

Besides my personal interest in SQL Server 2005 , at work I am asked to plan ahead for deployment of Yukon. As the company itself is in the midst of a technology transition, including an investment and future proof database platform, I am was considering 64 bit Yukon. 

But from MS the 64 bit story is not very good in regards to Yukon (and Itanium in particlar). And I am a bit worried. With all the BI goodness in Yukon, without a good 64 bit story, how can one take THE right decision?   

I know that 64 bitness will be included in beta 3, but is it not a bit late?

 

some links:

http://www.microsoft.com/sql/64bit/default.asp
http://www.informit.com/articles/article.asp?p=170820
http://www.ftponline.com/vsm/2004_en/magazine/features/rjennings/
http://weblogs.asp.net/tims/archive/2004/06/28/167675.aspx
http://www.microsoft.com/seminar/events/series/msdn64bitwin.mspx
http://www.lemanix.com/nick/archive/2004/09/11/1261.aspx
http://blogs.sqlxml.org/vinodkumar/archive/2004/01/16/328.aspx
http://www.thespoke.net/MyBlog/Hirantha/MyBlog.aspx
http://www.bsdg.org/2004/09/get-ready-for-net-20-with-danny-thorpe.shtml

Myth debunking: SQL Server vs MySQL security 2003-2004(SQL Server has less bugs !!)

MS SQL Server (or MSDE) vs MySQL

Seems that yet again a MS product has less bugs that the corresponding LAMP product (here are unscientific reports for ASP.NET vs PHP and IIS6 vs APACHE)

MSSQL    2003    12 
MySQL    2003     12 + 1 multiple (2003-10-30:  MySQL Multiple Vulnerabilities )

MSSQL     2004    3 
MySQL      2004    8

Am sure everybody will get (yet again) into splitting hairs as which is more or less secure, depending on
lines of code, number of installations, Service Packs vs latest build, etc etc

This is the list:

  2004-10-07:  MySQL MaxDB WebDBM Server Name Denial of Service Vulnerability
  2004-09-30:  MySQL Unspecified Insecure Temporary File Creation Vulnerability
  2004-09-27:  MySQL Bounded Parameter Statement Execution Remote Buffer Overflow Vulnerability
  2004-09-07:  MySQL Mysqlhotcopy Script Insecure Temporary File Creation Vulnerability
  2004-07-08:  MySQL Authentication Bypass Vulnerability
  2004-07-05:  MySQL Password Length Remote Buffer Overflow Vulnerability
  2004-05-25:  MySQL MYSQLD_Multi Insecure Temporary File Creation Vulnerability
  2004-05-25:  MySQL Aborted Bug Report Insecure Temporary File Creation Vulnerability
  2003-11-24:  MySQL Password Handler Buffer Overflow Vulnerability
  2003-10-30:  MySQL Multiple Vulnerabilities
  2003-09-18:  MySQL mysqld Privilege Escalation Vulnerability
  2003-09-18:  MySQL Double Free Heap Corruption Vulnerability
  2003-07-22:  MySQL AB ODBC Driver Plain Text Password Vulnerability
  2003-06-12:  MySQL libmysqlclient Library mysql_real_connect() Buffer Overrun Vulnerability
  2003-05-12:  MySQL COM_CHANGE_USER Password Memory Corruption Vulnerability
  2003-05-12:  MySQL libmysqlclient Library Read_One_Row Buffer Overflow Vulnerability
  2003-05-12:  MySQL COM_CHANGE_USER Password Length Account Compromise Vulnerability
  2003-05-12:  MySQL libmysqlclient Library Read_Rows Buffer Overflow Vulnerability
  2003-05-12:  MySQL COM_TABLE_DUMP Memory Corruption Vulnerability
  2003-05-05:  MySQL Weak Password Encryption Vulnerability
  2003-03-07:  MySQL Control Center Insecure Default File Permission Vulnerability


  2004-08-24:  Microsoft SQL Server User Authentication Remote Buffer Overflow Vulnerability
  2004-04-14:  Microsoft Remote Procedure Call Service DoS Vulnerability
  2004-04-07:  Microsoft SQL Server 2000 Resolution Service Stack Overflow Vulnerability
  2003-07-25:  Microsoft SQL Server / MSDE Named Pipes Privilege Escalation Vulnerability
  2003-07-25:  Microsoft SQL Server LPC Port Request Buffer Overflow Vulnerability
  2003-07-25:  Microsoft SQL Server / MSDE Named Pipe Denial Of Service Vulnerability
  2003-07-25:  Microsoft SQL Server / MSDE Multiple Vulnerabilities
  2003-07-15:  Microsoft SQL Server JET Database Engine 4.0 Buffer Overrun Vulnerability
  2003-06-16:  Microsoft SQL Server 2000 Resolution Service Heap Overflow Vulnerability
  2003-06-04:  Microsoft SQL MS Jet Engine Unicode Buffer Overflow Vulnerability
  2003-02-01:  Microsoft SQL Server 7.0/2000 DBCC Buffer Overflow Vulnerability
  2003-02-01:  Microsoft SQL Agent Jobs Privilege Elevation Vulnerability
  2003-02-01:  Microsoft SQL Server Extended Stored Procedure Privilege Elevation Vulnerability
  2003-01-27:  Microsoft SQL Server Web Task Stored Procedure Privilege Escalation Vulnerability
  2003-01-25:  Microsoft SQL Server 2000 Bulk Insert Procedure Buffer Overflow Vulnerability

(Figues provided by http://www.securityfocus.com/bid/vendor/)

.NET and integration with BCP


add following at beginning of the web.config between <configuration> and <system.web> tags

<configSections>
<section name="myapp_bcp_config"
type="System.Configuration.SingleTagSectionHandler,system, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</configSections>


add following after closing </appSettings> tag

    <myapp_bcp_config
 bcp_Tbl = "destDB..destTable"
 bcp_usr = "myUser"
 bcp_pwd = "myPWD"
 bcp_SRVR = "myServer"
 bcp_format = "myapp_bcp_format.fmt" <!--- or custom stuff like -c -f2 depending on database vendor  --->
     />


load config values

    Sub loadParamConfig()
        Dim valueTable As IDictionary = CType(ConfigurationSettings.GetConfig("myapp_bcp_config"), IDictionary)
        bcp_Tbl = valueTable("bcp_Tbl")
        bcp_usr = valueTable("bcp_usr")
        bcp_pwd = valueTable("bcp_pwd")
        bcp_SRVR = valueTable("bcp_SRVR")
        bcp_format = valueTable("bcp_format")
    End Sub

build command

    Function buildBcpCmd(fileName as string)
        Dim sb As New System.Text.StringBuilder()
        sb = New System.Text.StringBuilder()
 '
        sb.Append(bcp_Tbl & " in " & fileName & " ")
        sb.Append("-U " & bcp_usr & " ")
        sb.Append("-P " & bcp_pwd & " ")
        sb.Append("-S " & bcp_SRVR & " ")
        sb.Append("bcp_format)
        Return sb.ToString
    End Function

run command

 invoke sub below with fowwing line of code
 runcmd("bcp", buildBcpCmd("myfile.txt"))

  
 '
        Sub runcmd(ByVal cmd As String, ByVal exeTxt As String)
            Dim proc As System.Diagnostics.Process
            Dim StartProcessInfo As New System.Diagnostics.ProcessStartInfo()
            proc = New System.Diagnostics.Process()
            StartProcessInfo.UseShellExecute = False
            StartProcessInfo.RedirectStandardOutput = True
            StartProcessInfo.RedirectStandardError = True
            StartProcessInfo.FileName = cmd & ".exe "
            StartProcessInfo.Arguments = exeTxt

            proc.EnableRaisingEvents = True
            Try
                ' start
                proc = proc.Start(StartProcessInfo)
                ' end
                procOut = proc.StandardOutput().ReadToEnd()
                procError = proc.StandardError().ReadToEnd()
  'wait
                proc.WaitForExit()
                ' check exit code
                If Not proc.ExitCode = 0 Then
  ' output message and log
                End If
            Catch cmdExecEx As System.ApplicationException
  ' log stuff
                Throw cmdExecEx
            Finally
             proc.Close()
             proc.Dispose()
             proc = Nothing
    End Try  
        End Sub

SQL Server 2005 Yukon clustering

Despite all my love for SQL Server and Yukon(for it's BI features) I am frustrated by it less then optimal clustering features. Now,
since the launch of the SQL Server 2005 Yukon Beta 2 was yesterday, I don't want to be a party pooper or risk a future "red pill" offer.
But, historically Oracle and DB2 have been more advanced in high availability and I hoped that SQL Server would catch up on the clustering side. But even in it's 2005 incarnation it didn't. MySQL seems to have done it, albeit I don't have the details ready.

"My" sort of clustering would have meant a sort of load balancing, at least for read-only operations. Considering reporting or applications like .Text, where reads make up at least 95% of the total load. Probably more than 80% of applications do m ore than 80% of reads. That means that you could cluster 5 boxes in load balancing, of which 1 does the writing - CRUD stuff - and the other 4 do the reading. Of the 4 one could even do the admin stuff(index building, DBCC checking), so that the 1 is free of admin work. If the "writing" box failed,