3

We have a strange issue which has appeared in the last couple of days.

We have two Amazon Redshift clusters. One cluster has our production workload, and the other cluster has our non-production workload. There are 4 copies of the same database. 1 production copy, and 3 copies in non-production.

In the last few days, data extracts began failing in our non-production environment. Upon further investigation, we see that the error is:

ERROR: schema "dbo" does not exist

So, upon closer inspection. Sure enough, the query is using dbo as the schema and there is no dbo schema in the database. All of the tables exist in the public schema. This would make sense if this didn't work for months prior to this event, and is actually still working in production.

The original (simplified) query looks like this:

select top 1 * from [dbo].[my_table];

In this case, dbo does not exist in any environment. my_table exists in the public schema. However, the above query works fine still on our production cluster, while it now fails, with the invalid schema error on our non-production cluster.

I also tried changing the query to:

select top 1 * from "dbo"."my_table";

I get the same results. Works fine in production. Does not work in non-production. In fact, if I try select top 1 * from "public"."my_table"; I get the same results (as dbo) in production, and the query works as expected in non-production. And, if I try select top 1 * from "asdf"."my_table" it fails universally.

I also checked the Redshift user's search path, in case that had something to do with it. In each environment the search patch is default: $user,public

I confirmed on all the databases that the dbo schema does NOT exist, and that all the tables are in public. I also checked the cluster version and update history. I identified that the non-production cluster is running version 1.0.44126, and the production cluster is running version 1.0.43931. The extracts did start failing after this update. I cannot find any reference to version 1.0.44126 online and have no idea what has changed here. (C'mon AWS, update your documentation!)

I can't find any reference to Redshift translating dbo to public or any other related feature that might do that.

I am able to reproduce the issue by issuing the following two statements:

create table public.test_table ( test integer );

select * from dbo.test_table;

I can also do: drop table dbo.test_table;

It will work fine on my 1.0.43931 cluster, and fail on the 1.0.44126 cluster. Clearly there is a mechanism here which is treating these two schemas names the same.

Why does the query select top 1 * from "dbo"."my_table"; work at all when the actual table is "public"."my_table"?

Why did it stop working all the sudden in version 1.0.44126 (if that is the case)?

5
  • 1
    "dbo" is the default schema for SQL Server. Is any jiggery-pokery going on in moving data out of a SQL Server database (still in use, or maybe stopped in the distant past)? What does version control tell you? (cough) Commented Nov 28, 2022 at 20:38
  • @MikeSherrill'CatRecall' You are correct. And we did consider this. And yes, the data being populated in to redshift is part of an ETL process from SQL server databases. And the redshift database used to run on SQL server, that is why we errantly had references to "dbo" in our code. However, this doesn't seem to be related to anything here. The only change I know happened that I have identified is a new version of Redshift. The non working cluster is 1.0.44126 and the one that is working is 1.0.43931. I did identify that the problem did occur after this update (I previously missed this). Commented Nov 29, 2022 at 18:14
  • @MikeSherrill'CatRecall' I cannot find any reference to version 1.0.44126 online yet. Commented Nov 29, 2022 at 18:14
  • @MikeSherrill'CatRecall' I revised the post with this new information, and also showed that I can easily reproduce this behavior by creating a table in the public schema and querying it in the dbo schema. Commented Nov 29, 2022 at 18:42
  • 1
    No version control then? You can't track who and when wrote these queries that use a schema that never existed in your database? Commented Nov 30, 2022 at 17:09

1 Answer 1

0

I have seen the exact same situation. The thing I can't determine is how these "dbo.XXX" queries ever worked before as there has never been a dbo schema. An ugly (but effective) quick solution was to create a dbo schema and create views for each table in public, effectively acting as aliases.

1
  • 2
    but how and why these queries were ever written in the first place? Surely you have a version control where you can track who wrote them. Commented Nov 30, 2022 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.