Developer ToolsFree generatorPDF, Excel, Word exportDiscrete Manufacturing

OEE SQL Query Generator

Most plants have stops in one table and counts in another. This generator builds a clean SQL query that joins them and returns availability, performance, quality and OEE per line per day.

Fill in

Generated code
Download:

OEE by line and day (generic ANSI style SQL)

WITH counts AS (
  SELECT line_id AS line_id,
         production_date AS d,
         SUM(total_count) AS total_count,
         SUM(good_count) AS good_count
  FROM production_counts
  GROUP BY line_id, production_date
),
stops AS (
  SELECT line_id AS line_id,
         stop_date AS d,
         SUM(stop_minutes) AS stop_minutes
  FROM stop_events
  GROUP BY line_id, stop_date
)
SELECT c.line_id,
       c.d,
       (450 - COALESCE(s.stop_minutes, 0)) / 450.0 AS availability,
       CASE WHEN (450 - COALESCE(s.stop_minutes, 0)) > 0
            THEN (0.5 * c.total_count) / (450 - COALESCE(s.stop_minutes, 0))
            ELSE 0 END AS performance,
       CASE WHEN c.total_count > 0
            THEN c.good_count * 1.0 / c.total_count
            ELSE 0 END AS quality,
       (c.good_count * 0.5) / 450.0 AS oee
FROM counts c
LEFT JOIN stops s ON s.line_id = c.line_id AND s.d = c.d
ORDER BY c.d, c.line_id;

Check query: rows where OEE exceeds 100 percent

-- Wrap the query above as a view named v_oee_daily, then:
SELECT *
FROM v_oee_daily
WHERE oee > 1.0
   OR performance > 1.0
   OR quality > 1.0;

Table and column names are placeholders for your own schema. The query assumes one planned time and one ideal cycle time for all lines; join a routing or standards table if yours vary by product. Test on a sample day against a manual calculation, and adjust the cast syntax for your database version.

Have your OEE query reviewed

Optional review of your schema and the OEE logic against your own data.

Optional. The tool and every export work without this. No spam.

How to use it

Enter the names of your count table, stop table and columns, then set the planned minutes and ideal cycle time. Copy the output into your SQL client, run it on one day and compare with a hand calculation. Wrap it as a view once it matches, and point your BI tool at the view.

  • Check that each stop belongs to only one line and date
  • Make sure stop minutes are within planned time
  • Use a standards table for varying cycle times

The method behind the query

Availability is run time over planned time. Performance is ideal cycle time times total count, divided by run time. Quality is good over total. OEE equals good count times ideal cycle time, divided by planned time, which is the same as the product of the three factors. The query uses both forms so you can cross check.

Reading the output

Each row is one line on one day. If availability is low, look at the stop reasons. If performance is low, check the ideal cycle time first, then small stops. If quality is low, review scrap and rework. A value over 1.0 means a data problem, which the check query finds.

Common mistakes

Common faults are stops that cross midnight and land on the wrong date, a single ideal cycle time applied to products with different speeds, and joining before aggregating, which multiplies counts. This query aggregates first for that reason.

Frequently Asked Questions

Which databases does this work with?

The query uses common table expressions, SUM, CASE and COALESCE, which work in SQL Server, PostgreSQL, Oracle and MySQL 8 and later. You may need to adjust the numeric casts, for example the decimal literal trick, for your version.

What if stops cross midnight?

Split those events at midnight or use shift dates rather than calendar dates. Otherwise the downtime falls on the wrong day and availability looks wrong for two days in a row.

How do I handle different products on one line?

Store the ideal cycle time by product, join it to the counts and sum ideal cycle time times count per product. Then use that sum in place of the single cycle time multiplication.

Can I use this on ERP tables directly?

You can if the ERP stores machine states and counts at the right detail, which many do not. Often a MES or historian holds the stops. Use this query where the data lives and avoid writing to the ERP.

If your counts and stops sit across an ERP and a shop floor system, we can help build the pipeline and a trusted OEE view.