1. In an Azure Web Role, references are added to 3 assemblies. Diagnostics which contains all the logging and diagnostics classes, ServiceRunTime which allows access to the configuration settings and recycling of roles etc, and StorageClient which is a .NET library wrapped around a REST interface for Blob, Table, Queue and Drive storage.

   

2. There is a WebRole.cs or WebRole.vb file added to an Azure WebRole project, this file just adds some boiler-plate template code for basic Azure tasks such as setting up diagnostics and logging.

   

3. In the Web.Config file a trace listener is added to enable logging and debugging.

   

You can , however, download and install a local development environment for developing and testing Azure apps locally.

The closest to an inbuilt backup functions is support for the TSQL Database Copy command which produces a transactionally complete copy of a database.

Coming in 2010, Azure will deliver two backup methods – Clone and Continuous Backup. Clone (targeted for release in H1 2010) allows for a transactionally consistent ‘clone’ to be made of a database, once a clone is created it is a totally separate database with no relations to the ‘parent’ database. Continuous Backup (targeted for release in H2 2010) is similar to a mirror and is configured with a retention period and a lag time. Continuous Backup copies will be read-only. These will be be add-ons to the standard SQL Azure service and will incur an additional fee which was has not yet been announced.

• BCP using the .exe bulk load/export tool.
• SSIS
• Bulk API’s in ADO.NET and ODBC (see below).
• Third Party Tools
• Sync Framework

BCP

BCP is probably the fastest way to move the data. BCP is a command line tool introduced with SQL Server 2005 SP1 which allows for copying data in and out of SQL Server. The tool uses standard TSQL Syntax conventions.
// BCP example

SET SRV=aserver.database.windows.net

SET LOGIN=judo@someserver

SET PW=something

SET S_DR=C:flats

bcp TPCH2.dbo.supplier in %S_DR%supplier.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.nation in %S_DR%nation.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.region in %S_DR%region.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.customer in %S_DR%customer.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.part in %S_DR%part.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|“

bcp TPCH2.dbo.supplier out %S_DR%supplier.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.nation out %S_DR%nation.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.region out %S_DR%region.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.customer out %S_DR%customer.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

bcp TPCH2.dbo.part out %S_DR%part.tbl -c -U %LOGIN% -P %PW% -S %SRV% -t “|”

ADO.NET Bulk Copy API:

// Bulk data import

using (SqlBulkCopy bulk = new SqlBulkCopy(new SqlConnection(conn))

{

DestinationTableName = “dbo.data”,

BatchSize = 2000, // Transaction size (length)

BulkCopyTimeout = 10000, // Transaction timeout

NotifyAfter = 1000, // Progress callback

})

{

bulk.SqlRowsCopied += new SqlRowsCopiedEventHandler(

myProgressCallback);

bulk.WriteToServer(sourceDataReader);

}

Third Party Tools

Currently the primary third party tool for migration is the SQL Azure Migration Wizard

In addition there is inbuilt DOS protection, if there are many failed attempts to access a SQL Azure database the requesting IP is disallowed for a period of time. Thus if you make several incorrect login attempts you may be locked out for a short period.

As at launch (January 2010) SQL Azure will disconnect any idle sessions after 5 minutes, it will also kill any long running transactions which last over 5 minutes (Microsoft has pledged to adapt this restriction in future and attempt to distinguish between genuine long running transactions and transactions which are not operating correctly). SQL Azure will implement resource throttling if a process generates excessive CPU or I/O load. The exact throttle thresholds are not disclosed.

There is a subtle difference in connecting compared with SQL Server. When connecting to SQL Server you are first connected to the server and through the server to the database, in Azure you are directly connected to the database. This means that there is no support for context switching using the USE keyword (in SQL Server this allowed the Server to direct a request to a database determined at run-time).