20. Nov. 2008

As a Web Developer we sooner or later maybe required to work with a CMS (Content Management System), perhaps out of own interest or plainly being forced by a customer request.

The idea behind such tools is the try to separate the data from the presentation layer. Following this approach later on it will be easy to change the look and feel of your site just by changing or updating the template used, immediately all content pages will get shown in that brand new look without changing them one by one.

Setting up such a CMS is fairly easy, first by uploading all files that come with it to your server. We now need to put together your database details as they are the key to your central data store and specifying them together with a few other essential (but usually not difficult to answer) questions during a typical setup procedure. From then on it is just learning about and working with the tool ñspecify what tool, is it CMS(?) – to get your site ready to use.

Your site, usually developed on your own server, or within a subfolder of the original environment sooner or later you may find the need to move your installation.

In all cases the principle process is the same. Following the idea of a CMS, data can be either located within the file system, the database, or within both. So moving a CMS always requires moving both!

We have already given you a few tips here about how to move the files between servers quickly and therefore we will now focus on the database data only.

The main benefit of a database is that the data is stored within, in a very efficient way for accessing it quickly and in a structured way. Most databases come with some binary data export/import tools for transferring both data and structures.

Making a WordPress move and the usual MySQL database, phpMyAdmin is the tool of our choice. Mostly offered by the hosting provider itself it is often part of your hosting package and easy to access.

Once started it offers you a nice and neat surface interface enabling you to work with your database and it hopefully will not take you long to get familiar with it. With the main view opened and looking at your database the menu directly offers you the options export and import. Now choosing export we usually can go on with the offered defaults. But to prevent problems I would recommend you to ensure that the check boxes “Add DROP TABLE” and “Complete inserts” are checked and “Export type” is defined as “INSERT”.

With this set we can now press “Go” and the result will be a long and curious screen output containing both, the data and all necessary SQL (Structured Query Language) elements, later on it is necessary to re-import this data.

This output we will now cut & paste to an ASCII Editor of our choice and the reason for this is there maybe references pointing to structures of the old server we now have to change (now hopefully making them “relative”). Within the editor this can be done easily by using the usual search and replace function.

Importing the data back into the database or transferring it to another one, we now copy & paste our content back into phpMyAdmin and connect to the new target database. For the re-import I recommend the SQL functionality of the tool. There you can just paste your script into the big SQL input field and finally press the OK button below. And after a few seconds of processing, a friendly message will tell us that our data is stored back within the database.

Having ported both – data and files – we finally need to change a few runtime settings of the WordPress installation.

Once again you should be aware that we are working with two different locations; database and filesystem and you will understand tweaks will be required to both.

All the necessary information to access the database is stored within a file wp-config.php. We should remember that file as it was part of the initial installation we did earlier.

Now we open this configuration file within an editor of our choice and replace the relevant parts e.q. username, password, database, server and table prefix with the correct new values.

Finally and as a last step we have to head back to the phpMyAdmin and navigate down to a table called  wp_options. Browsing the content of this table we will see two option rows siteurl (option_id=1) and home (option_id=39) which contains the old site URL as an argument. Adjusting them with the new site URL will finally allow us to run the WordPress on our new Server without issues.

11. Nov. 2008

Messing up some setting with the system SPFILE can end us up with a database which does no longer start up. Unfortunately this can happens delayed as for it is possible to set new vales without making them active immediately.

Now a system SPFILE is no real editable file and therefore fixing it becomes difficult:

A typically problem which can occur leaving your database inoperable is specifying LOG_ARCHIVE_DEST within a Oracle Database Version 10g as for syntax has change in this version and it is easily done following good “old” behavior.

You will end up with an database complaining about:

SQL> startup mount force
ORA-16019: cannot use LOG_ARCHIVE_DEST_1 with LOG_ARCHIVE_DEST or LOG_ARCHIVE_DUPLEX_DEST

Fixing this we have to startup the database with an alternative INIT.ORA file which we usually have from the database creation process. Don’t worry about it is recent or not as for our aim is just to get up the database up and running in mount status:
(if not at hand create an INIT.ORA file from scratch using an universal example)

SQL> startup mount pfile=’C:\oracle10g\admin\SID\pfile\init.ora’;
ORACLE instance started.

Total System Global Area 135339844 bytes
Fixed Size                  454468 bytes
Variable Size            109051904 bytes
Database Buffers          25165824 bytes
Redo Buffers                667648 bytes
ORA-00205: error in identifying controlfile, check alert log for more info

Having the database up now again, we can create an editable INIT.ORA by reading the values within system SPFILE:

SQL> create pfile=’c:\temp\init.ora’ from spfile=’c:\oracle10g\database\spfileSID.ora’;
File created.

Now with the new editable INIT.ORA file containing all the actual configuration settings of our database (even the wrong one) we can go on fixing our issue and finally convert the INIT.ORA file again back into a system SPFILE:

SQL> create spfile=’c:\oracle92\database\spfileSID.ora’ from pfile=’c:\temp\init.ora’;
File created.

When we now shutdown the database and reopen it again it will start and open gain using the fixed SPFILE as before:

SQL> startup force
ORACLE instance started.

Total System Global Area 139534168 bytes
Fixed Size                  454488 bytes
Variable Size             113246208 bytes

…..

11. Nov. 2008

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:

execute DBMS_REPAIR.SKIP_CORRUPT_BLOCKS(‘schema’,’tablename’);

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.

CREATE TABLE salvage_table AS SELECT * FROM corrupt_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:

execute DBMS_REPAIR.SKIP_CORRUPT_BLOCKS(‘schema’,’tablename’, flags=>dbms_repair.noskip_flag);

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:

table scan: segment: file# 6 block# 11
skipping corrupt block file# 6 block# 12

« previousnext »