C17.3. Database capabilities. Database size, throughput, scalability, procedures for object creation, editing, and deletion, change notifications, registrar transfer procedures, grace period implementation, reporting capabilities, etc.

The registry database will be implemented using Oracle 9.2 Enterprise Edition software.

Oracle is the most powerful database technology available and can be scaled to perform in excess of 400,000 transactions per minute. (http://Oracle.com/features/9i/benchmarks/index.html?0523_db_tpcc.html)

Database Size

The database servers require 120GB of disk space for the Oracle database. 100GB of this space will be allocated to the Oracle data files, 10GB will be allocated for database logs and trace files, and 10GB of space will be provided archived redo log files. These size estimates will allow sufficient capacity for the first four years, at which point an updated capacity plan will be produced.

Approximately 1.5GB of new data will be added to the database every day. The majority of this information will be EPP transaction logs that do not need to be maintained online for more than a few days. The anticipated net growth of the database after archiving is expected to be 20GB per annum.

Database Throughput

The specified database configuration will support a continuous workload of at least 100 WHOIS queries, 400 RRP transactions and 200 EPP transactions per second.

AusRegistry’s existing system running on commodity Intel hardware can serve 100 WHOIS queries and 45 EPP transactions per second, and we estimate that this system could serve approximately 80 RRP transactions per second.

AusRegistry conservatively estimates that database performance on the SUN FireBlade hardware will increase by a factor of five, allowing the database to serve 500 WHOIS queries, 450 RRP transactions and 225 EPP transactions per second.

Database throughput will be actively managed using a combination of mechanisms.

At all times when both primary and standby sites are operational, EPP/RRP will access the primary database and WHOIS will access the standby database. This segmentation of registry applications will allow full utilization of all available database resources and protect the WHOIS service from interference by heavy EPP/RRP load. Some additional load will be incurred by the inter-database replication but impact will be not be significant as WHOIS is read-only and 75% of RRP transactions are check commands.
Oracle’s Resource Manager will be configured to guarantee more processing resources to connections from the Grade 1 server than connections from the Grade 2 and Grade 3 servers. Similarly, the WHOIS, EPP and RRP database users will each be guaranteed a minimum CPU allocation, preventing one application from inappropriately consuming all available resources.
Network rate limiting will be used to prevent registrars from performing too many transactions in a given timeframe.

Scalability

Oracle has been the market leader in database software for many years and it is recognized as the premier mid-range database technology. Thousands of companies choose Oracle for its enviable reputation as the most reliable and most scalable product available.

The proposed database implementation has been designed in accordance with Oracle’s recommendations for high scalability and performance. If the peak system load increases faster than anticipated, additional CPUs can be installed into the server to provide extra processing power.

Procedures for object creation, editing, and deletion

RRP and EPP objects can only be manipulated via the relevant application servers.

Registry operations staff will have read-only access to all registry objects via an internal management system.

Direct access to the underlying data is restricted to AusRegistry’s Database Administrator and Chief Information Officer.

The RPP and EPP servers will provide support for arbitrary deletion delays, during which time the object will be marked deleted but can not be created by another registrar.

AusRegistry will comply with any policies or rulings determined by ICANN in relation to object management.

Change Notifications

No changes to registry data will be made by made to registry objects without direction from ICANN or by prior written approval from the appropriate sponsoring registrar.

Changes in system architecture may be necessary from time to time, as determined by policy changes, updated application specifications, or desired system enhancement.

AusRegistry will comply with all ICANN guidelines in relation to change notifications.

Registrar Transfer procedures

The process for transferring objects between registrars will be executed as per the RRP and EPP specifications, and subject to all ICANN policies in relation to transfers.

Registrars will be able to perform transfer operations using the standard RRP and EPP transfer commands. The transfer operation will be completed as soon as the transfer is approved.

Customisations to the standard transfer protocols can be implemented if required.

Grace period implementation

Unity Registry will follow the Grace Period policy as specified. (http://www.icann.org/tlds/agreements/VeriSign/registry-agmt-appc-16apr01.htm#3)

This functionality will be built into the database and executed automatically as part of the mentioned transactions.

Unity Registry will comply with any amendments to this policy as agreed with ICANN.

Reporting capabilities

A Registry Operator’s Monthly Report following the format specified in Revised VeriSign .net and .org Registry Agreements: Appendix Twill be implemented and made available to ICANN via a secure reporting website within the first 5 working day of the new month.

All report dates and times will all be calculated in UTC.

New reports will be implemented as requested by ICANN subject to the terms of the Registry Agreement.