I'm simply doing a select * from one of my tables. It is a daily table containing yesterday's data and was working fine yesterday and earlier today. It is suddenly returning "Error: Unexpected. Please try again."
Are there any production issues currently? The job id for one of these failed queries is job_Tj_vZhAqfZH9jpW52M8IUld4XKE
A configuration change this morning caused a problem querying from tables that had been written to via streaming. The issue should be fixed now. Please ping this thread if you continue to see problems.
Related
We have created datashare (environments) in redshift where we are binding 1 table from environment A named tableA to environment B named tableB .
We access both tables from environment A. We were able to access these both tables for few weeks but from yesterday we are getting following error which does not have any info available on web.
SQL Error [58030]: ERROR: Query aborted due to read failure on a perm block. Hint: Please try again.
We can access tableB from environmentB (datashare) but only getting this when we try to access tableB from environment A (datashare A). Dropping bidning and recreating these tables and again linking these 2 tables solves the issue for some time where we can access the tables from both datashares. But error again comes back after some time. Does anyone know why this issue is arising?`
We recreated the tables and binding between these 2 tables in redshift, it worked for some time, but issue repeats
we had the same problem recently. In our case, restoring the datashare did not solve the problem. Instead, recreating the referenced table solved the problem.
I am facing an issue with the Bigquery update job which was executing fine till a few days back and started failing all of suddenly due to the backend error
Error:-'backendError', And it is suggesting to retry would solve the problem but it is not the case.
Can someone help on this, I am trying to update the partition table from a nonpartitioned table based on non-part fields.
I've had this query in BigQuery that I have been updating every day for the last few months. It's been fine - some occasional errors, but retrying has solved the problem.
Bet last few days I am getting the error: The job encountered an error during execution. Retrying the job may solve the problem.
The error description says that it's an external error, so how can I fix that?
I have been retrying (with rather long pauses in between), but I still get the error.
JobID example: bquxjob_152ced5d_169917f0145
Does anyone have any idea what's going on? Is there any data/time limitations I might encounter (but why just the last few days then)?
You can use CGP stackdriver to monitor your BigQuery process using this URL
Interesting information you can find among others are the queryTime heatmap and the Slot usage which might help you understand your problems better
On the subject of the external table usage, you can use Google transfer (See this link for details) to schedule a repeated transfer from CSV to BigQuery table.
The below Image show you how to get to the transfer set up page from the webUI
I encountered this dreadfully useless error in a scheduled query. It was working great and then one day it stopped working at all and has been failing ever since without any other explanation. The StackDriver (now "Logs Explorer") showed nothing more enlightening:
jobStatus: {
errorResult: {
code: 14
message: "Error encountered during execution. Retrying may solve the problem."
}
errors: [
0: {
code: 14
message: "Error encountered during execution. Retrying may solve the problem."
}
]
jobState: "DONE"
}
Figuring out the actual issue takes a long time because scheduled queries start slowly since they use BATCH priority. What I found in my case was that the partitioned table and "Partition field" setting in the scheduled query was the culprit. I dropped the table and removed the partition field and voila the thing works again (although far from ideal since I need partitioning).
I hope this helps someone else running up against that useless error but in any case, I hope the good folks working on BigQuery find a better error to bubble up.
I ran into this problem when replacing the contents of a partitioned table. Two retries did not help. When I removed the --range_partitioning from the command the update was processed correctly. The table remained partitioned.
So there seems to be an issue about updates to partitioned tables, and when that is the cause these errors might not benefit from retry. I don't know whether there are other causes of this error.
This kind of issue probably has a lot to do with BigQuery quota errors : https://cloud.google.com/bigquery/docs/troubleshoot-quotas#ts-number-column-partition-quota, as mentionned by other answers, such as the 4000 partitions-by-table quota.
I am unable to execute a simple select query (select * from [<DatasetName>.<TableName>] LIMIT 1000) with Google BigQuery. It is giving me below error:
Query Failed
Error: Unexpected. Please try again.
Job ID: job_51MSM2uo1vE5QomZA8Sv_RUE7M8
The table contains around 10 records. I am able to execute queries on other tables.
Job Id is - job_51MSM2uo1vE5QomZA8Sv_RUE7M8.
It looks like there was a temporary issue where we were seeing timeouts when querying tables that had been inserted to recently via streaming insert (tabledata.insertall()). We're currently addressing the underlying issue, but it should be working now. Please ping this thread if you see it again.
Since yesterday, 1-09-2012, I can't run any queries over a table that has been created from the result of another query.
example query:
SELECT region FROM [project.table] LIMIT 1000
result:
Query Failed
Error: Field 'region' is incompatible with the table schema.
49077933619
These kinds of queries passed successfully every day, last couple of weeks. Has anybody else encountered a similar problem?
We added some additional schema checking on friday. I was unable to reproduce the problem but I'll look into your examples (I was able to find your failed job in the logs). I'm in the process of turning off the additional schema checking in the meantime. Please try again and let us know if the problem continues.