Point41

Reseeding Identity Columns for Replication

admin — Thu, 13 Aug 2009 21:24:22 +0000

As a software developer/architect in this era of downsizing and people becoming Jacks of all Trades, I frequently find myself in a situation where I have to do DBA stuff. In one particular case, I am maintaining two databases which are peer-to-peer replicated. The databases support a web application for a primary site and a disaster recovery (DR) site.

Though already running in production mode, the web application is still changing because new features are being added on a daily basis. As a result of this, schema changes are pushed to the database almost weekly and I just don’t have the time to maintain the SQL scripts required to keep replication in sync with the schema changes. It is much easier to just: 1) take down replication and delete the DR database, 2) update the schema on the primary database, 3) restore a new copy of the second DR from a backup of the primary, 4) reseed identity columns on the DR database, 5) set up replication from scratch.

It may sound stupid, but whatever. Setting up replication from scratch through the UI works out to be easier than maintaining the change scripts required to keep several hundred tables properly replicated while new tables are columns are being constantly added. The only pain-in-the-ass part of this method is that the identity columns of hundreds of tables in the DR database need to be reseeded each time. Fortunately this can be done quickly.

Our rule is that indentity columns of type int should have values in the range of 1 – 1073741823 on the main database, and on the second database the range should be 1073741824 and up. For bigint it should be 1 – 10737418239 on the main database and 10737418240 and up on the second database.

So for a table tbl_abc which has an identity column of type int to run the following 2 SQL statements on the DR database:



dbcc checkident('tbl_abc', RESEED, 1073741824)

dbcc checkident('tbl_abc', RESEED)

The first sets the seed value to 1073741824. However, the application might have previously failed over to the DR database and there may already be rows with identity columns having a value of 1073741824 and up. The second statement above correcly sets the seed to the next available value, if 1073741824 is already used.

The output of following SQL script will generate the pair DBCC statements for all tables in the database named ‘tbl_%’.



select

