SQL Policy

These are the policy guidelines for the use of SQL LITE, STANDARD SQL, PREMIER SQL, VIRTUAL DEDICATED SQL (VDQ) and MySQL Services.

Customers who purchase a MySQL, SQL Lite, Standard SQL, Premier SQL or VDQ Service must adhere to the following policy guidelines. WebCentral takes no responsibility for any problems caused by failure to observe these policy guidelines.

1. General Terms and User Policies Applying to Shared SQL Services (SQL Lite, Standard SQL, Premier SQL and MySQL)

1.1 SQL Replication is not supported.

1.2 WebCentral will only supply a hosting environment, not a testing environment. Customers hosting SQL databases should run the database in a similar environment in their premises and test offline.

1.3 Customers with workloads that detrimentally impact other customers on the SQL server will have their databases moved to a tuning server environment. WebCentral will give prior notice of the move if practicable. The customer will have two weeks to tune their SQL workload on the tuning server. The customer's database will be moved back to the SQL environment only after the workload has been tuned to WebCentral's satisfaction. Failure to comply with the request to tune the SQL workload is regarded as a material breach of WebCentral's terms of supply and the service may be suspended or terminated in accordance with the WebCentral's Standard Terms and Conditions (6. Suspension and Termination of Service).

1.4 Applying to SQL Lite, Standard SQL and Premier SQL only: Full-text search support is provided for character-based data on SQL servers. The Full-Text Search facilities can be used to create special indexes of all pertinent words in selected columns of selected tables. Administration of full-text indexes can be managed either through SQL Server Enterprise Manager (for SQL 2000 databases), SQL Server Management Studio (for SQL 2005 databases) or Full-Text system stored procedures. The space taken up by the Full-Text Search indexes is included in the space quota for your site.

1.5 Applying to customers utilising an SQL 2005 database only with the Standard SQL Add-On or Premier SQL Add-On: If using the SQL CLR feature, only SAFE MODE assemblies are allowed.

2. General Terms and User Policies Applying to Virtual Dedicated SQL Services (VDQ)

2.1 The VDQ server environment permits a SQL workload limit of 60 SQL statements per second. Customers who exceed the SQL workload limit for their SQL instance will be advised to tune their application and reduce the SQL workload below the above specified limit. The requested tuning must be actioned within two working days of being advised by WebCentral. See clause 2.2 for workloads that detrimentally impact other customers on the VDQ server.

2.2 Customers with SQL workloads that detrimentally impact other customers on the VDQ server will have their databases moved to a SQL tuning server environment. WebCentral will give prior notice of the move if practicable. The customer will then be given two weeks to tune their SQL workload on the SQL tuning server. Once the offending SQL workload has been tuned to WebCentral’s satisfaction the databases will be moved back to the VDQ environment. Failure to comply with the request to tune the SQL workload is regarded as a material breach of WebCentral’s terms of supply and the service may be suspended or terminated in accordance with the WebCentral’s Standard Terms and Conditions (6. Suspension and Termination of Service).

2.3 WebCentral will only supply a hosting environment, not a testing environment. Customers hosting SQL databases should run the database in a similar environment in their premises and test off line.

2.4 Full-text search support is provided for character-based data on VDQ servers. The full-text search facilities can be used to create special indexes of all pertinent words in selected columns of selected tables. Administration of full-text indexes can be managed either through SQL Server Enterprise Manager (for SQL 2000 databases), SQL Server Management Studio (for SQL 2005 databases),or Full-Text system stored procedures. The space taken up by the full-text search indexes is included in the space quota for your site.

2.5 SQL Replication publishing and distribution is permitted using VDQ, however, the customer’s replication SQL workload and application SQL workload combined must not exceed the SQL workload limit stated in clause 2.1.

2.6. The VDQ server environment permits a maximum of 10 Gigabyte of space for database and transaction log allocations per SQL Instance. Customers who exceed the 10 Gigabyte space limit will be advised to purge data. Failure to comply with the request to reduce database/transaction log space usage is regarded as a material breach of WebCentral’s terms of supply and the service may be suspended or terminated in accordance with the WebCentral’s Standard Terms and Conditions (6. Suspension and Termination of Service).

