dbalifeeasy

SQL Server Migration Assistant (SSMA) Tables Partially Migrated and High Memory Usage

PROBLEM

While we migrate a relatively big size database from Oracle to Microsoft SQL Server, all the small tables are migrated successfully without any issues. But the following issues occur from big tables migration.

“SSMAforOracle.exe” process consumes high memory, so the server got 99% memory utilization consistently.
For big tables with more than 10 million records, they are always partially migrated.
After big tables migration failure, we can see sometime the follow message in the migration log.

^{“Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding.”}

DataMigration Error. 
From : "SCHEMANAME"."TABLENAME"
To : [DBNAME].[SCHEMANAME].[TABLENAME] Execution Timeout [Error: Datamigrator] [9812/41] [2020-11-01 21:21:34]: Exception: Execution Timeout Expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.

It is not really a timeout issue. Even after increasing the “Data Migration Timeout” from default 5 mins to maximum 1440 mins( 24 hrs), the migration of big tables still fails.

SOLUTION

Subscribe to get access

Read more of this content when you subscribe today.

How to Change the Owner of Database in SQL SERVER

Check database owner by the below sql query:

select name, SUSER_SNAME(owner_sid) OWNER from sys.databases;

To change the owner of a database, the following either way should do the job.

On SQL Server Management Studio -> Right Click on Database -> Properties-> Files ->click Owner..

2. Change owner of a database by sql.

ALTER AUTHORIZATION ON DATABASE::TESTDB TO "VIRTUALLAB\Administrator";

If you meet the following error messages.

Msg 15110, Level 16, State 1, Line 48
The proposed new database owner is already a user or aliased in the database.

Then drop the user first, and re-run the above one.

USE "TESTDADB";
GO
drop user "VIRTUALLAB\Administrator";

ALTER AUTHORIZATION ON DATABASE::TESTDB TO "VIRTUALLAB\Administrator";

SQL Server Database in “Recovery Pending“ Status

Due to temporary disk availability issue, SQL Server database is in “Recovery Pending“ Status.

Let’s step by step repair the database by the following guidelines:

Make sure disks are available and with enough space for databases.
Make a backup of datafiles and logfiles. In case repairing failure, so the alternative repairing methods can be used later against database restoration from this backup.
Manually set database online.

Run CheckDB.

You can run CHECKDB with option ‘NO_INFOMSGS’ to eliminate the informational messages.

DBCC CHECKDB ('TestDatabase') WITH NO_INFOMSGS;

In this case, CheckDB has completed without warning, so the database is healthy. Otherwise continue to repair the database.

• Set to single user mode for databases to be repaired.

ALTER DATABASE TestDatabase SET SINGLE_USER;

• Start to repair the database.

First try “REPAIR_REBUILD” option.

DBCC CHECKDB('TestDatabase',REPAIR_REBUILD)

The repaired database can be se to multiple user mode now, if it is successful.
Otherwise continue to repair with level ‘REPAIR_ALLOW_DATA_LOSS’.

DBCC CHECKDB(‘TestDatabase’,REPAIR_ALLOW_DATA_LOSS);

Please note the option name explains the potential data loss could happen.

If the repairing is successful, the database can be set back to multiple user status to open to users.

If the repairing is still a failure, then continue to next step for repairing with ‘EMERGENCY’ mode.

ALTER DATABASE TestDatabase SET EMERGENCY;
ALTER DATABASE TestDatabase SET SINGLE_USER;
DBCC CHECKDB ('TestDatabase',REPAIR_ALLOW_DATA_LOSS) WITH  NO_INFOMSGS,ALL_ERRORMSGS;

Finally set database to ‘online’ and multiple user mode.

ALTER DATABASE TestDatabase SET ONLINE;
ALTER DATABASE TestDatabase SET MULTI_USER;

Let’s check database online and normal now.

DataPump: UDE-00008 ORA-31626 ORA-39086

The following errors occur when exporting data by using DataPump:

UDE-00008: operation generated ORACLE error 31626
ORA-31626: job does not exist
ORA-39086: cannot retrieve job information
ORA-06512: at "SYS.DBMS_DATAPUMP", line 2772
ORA-06512: at "SYS.DBMS_DATAPUMP", line 3886
ORA-06512: at line 1

Check the log which shows exporting has been successful.

...
..
.
Master table "SYS"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded
Dump file set for SYS.SYS_EXPORT_SCHEMA_01 is:
C:\TEMP\TEST.DMP
Job "SYS"."SYS_EXPORT_SCHEMA_01" successfully completed at 12:08:38

So it is a bug, and this error can be ignored.

How to Check and Fix Dead Tuples Not Removed By Vacuum From PostgreSQL Tables

Why Vacuum ?

In PostgreSQL, when rows are updated or deleted from a table, dead rows are created and left behind, vacuum daemon processes will clean those dead tuples ( rows) periodically based on parameter setting for vacuum process. Generally the following four reasons explain why vacuum is needed:

To recover or reuse disk space occupied by updated or deleted rows.
To update data statistics used by the PostgreSQL query planner.
To update the visibility map, which speeds up index-only scans.
To protect against loss of very old data due to transaction ID wraparound or multixact ID wraparound.

Tables’ Dead Tuples Not Removed

The following query result shows the dead tuples are not removed by auto vacuuming for some reasons. But they should have been removed from tables.

 schemaname  |          relname          | n_live_tup | n_dead_tup |    overthread    |              now              |        last_autovacuum        | autovacuum_count
------------+---------------------------+------------+------------+------------------+-------------------------------+-------------------------------+------------------
 pg_catalog | pg_statistic              |       3298 |      48500 |  127.69878883623 | 2020-10-10 03:35:43.573615+00 | 2020-10-10 03:34:11.607386+00 |          1797116
 pg_catalog | pg_attribute              |       1116 |       6643 | 41.1076732673267 | 2020-10-10 03:35:43.573615+00 | 2020-10-10 03:34:28.653988+00 |          1589637
 cdrdb      | users                     |      27316 |      87554 | 31.4761288467069 | 2020-10-10 03:35:43.573615+00 | 2020-10-10 03:35:35.891844+00 |          1717941
 cdrdb      | products                  |        645 |       1689 | 14.7510917030568 | 2020-10-10 03:35:43.573615+00 | 2020-10-10 03:35:32.192822+00 |          1596895
 cdrdb      | price                     |     154492 |     168499 |  10.871464333643 | 2020-10-10 03:35:43.573615+00 | 2020-10-10 03:35:05.049206+00 |          1655072
 cdrdb      | contract_pdf              |     157701 |     165106 | 10.4364700602398 | 2020-10-10 03:35:43.573615+00 | 2020-10-10 03:35:27.945506+00 |          1656837
...
..
.
(27 rows)

Subscribe to get access

Read more of this content when you subscribe today.