Running DE8 on Windows Servers, do and dont's (SMB1,SMB2,SMB3 and OpLocks)

With the release of DataEase 8.0, 8.1, 8.2 and Windows 7, 8 , 8.1 and Windows Server 2012 R2, we are frequently asked about how new versions of DataEase work when connecting to old versions of Windows servers and old versions of DataEase connecting to new versions of Windows servers etc.

In DataEase 8.0 we did an important and radical decision in defaulting to Opportunistic Locking and stop the previous locking recommendations. This in itself reduced the problems by a factor of 100 and increased network speed and reliability dramatically.

But there is still pranks to be played on you and in short they are called OpLocks (MS Opportunistic Locking not to be confused with our Opportunistic Locking) and Caching (Read ahead blocks), in short - SMB.

In this article we will discuss what problems you can expect and how to avoid them.

Upgrading to a new version of SMB is something that happened a few times over the years and we established a process in the protocol itself by which clients and servers negotiate the highest version that both support.

Versions

There are several different versions of SMB used by Windows operating systems:

CIFS The ancient version of SMB that was part of Microsoft Windows NT 4.0 in 1996. SMB1 supersedes this version.
SMB 1.0 (or SMB1) The version used in Windows 2000, Windows XP, Windows Server 2003 and Windows Server 2003 R2
SMB 2.0 (or SMB2) The version used in Windows Vista (SP1 or later) and Windows Server 2008
SMB 2.1 (or SMB2.1) The version used in Windows 7 and Windows Server 2008 R2
SMB 3.0 (or SMB3) The version used in Windows 8 and Windows Server 2012
SMB 3.02 (or SMB3) The version used in Windows 8.1 and Windows Server 2012 R2

Windows NT is no longer supported, so CIFS is definitely out. Windows Server 2003 R2 with a current service pack is under Extended Support, so SMB1 is still around for a little while. SMB 2.x in Windows Server 2008 and Windows Server 2008 R2 are under Mainstream Support until 2015. You can find the most current information on the support lifecycle page for Windows Server. The information is subject to the Microsoft Policy Disclaimer and Change Notice. You can use the support pages to also find support policy information for Windows XP, Windows Vista, Windows 7 and Windows 8.

In Windows 8.1 and Windows Server 2012 R2, we introduced the option to completely disable CIFS/SMB1 support, including the actual removal of the related binaries. While this is not the default configuration, we recommend disabling this older version of the protocol in scenarios where its not useful, like Hyper-V over SMB. You can find details about this new option in item 7 of this blog post: Whats new in SMB PowerShell in Windows Server 2012 R2.

Negotiated Versions

Heres a table to help you understand what version you will end up using, depending on what Windows version is running as the SMB client and what version of Windows is running as the SMB server:

OS	Windows 8.1 WS 2012 R2	Windows 8 WS 2012	Windows 7 WS 2008 R2	Windows Vista WS 2008	Previous versions
Windows 8.1 WS 2012 R2	SMB 3.02	SMB 3.0	SMB 2.1	SMB 2.0	SMB 1.0
Windows 8 WS 2012	SMB 3.0	SMB 3.0	SMB 2.1	SMB 2.0	SMB 1.0
Windows 7 WS 2008 R2	SMB 2.1	SMB 2.1	SMB 2.1	SMB 2.0	SMB 1.0
Windows Vista WS 2008	SMB 2.0	SMB 2.0	SMB 2.0	SMB 2.0	SMB 1.0
Previous versions	SMB 1.0	SMB 1.0	SMB 1.0	SMB 1.0	SMB 1.0

* WS = Windows Server

What is Opportunistic Locking?

Opportunistic locking (oplocks) is a Windows-specific mechanism for client/server databases to allow multiple processes to lock the same file while allowing for local (client) data caching to improve performance over Windows networks. Unfortunately, the default setting of the oplocks mechanism that enhances the performance of one type of database (client/server) also introduces data integrity issues for other database types (file system/ISAM i.e. DataEase).

Microsoft's documentation states "An opportunistic lock (also called an oplock) is a lock placed by a client on a file residing on a server. In most cases, a client requests an oplock so it can cache data locally, thus reducing network traffic and improving apparent response time. Oplocks are used by network redirectors on clients with remote servers, as well as by client applications on local servers" and "Oplocks are requests from the client to the server. From the point of view of the client, they are opportunistic. In other words, the server grants such locks whenever other factors make the locks possible.".

What is Read Caching?

Read caching, sometimes referred to as read-ahead caching, is a feature of oplocks. It is a technique used to speed network access to data files. It involves caching data on clients rather than on servers when possible.

The effect of local caching is that it allows multiple write operations on the same region of a file to be combined into one write operation across the network. Local caching reduces network traffic because the data is written once. Such caching improves the apparent response time of applications because the applications do not wait for the data to be sent across the network to the server.

Problems with read caching usually occur if something unforeseen happens, such as a workstation crash, where data is not properly flushed from the workstation, which can lead to data corruption.

Microsoft's documentation states that 'Under extreme conditions, some multiuser database applications that use a common data store over a network connection on a file server may experience transactional integrity issues or corruption of the database files and/or indexes stored on the server. This typically applies to some so-called "ISAM style", or "record oriented" multiuser database applications, not to a client/server relational system like SQL Server' and 'A hazard of local caching is that written data only has as much integrity as the client itself for as long as the data is cached on the client. In general, locally cached data should be flushed to the server as soon as possible.'

Running a DataEase Application on a Microsoft Server

DataEase is a file based Relational database and thus susceptible to the effects of the default Windows oplocks settings. Using a DataEase database on Windows networks without disabling oplocks is not recommended or supported and has a high likelihood of data corruption.

Reliable database operation on Windows Networks can be achieved provided that the network is properly configured. You can use the information in this paper to set up your Windows network's oplocks parameters. One downside to using this method are maintenance issues: you must continually ensure that each and every server and client using an application accessing the embedded database has oplocks disabled and are always maintained in that state.

Published: 03/12/14 - 16:11:37 (Amanda Higgins)

Last changed: 04/12/14 - 10:38:17 (Ulrik Jacob Hoegh - Krohn)