2.7 Applying to customers utilising an SQL 2005 database only with their VDQ service: If using the SQL CLR feature, only SAFE MODE assemblies are allowed.

3. Additional Terms and User Policies Applying to MySQL

3.1 The 2MB MySQL Intro database is only available the first time you sign up for the MySQL Add-On.

3.2 Each account (VS Number) is only entitled to ONE 2MB MySQL Intro database.

3.3 Two (2) database users are provided with each database for application and administrative use. An additional 8 (to bring the number of users to a maximum of 10) per database will be permitted.

3.4 A web-based interface for the MySQL databases will be provided, at no extra charge and maintained by the technical departments, as a means of managing the database.

3.5 Connections from external networks and use of client software packages other than those provided by the hosting platform are not supported for security and interoperability reasons.

3.6 InnoDB/Berkeley DB table types are not supported in the current shared product.

4. Additional Terms and User Policies Applying to Premier SQL and VDQ

4.1 Premier SQL and VDQ customers will design their Web-SQL applications to use the SAME user connection. Opening individual user session connections to the database is undesirable and not recommended.

4.2 At least one member of the development team responsible for development of the SQL database possesses at least two years experience in SQL Server development and/or has a Microsoft certification (MCSD or MCDBA).

4.3 The customer's SQL development team follows a formal testing process that tests all application components prior to deploying to the SQL server.

5. How to Upgrade Your SQL 7.0 Database

5.1 Existing SQL 7.0 customers requesting an upgrade to SQL 2000 or SQL 2005, must host on either the Professional or Premier shared hosting plans and enable either the Standard SQL Add-On or Premier SQL Add-On respectively.

5.2 If WebCentral has agreed to upgrade existing SQL 7.0 customers, the customer will have the choice of having a new database created on the either the SQL 2000 or SQL 2005 server.

5.3 The set-up and monthly subscription charges set out in the Standard SQL Add-On and Premier SQL Add-On product features will apply to upgrades.

5.4 It is the customer's responsibility to upload its data to the new SQL 2000 or SQL 2005 database provided.

6. Best Practice Guidelines for All SQL Users (includes Shared SQL Services and VDQ)

These development best practices guidelines may also be viewed at http://admin-au.server-secure.com/bestpractices/sql/.

6.1 Normalise the database design to 3rd Normal Form and use controlled redundancy as a last resort.

6.2 Do not use or design an application that allows users to fill in edit boxes that generate a long-running query. For example, do not use or design an application that prompts the user for inputs but rather allows certain fields to be left blank or a wildcard to be entered. This may cause the application to submit a query with an excessive running time, thereby causing a blocking problem.

6.3 Do not use or design an application that allows user input within a transaction.

6.4 Allow for query cancellation.

6.5 Use a query or lock time out to prevent a runaway query and avoid distributed deadlocks.

6.6 Immediately fetch all result rows to completion.

6.7 Keep transactions as short as possible and avoid nesting transactions.

6.8 Explicitly control connection management.

6.9 Use Stored procedures where possible. When calling a stored procedure avoid returning single row result sets, instead use stored procedure output parameters. Insert error handling after each insert, delete and update SQL statement to ensure stored procedure robustness.

6.10 If returning large result sets to the client, develop a method of returning only the number of rows that can fit in the screen at the one time. See article on "Just-In-Time Record Set Creation".

6.11 When returning result sets, ensure the SQL statement is as selective as possible to minimise the number of rows retrieved, retrieve only the columns required and minimise network round trips.

6.12 Construct SQL Query statements using efficient techniques.

6.13 Use selective WHERE clause with a supporting index, avoid negative equality clauses and minimise OR logic, use IF EXISTS instead of Select Count(*), use EXISTS instead of IN, avoid large sorts by minimising use of DISTINCT, ORDER BY, GROUP BY and by matching search arguments and ORDER BY clause with a supporting index, minimise the number tables in a join (rule of thumb is <= 4 tables).

6.14 Test SQL statements prior to implementation. Check for an efficient execution plan, resource usage (CPU, IO, Memory, Worktable space).

6.15 Avoid using large Server Side cursors.

6.16 Stress test the application at the full projected concurrent user load.