Fixing block corruptions within a Database is always a messy thing. Not because it is not do-able, but it always means some service disruptions combined with a recovery activity of parts of your database.

Regardless you have to analyse and fix the real issue e.q. a dying controller or harddisk, or perhaps a messy memory modul first, in some cases you can speed up time for fixing the issue by just reading out your corrupted table and recreating it.

Connect as a SYSDBA user you can mark the table as needing to skip corrupt blocks with the following command:

This will tell the Oracle Kernel to just read over all corrupted blocks and go on with serving your query until the end.

After you have issued the command about you should be able to issue a CREATE TABLE AS SELECT operation against the corrupt table to extract data from all non-corrupt blocks and/or EXPORT the remaining healty content of the table.

But be aware about you will for sure loose data, which is stored within those corrupt blocks!!!

Once you salvaged the date you should now drop the corrupt table and recreate it from scratch. If for any reason you should wish to keep the damaged table though, you can clear the attribute for a table with this command:

But you will end up with some no longer query able table again!!!

To get a feeling about how much data and blocks you have lost, you can have a look into your trace files. Whenever a session skips a corrupt block due to SKIP_CORRUPT being set then a message is written to the trace file (not the alert log) for each block skipped in the form like this:

Sooner or later it will come to a situation in which we have to transfer data between different database. Given the fact we have to do a normal database upgrade Oracle Export/Import will help us to do as long we will go with a full database export and all users, priviledges, permissions and quota will get transfered.

Now given the case that we based on schedules or migration plans just have to overtake single schemas world does look different. Oracle Import will expect theuser schema already exisiting and even try to create all database objects in relation to their old location within the former database.

Now I’m not going to explain you how to change tablespace or storage information within this posting … perhaps in another one … but will try to help you with pre-setting up the schema and additional security information before importing the data.

As for we work with some database system all data can for sure get queried and even stored within directly executable sql statement. Since years I’m working with an easy to use set of scripts collecting these information for me.

Feel free to download it from here and using it for your own pleasure.  When unpacked you can call the script 0_capture_security_information.sql within SQLPLUS and you will get generated another result set of scripts containing all users, roles and granted system and role priviledges stored with the database you are connected too.

Connecting now to the new target database and executing the scripts full or in parts will allow you to set up security there again.

As for todays hosting is mainly done on UNIX systems transfering websites can be done quick and reliable using UNIX commands. And therefore a changing your Hosting Provider can become fairly easy.

Instead of downloading all content from Server A to your local system using a however clever FTP Client and later uploading it again to Server B, this whole file transfer can be done within one step using a server to server copying command.

As a basic requirement to use this feature, you have to have secure shell access onto both servers. Being logged in to one server (it doesn’t matter which one) you can use SCP command to transfer all your files. The syntax of the command is fairly easy and it is part of the command to specify source and target system and therefore is doesn’t matter if you are pulling or pushing the files.

Easy command line examples for an SCP command would be:

Copying file to host:

scp SourceFile user@host:directory/TargetFile

Copying file from host:

scp user@host:directory/SourceFile TargetFile

Using the -R option as well will allow you to transfer whole directory trees within one single copy command.

While transfering all files and perhaps several domain can take up several days depending on the size and complexity of your hosting, it can occur that parts of the original files are already changed again until the final go life.

To prevent differences in between source and new target system a final update of both system shortly before switching over does make sense. Here now the command RSYNC will help us.

With RSYNC you can syncronize files and folders between systems.

Again an easy command line example would be:

rsync -r user@host:directory/SourceFolder TargetFolder

Also here source and target system needs to be specified and therefore both sending and receiving are possible.