The Oracle Media Server

This product is the center of what Oracle offers. It provides the ability to store media objects, such as video or sound, and to organize them in a database structure. The Oracle Media Server is just a database server with the special function of handling media objects instead of simple character and numeric data.

Oracle has renamed many of its traditional database structures so the components of the video server are full of completely different names. But the components of the media server are only a special case of the components of a traditional RDBMS. Look at the different components of the video server and their functions:

•  Media Data Store. The Media Data Store (MDS) is simply a set of files on a file system that store multi-media data and can deliver this data real-time according to the specifications of the application. The MDS is really only a glorified tablespace for media data.
Although this object is like a tablespace, the MDS is far more sophisticated when it comes to sizing estimates. You are dealing with huge amounts of media data where a change in time for the presentation could dramatically increase disk size. For instance, at a 1.2 MPS playback rate, a minute of video data will only need 72MB, while an hour of video will obviously need 72×60, or 4,320MB.
When creating the MDS, you can also set bandwidth parameters, which determine how wide you will need your bandwidth to be. This parameter is a function of megabytes-per-second multiplied by the number of concurrent users.
The Media Data Store (MDS) comes with a series of low-level utilities that help assist the Video Database Administrator (VDBA) to manage and manipulate the files of the MDS. Here are a few of the utilities that the MDS provides:

• mdschecksum	This is a simple utility used to make sure video data is not corrupted over time. When new video data is registered in the MDS, a checksum can be run to generate a unique number for that data. If you run the mdschecksum on this same file a month later and the number is different, you have a problem. This is a very important tool for video storage because the volume and the interdependence of the data is usually more emphasized than in a traditional database.
• mdsconcat	This low-level function is more like an editing tool. Just like the strcat function in the C language, mdsconcat concatenates two video files together. This is helpful if you are presenting media as a series of shorter video clips in a given sequence.
	Many times you might be given 100 video files that you need to place in a certain sequence. This function will concatenate these 100 files into one file that is in the correct order. This function thus helps to make the media creation environment easier to manage.
• mdscopy	This is a very valuable function that I wish were available with a traditional relational database. It allows the user to move or copy MDS files to another MDS volume or to a directory on the Media Server. The MDS counterpart in the RDBMS is the tablespace, and to move a tablespace is a much more complicated effort than one straightforward command like this.
• mdscreate	This is similar to the create tablespace command in that it creates a file in a specified MDS volume. This file can now be used to store video data. One note of caution though: This utility simple allocates space for the file on disk, and does not wipe out any old data; therefore don’t assume your old data is destroyed if you run an mdscreate on the same data volume.
• mdsdelete	Again, this would be similar to a drop tablespace command. This command simply removes a file or files from an MDS volume.
• mdsdir	This command is simply used to list file information and general information regarding an MDS volume.
• mdsdiskmode	This allows the user to place a disk in rebuild mode if there is ever a need to rebuild an MDS volume.
• mdsdump	This low-level function is probably the last thing you want to use; it dumps a file in an MDS volume into hexadecimal data. It really is designed for only low-level debugging of bad MDS files.
• mdslock	This is an important utility that locks a file in an MDS volume for read-only activity. This comes in handy if you have just spent 3 days working on a media file and don’t want anyone else to change it. With the lock on, any number of users can still read the file and enjoy the video output.
• mdsrebuild	This command rebuilds MDS data on a disk after a disk failure. Be advised to consult the latest Oracle documentation before using this function and to have a failure strategy in place. This command currently works only with RAID storage because RAID gives Oracle potential copies of the same data.
• mdsrename	This command allows you to rename a file on an MDS volume.
• mdstar	This command allows you to perform backups from an MDS volume to tape or from tape to an MDS volume.
• mdstruncate	Use this command to truncate an existing file in an MDS volume; many files fill up with useless space and this is a good way to reclaim the space.
• mdsundelete	This command will allow you to “undelete” a file removed using the mdsdelete function.
• mdsunlock	This command will unlock a file put in read-only mode in an MDS volume.
• mdsvolinit	This command is crucial. Once you have defined your data storage for MDS volumes using the voltab file, you need to run this command to actually create the definition of the MDS volume to each of the volume’s disks.
• mdsvstat	This is a primitive monitoring and administration tool that gives you information on an MDS volume and general statistics.

•  The Video Pump. The video pump reads in information from the Media Data Store, which is like a tablespace and stores data. The pump is simply the process to read in this information. Unlike the Oracle read process, video must run in real time, so the pump is more sophisticated in that it allows users to control parameters such as the maximum data transmission rates, the number of packets sent at a time, and even memory settings for internal buffers.
Also, unlike the Oracle kernel that handles reads without as much direct control from the user, the video pump can be started and stopped separately from the database. To start your own video pump called mypump, the command is

svcstart mypump

•  The Voltab File. This file is similar to the traditional Oracle control files; it is in the voltab file that the user defines the disk space needed for the Media Data Store. This file is also much more complex because you are dealing with media objects, other parameters such as the parity, transfer rates, and the RAID specification for the disks your Media Data Store will be sitting atop.
The Media Data Store (MDS) is created when you create a voltab file. Unlike a control file, you need to manually create this file. In some respects it is similar to an init.ora file, yet it holds much of the disk information for the disk space needed by the MDS.
Figure 32.4 shows a typical media server and its Data Store.

Figure 32.4.  Oracle has re-designed its RDBMS components for media.