Queensland time, properly accounted for

SQL Server DBA services in Brisbane

Queensland does not observe daylight saving, so for about five months a year Brisbane runs an hour behind the southern states — which quietly moves every change window, batch overlap and SLA clock. Remote SQL Server DBA cover that is scheduled in your time, from $1,500 a month.

Free 20-point health check Call 1800 431 416

Queensland stays on AEST all year. From the first Sunday in October to the first Sunday in April, Sydney and Melbourne move to AEDT and Brisbane does not — so for roughly five months a year a Brisbane organisation is an hour behind the southern states, and every schedule agreed in "10pm" has to be asked about.

That is not a trivia point. Overnight maintenance windows, cross-state batch dependencies, replication to a southern DR site, SLA clocks, and the hand-off between a Brisbane operations team finishing at 5pm AEST and a provider still at their desk until 6pm AEDT — all of it shifts twice a year. In our experience it is the single most common source of a missed change window for Queensland estates, and it is entirely avoidable by writing the timezone next to the time.

How we handle it

Scheduling that accounts for Queensland time

None of this is clever. It is just done deliberately, because the alternative is an annual round of windows that drift by an hour.

Every change window, maintenance schedule and report time is written with its timezone attached, never as a bare clock time
Schedules are reviewed at both daylight saving transitions rather than left to drift — the October change is the one that catches Queensland estates
Where a Brisbane database replicates to or from a southern site, the overlap between the two maintenance windows is worked out explicitly rather than assumed
SLA response times are measured in elapsed time, so the clock is unaffected by which state is on which offset
For estates spanning Queensland and the southern states, we document which system runs on which offset — frequently the first time that has been written down

What we get called about in Queensland

The problems that come with distributed operations

Queensland estates are more geographically spread than most, and that shapes the database problems that reach us.

Databases at regional sites

Mine sites, ports, processing plants, regional offices and council depots running local instances over connectivity that was never designed for a database. Backups that technically run but could not be restored across that link in any useful time.

Operations that genuinely do not stop

Resources, logistics and utilities estates where there is no quiet period to schedule into. The work becomes finding a window that exists rather than negotiating the one you want.

A DR site in another state

Replication to Sydney or Melbourne, often configured once and never tested, and often with the two sites on different daylight saving offsets for half the year.

Queensland government information security

Queensland government agencies work to the state Information Security Policy, which — like the ACSC Essential Eight — expects vendor-supported, patched software. An out-of-support SQL Server version is the control that quietly fails.

One administrator, many systems

The common Queensland pattern outside the CBD: a capable generalist running an estate well until something needs a database specialist, with no escalation path when it does.

Weather as a continuity event

Queensland is the state most likely to need its continuity plan for reasons unrelated to IT. A recovery that has been tested is worth considerably more there than one that has been documented.

Being straight about this

We are not based in Brisbane

Onsys is a Melbourne practice. We support Queensland organisations remotely, and we schedule in your time rather than ours.

Our office is at Level 1, 530 Little Collins Street, Melbourne VIC 3000, and our DBAs are in Australia
Database support is remote, which is how specialist database work is delivered everywhere — the alternative is an in-house DBA, not a local one
On-site attendance is available in the Melbourne metropolitan area as part of an engagement; elsewhere it is arranged and quoted case by case
What you get instead of proximity is a guaranteed response time, a named consultant who knows your estate, and published prices
If physical attendance matters more to you than any of that, we will say so rather than talk you out of it

Start with one Brisbane instance

The free 20-point health check is read-only, needs no access to your environment, and comes back as a written report within 3 business days. If the estate is healthy, we will tell you that.

Book the free health check

Published 9 October 2026

FAQ

Common questions

No. Onsys is a Melbourne practice and our DBAs are in Australia. Queensland clients are supported remotely, with change windows and reporting scheduled in AEST year-round and a guaranteed response time at any hour. On-site attendance outside the Melbourne metropolitan area is arranged and quoted case by case.

It causes scheduling problems rather than technical ones, and they are avoidable. We write the timezone next to every scheduled time, review schedules at both transitions, and work out the overlap explicitly where a Queensland database replicates to a southern site. SLA response times are measured as elapsed time, so the clock itself is unaffected.

Yes, and it is worth looking at specifically. The usual finding is not that monitoring cannot reach the site, but that the backup strategy cannot — a backup that exists on the local server and could not be pulled across the link in any useful time is a backup that will not help you. We size the recovery approach against the connectivity you actually have rather than the one the design assumed.

We support public sector organisations across Australia, including councils and agencies. Queensland government agencies work to the state Information Security Policy, which expects vendor-supported and patched software — so the first useful output is usually a written inventory of every instance with its version and patch level, which is exactly what the free health check produces.

Plan A is $1,500 per month excluding GST for up to 10 SQL Server instances — $150 per instance — with a guaranteed two-hour response at any hour and 10 professional service hours a month. Plan B is $3,000 and Plan C is $7,500 for larger and mixed-platform estates. Every figure is published on the pricing page.