Sqlite dump outputting tables out of order - postgresql

I'm trying to convert a Sqlite3 database to Postgres by dumping it to raw SQL, editing the SQL and then loading it via psql, summarized by this script.
The overall approach seems fine, except for one problem. When I try to run the final load with psql, I get errors like "table x does not exist", because Sqlite is outputting tables referred to by foreign keys after the tables that refer to them. This causes psql to abort all further statements with the message:
ERROR: current transaction is aborted, commands ignored until end of transaction block
The only immediately solution I see is to manually go through all the SQL and try to manually reorder the CREATE TABLE commands so that the proper order is maintained. However, this is very tedious.
Is there any way to force Sqlite to output SQL so that tables are output in order of dependency?

Related

Is there a way for a PostgresQL procedure to somehow print out its table context for test purpose?

I am a new man for PostgresQL; working in DBEaver. I have created a procedure that modifies, among others, a temp table. I would like to print out the table for testing purposes: to see what is in the table now.
In T-SQL I could just execute “select * from MyTestTable”; and this was output to SQL Studio Grid tab. This did not break the procedure.
Now on Postgres I am using DBeaver and get errors when I try to use the same approach.
A question to experienced PostgresQL: how you cope with that? Is there any way to “peek my nose” into middle of a proc and see – what data are at given moment in table. If no - how to debug large and complicated procedures without ability to look at produced data Grid?

Postgresql Corrupted pg_catalog table

I've been running a postgres database on an external hard drive and it appears it got corrupted after reconnecting it to a sleeping laptop that THOUGHT the server was still running. After running a bunch of reindex commands to fix some other errors I'm now getting the below error.
ERROR: missing chunk number 0 for toast value 12942 in pg_toast_2618
An example of a command that returns this error is:
select table_name, view_definition from INFORMATION_SCHEMA.views;
I've run the command "select 2618::regclass;" that gives you the problem table. However reindexing this doesn't seem to solve the problem. I see a lot of suggestions out there about finding the corrupted row and deleting it. However, the table that appears to have corruption in my instance is pg_rewrite and it appears to NOT be a corrupted row but a corrupted COLUMN.
I've run the following commands, but they aren't fixing the problem.
REINDEX table pg_toast.pg_toast_$$$$;
REINDEX table pg_catalog.pg_rewrite;
VACUUM ANALYZE pg_rewrite; -- just returns succeeded.
I can run the following SQL statement and it will return data.
SELECT oid, rulename, ev_class, ev_type, ev_enabled, is_instead, ev_qual FROM pg_rewrite;
However, if I add the ev_action column to the above query it throws a similar error of:
ERROR: missing chunk number 0 for toast value 11598 in pg_toast_2618
This error appears to affect all schema related queries to things like INFORMATION_SCHEMA tables. Luckily it seems as though all of my tables and data in my tables are fine but I cannot query the sql that generates those tables and any views I have created seem inaccessible (although I've noticed I can create new views).
I'm not familiar enough with Postgresql to know exactly what pg_rewrite is, but I'm guessing I can't just truncate the data in the table or set ev_action = null.
I'm not sure what to do next with the information I've gathered so far.
(At least) your pg_rewrite catalog has data corruption. This table contains the definition of all views, including system views that are necessary for the system to work.
The best thing to do is to restore a backup.
You won't be able to get the database back to work, the best you can do is to salvage as much of the data as you can.
Try a pg_dump. I don't know off-hand if that needs any views, but if it works, that is good. You will have to explicitly exclude all views from the dump, else it will most likely fail.
If that doesn't work, try to use COPY for each table to get at least the data out. The metadata will be more difficult.
If this is an important database, hire an expert.

REORG command in db2

So I have been altering a table in QMF. After 3 alters I believe the table has gone into a pending reorg state so that I cannot alter it additionally. Am I correct in this assumption? If so what implications does this have and to get around it can I simply reorganize the table and continue altering it? If so, what does the syntax look like for reorganizing a table? I tried
REORG TABLE PIDJBIP.TABLE_NAME_T
and receive the error:
an unexpected token "PIDJBIP" was found following "REORG TABLE".
Expected tokens may include: "JOIN". SQL state = 42601.
I haven't gotten much help out of the IBM pages regarding this subject.
REORG is not an SQL statement, so it cannot be issued using a SQL interface (such as QMF). You will need to run it using the DB2 Command Line Processor.
Alternatively, you might use the administrative stored procedure, which you could call via QMF:
call sysproc.admin_cmd('reorg table PIDJBIP.TABLE_NAME_T')

How to View Execution Plan for Query Containing a Temp Table in Toad for SQL Server?

I am trying to tune the performance of a stored procedure that contains a temp table in Toad for SQL Server. After selecting "Include Actual Execution Plan" from the 'Editor' menu, I run the query. The Results Set returns values as expected, however, the Execution Plan tab shows the following error:
Invalid object name '#temp'.
I have tried creating the temp tables first then just executing the SELECT statement that references it, I tried creating the temp tables as global temp tables and running the SELECT statement in another window, and I have messed with the SHOWPLAN_TEXT and STATISTICS PROFILE (as mentioned in this question) but I keep receiving the same error. The only thing I have not tried is using a table variable, but the changes I will be making cannot be done on table variables, so this is not really an option for me at this time.
Has anyone else come across this or have any ideas as to what I might be doing wrong?
You'll want to use the ISQL command line utility on a machine that has SQL Server client package installed. Or any other utility that can submit a query to SQL Server.
ISQL Docs and How to get an execution plan (2nd part of the post)

DB2 SQL Error: SQLCODE=-911, SQLSTATE=40001, SQLERRMC=68

I am getting this error when I ran:
alter table tablename add column columnname varchar(1) default 'N';
DB2 SQL Error: SQLCODE=-911, SQLSTATE=40001, SQLERRMC=68
How to solve it?
The alter statement wants to get an X lock on this row in SYSIBM.SYSTABLES. There is an open transaction that has this row/index value in an incompatible lock state. This lock that caused the timeout could even be from an open cursor that reads this row with an RS or RR isolation level.
Terminate any other SQL currently trying to query SYSTABLES and any utilities that may be trying to update SYSTABLES like reorg and runstats then try the alter again.
See DB2 Info center (I picked the one for DB2 10, most likely this error code is the same in other versions, but doublecheck!).
Seems there is a transaction open on your table, that prevents your alter command from execution.
after you have Altered a table you need to Reorg: reade up on it here:
Run the runstats script, which is a DB2 script, at regular intervals and set the script to gather RUNSTATS WITH DISTRIBUTION AND DETAILED INDEXES ALL.
In addition to running the runstats scripts regularly, you can perform the following tasks to avoid the problem:
Use REOPT ONCE or REOPT ALWAYS with the command-line interface (CLI ) packages to change the query optimization behavior.
In the DB2 database, change the table to make it volatile. Volatile tables indicate to the DB2 optimizer that the table cardinality can change significantly at run time (from empty to large and vice versa). Therefore, DB2 uses an index to access a table rather than a table scan.