'dbcc checkident(''' + st.name + ''',RESEED,' + case when sc.system_type_id = 56 then '1073741824)' else '10737418240)' end

from sys.tables st

inner join sys.columns sc on sc.object_id = st.object_id

where st.name like 'tbl_%'

and sc.is_identity = 1
select

'dbcc checkident(''' + st.name + ''',RESEED)'

from sys.tables st

inner join sys.columns sc on sc.object_id = st.object_id

where st.name like 'tbl_%'

and sc.is_identity = 1

The output needs to be captured as text and cleaned up a little (remove headers, etc.), before being resumbitted as a SQL command. Note that if the table has many rows (over several hundred thousand), it could take a while for DBCC CHECKIDENT to complete.

4GB Virtual Address Space Under WoW64

admin — Tue, 11 Aug 2009 23:07:28 +0000

In Windows x86 your 32-bit application can only address 2GB of virtual address space. The other 2GB has been reserved for kernel operations. Under Windows x64, with the 32-bit application running under WoW64, you can give the access to the full 4GB virtual address space by changing a flag in the PE header. This is accomplished by using the EDITBIN.EXE utility which comes with Visual Studio.

editbin /LARGEADDRESSAWARE xxx.exe

Why not just simply compile and link xxx.exe as a native 64-bit application and get much more than 4GB? Well, the application may be using libraries and components which are only available as 32-bit binaries. In this case, building a 64-bit app is not an option. Also, if you have been following Rico Mariani’s (of Visual Studio fame) blog, you would know that there are some disadvantages of running native 64-bit applications vs. 32-bit applications under WoW64 – the main thing being that all address pointers would be twice the size, meaning a larger memory footprint and slower memory access.

You can use the DUMPBIN.EXE utility (also part of Visual Studio tools), to find out the setting of the /LARGEADDRESSAWARE flag in the header.

dumpbin /HEADERS xxx.exe

In the output of DUMPBIN look out for Application can handle large (>2GB) addresses. This means that your 32-bit app will be able to address the full 4GB address space when running under Windows x64. Note that when running the app in 32-bit Windows configured with the /3GB option, the app will be able to address 3GB.

Script to Re-index SQL Server Database

admin — Sun, 09 Aug 2009 22:31:16 +0000

The following SQL Server script enumerates the tables in a database and calls DBBC REINDEX on each one (with a fill factor of 80%). It then calls sp_updatestats too update the index statistics.

USE 
DECLARE @TableName varchar(255) 
DECLARE TableCursor CURSOR FOR

SELECT table_name FROM information_schema.tables

WHERE table_type = ‘base table’ 
OPEN TableCursor 
FETCH NEXT FROM TableCursor INTO @TableName

WHILE @@FETCH_STATUS = 0

BEGIN

Print @TableName

DBCC DBREINDEX(@TableName,’ ‘,80)

FETCH NEXT FROM TableCursor INTO @TableName

END 
CLOSE TableCursor 
EXEC sp_updatestats

To avoid your queries from running under non-optimal execution plans, the script should be run periodically, typically weekly or nightly, when the the database is not in use.

Replicating large text / ntext fields in SQL Server 2005, 2008

admin — Sun, 09 Aug 2009 15:24:40 +0000

Scenario – You have successfully setup replicated SQL Server databases with ntext fields and things were going fine initially. One day you get this error in the Event Log:

Server: Msg 7139, Level 16, State 1, Line 1
Length of text, ntext, or image data ([some number larger than 65536]) to be replicated exceeds configured maximum 65536.
The statement has been terminated.

This is happeming because Max Text Replication Size by default is set to 65536 and SQL Server has attempted to replicate a row where the data in a column is greater than this size. From the SQL Server Management Studio you can view and change this setting under Server Properties | Advanced dialog.

Increase this number to a higher value – up to 2147483647. Make this change on all SQL Servers involved in the replication. If you don’t like UI stuff, you can also make this change via a SQL Query.

EXEC sp_configure ‘max text repl size’, 2147483647

GO
RECONFIGURE

GO 

Disabling SSL 2.0 on IIS 6

admin — Fri, 07 Aug 2009 22:25:03 +0000

If you run a secure site on IIS 6, note that the legacy SSL 2.0 protocol is enabled by default. SSL 2.0 has been superseded by SSL 3.0 and you’d want to disable it for the following reasons.

The Downgrade Attack: SSL v2 has no notion of integrity checking for handshake packets. Thus, an attacker could change the algorithms and key lengths chosen by the client while the appropriate handshake message was on the wire. This can result in a weak SSL connection being setup between the client and the server even though this is not what the two intended. Armed with this weak connection, the attacker could log all the traffic going by during the data exchange and could then use a brute force application to attack the weak encryption.

The Truncation Attack: SSL v2 does not allow the parties involved to distinguish when the connection is ended by one of them or by a malicious third party. Thus an attacker can freely interrupt secure client-server connections. If the attacker additionally understands the application, the semantics and ordering of messages being exchanged, then he/she can potentially alter the meaning of a message by interrupting the connection at precisely the correct instant.

Instructions for disabling SSL 2.0

Open the registry editor and navigate to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ SecurityProviders\SCHANNEL\Protocols\SSL 2.0
Under the Client key set Enabled DWORD value to 0×0
Under the Server key set Enabled DWORD value to 0×0

If you hire someone to run a penetration test on your server/web site, this is one of the things they look out for. Eliminating it right from the start would prevent this blemish on your pen test report.

References
http://support.microsoft.com/?kbid=245030

Windows Server 2003 Automatic Logon On Startup

admin — Fri, 07 Aug 2009 00:24:09 +0000

After system startup, there is sometimes a need to have Windows Server login automatically as a particular user. The following changes to the registry accomplishes this.

Using RegEdit, open the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Set the account name in the DefaultUserName entry. If DefaultUserName does not exist, create a new entry as a string value (REG_SZ).
Set the password in the DefaultPassword entry. If DefaultPassword does not exist, create a new entry as a string value (REG_SZ).
Set the AutoAdminLogon entry to 1. If AutoAdminLogon does not exist, create a new entry as a string value (REG_SZ).

Click on the picture for larger image.

The next time the computer restarts it will automatically login as the specified user.