PikoSystem IT engineering services
فا Emergency Talk to an engineer
Emergency

Urgent database and server troubleshooting (MySQL, SQL Server, Linux, Windows)

MySQL won't start after a power cut, SQL Server refuses connections, or the disk filled up and applications are stopping one after another. In a situation like this, protecting the data comes first: we copy the database files and logs, then start troubleshooting. Once the service is back, we can recommend database optimization so the same failure does not return.

0900-000-0000 Send an urgent request
Tools & technology database-os-troubleshooting
  • MySQL
  • MariaDB
  • SQL Server
  • PostgreSQL
  • Percona Toolkit
  • SQL Server Management Studio
  • systemd
  • Event Viewer
  • Ubuntu
  • Windows Server
5work areas
4deliverables
4steps

What is Database and OS Troubleshooting?

Database optimization and urgent MySQL and SQL Server fixes are services that get a failed, slow or locked database and its Linux or Windows server working again, with the data protected first. They are for situations such as MySQL refusing to start after a power cut, accounting software that cannot connect to SQL Server, or a full server disk. PikoSystem copies the data directory, MDF and LDF or ibdata files and error logs before any repair, troubleshoots InnoDB errors and databases stuck in Suspect or Recovery Pending, examines long-running queries, deadlocks, missing indexes and settings like innodb_buffer_pool_size, and safely frees space taken by binary logs or transaction logs. You end up with the service back in working order, a report on the cause, a list of config changes with old and new values, and optimization recommendations.

When you need Database and OS Troubleshooting

  • MySQL won't start after a server reboot and the log shows InnoDB errors.
  • Our accounting software says it can't connect to SQL Server.
  • The server disk is full and I don't know what is safe to delete.
  • Every few hours the server kills processes because it runs out of memory.

What Database and OS Troubleshooting includes

01

Protect the data first

We copy the database data directory, MDF and LDF or ibdata files, and the error logs. On a database that may be damaged, we never run a repair command without a copy.

02

Startup failures and crashes

We troubleshoot InnoDB errors, crashed MyISAM tables, SQL Server databases stuck in Suspect or Recovery Pending, and breakage after updates.

03

Slowdowns and locking

We look at long-running queries, deadlocks, missing indexes and settings such as innodb_buffer_pool_size or max server memory.

04

Full disks

We find what is eating space, such as binary logs, transaction logs, logs that never rotate and temp files, and free it up safely.

05

Operating system problems

We deal with memory exhaustion and the OOM killer, boot errors, failed systemd services and Event Viewer errors on Windows Server.

What you get from Database and OS Troubleshooting

  • The database or server back in working order
  • A report on the cause and the actions taken
  • A list of config changes with old and new values
  • Recommendations for optimization and preventing a repeat

Database and OS Troubleshooting: a practical guide

MySQL optimization: which settings actually matter?

After innodb_buffer_pool_size, max_connections is the most common mistake. Each connection takes its own buffers such as sort_buffer_size and join_buffer_size, so a high limit combined with large buffers runs the server out of RAM at peak time and the OOM killer stops MySQL. Redo log size, set with innodb_redo_log_capacity on newer versions, directly affects write speed.

Avoid copying my.cnf files from old tutorials. The query cache was removed in MySQL 8.0, and a leftover query_cache_size line stops the service from starting at all. Change one setting at a time and measure the effect with pt-query-digest and the slow query log.

Speed up SQL Server: defaults worth changing

The default max server memory is effectively unlimited, so SQL Server takes as much RAM as it can. On a server that runs other services, the operating system is starved and everything slows down. Cost threshold for parallelism defaults to 5, which is low for most modern workloads and sends small queries parallel for no benefit.

Auto Shrink, or a scheduled shrink job, is another frequent find. It shrinks files, fragments indexes and forces the database to grow again. Stale statistics and missing index maintenance are common causes of gradual slowdowns too.

System or MySQL crash: which log to check

On Linux, journalctl -b -1 shows the previous boot and is the first place to look after a sudden restart. Out of memory: Killed process in dmesg output means the kernel ended a process for lack of RAM. The MySQL error log usually lives in /var/log/mysql or /var/lib/mysql.

On Windows Server, Kernel-Power event 41 and event 6008 record an unexpected shutdown, and event 1001 shows that a blue screen occurred and a minidump was written. SQL Server keeps its own ERRORLOG file in the Log folder of its installation.

When do you need high availability for SQL Server or MySQL?

When a few hours of database downtime halts sales or production, restoring from backup is no longer enough on its own. SQL Server offers Always On Availability Groups, Failover Cluster Instances and log shipping, and Standard edition supports only Basic Availability Groups with one database each. MySQL and MariaDB setups typically use replication or Galera Cluster.

High availability does not replace backups. A DROP statement or an accidental delete reaches every replica within seconds.

How Database and OS Troubleshooting works

  1. 01

    Call and describe the error

    Tell us the error message, when the problem started and what changed recently. Send screenshots or logs if you have them.

  2. 02

    Access and copies

    We connect over secure remote access and copy the data and logs before changing anything.

  3. 03

    Diagnose and fix

    We find and fix the cause. Any step that could lose data happens only with your approval.

  4. 04

    Test and report

    We test application connections and data integrity with you, then hand over the report.

Database and OS Troubleshooting: frequently asked questions

How is emergency troubleshooting different from database optimization?

Emergency troubleshooting means getting the service back during the crisis. Database optimization is planned work that covers query analysis, indexing and tuning the configuration for your real workload. After fixing an outage, we usually recommend optimization so the crisis does not come back.

Our MySQL database crashed. Is the data gone?

A MySQL crash does not necessarily mean lost data. InnoDB often comes back through its own crash recovery or with innodb_force_recovery. The wrong move at this stage, such as deleting ib_logfile files, can make the damage serious, so avoid restarting the service over and over until we look at it.

Can you help without remote access?

Most database and operating system problems need secure remote access. If company policy blocks access from outside, we work through a screen-sharing session with your colleague or arrange an on-site visit.

Related searches

  • slow database
  • MySQL optimization
  • speed up SQL Server
  • database error fix
  • server disk full
  • MySQL crash
  • high memory usage on server
  • database support

Related services

Urgent

Report an urgent problem

For a full outage, a phone call is the fastest route. If you can't call, fill in the form and we'll call you.

Call now 0900-000-0000
  1. 01We call you and get the details.
  2. 02Contain the damage and preserve logs before changing anything.
  3. 03Fix the issue, then report the cause and what was done.

Your details are only used to answer this request.