I don't have any experience in SQL databases.
I want to use Microsoft SQL server and i need to ask two questions:
I want to know what are the disadvantage and advantage of saving the data in the mdf file.
Is there some easy way to 'copy' the data that i saved in the mdf file to the regular table ?
1) Question doesn't make sense: All data is stored in .mdf or .ndf data files (in reality the extension doesn't matter, it's just a convention)
2) You seem to be mixing the concept of a table and a data file. Backups are used to create safe copies of your data. The tables you see in SSMS are stored in data files (via filegroups).
If you don't know anything about SQL Server, you should start by finding a good book (and go to a good training course) to understand the basic concepts. The documentation is very extensive, but it's really a reference and not a learning tool.
Having said that, have you read the documentation on files and filegroups in SQL Server? All data in SQL Server is stored in .mdf (and possibly .ndf) files. Unless you're using SQL Server Compact, I believe.
And what are "regular tables"? Are you perhaps using Access as a front-end to SQL Server?
Related
I have .mdf files that are backups of several databases, and I would like to know if it is possible to attach these files at once.
If it is also possible, for example via PHP code, I also feel free to explore.
So I am aware that typically an SDF file would be thought to be a SQL Server Compact Database file. However it is highly unlikely that is the case here.
I have a client that is trying to pull their data out of a legacy system. I've been given access to the data files and some go back as far as 1998. According to this:
http://fileinfo.com/extension/sdf
these files are likely Standard Data Files. This makes sense based on the naming of the files as well. Each file name appears to be what I would normally consider a table name. My understanding is that a SQL Server Compact Database would have all of these tables in a single file.
So the question now is what system can read these SDF files. What late 90s database programs would use SDF files? I've tried Googling this and it doesn't look like there is much on the topic.
What kind of database the Sql Server Migration Assistant uses as an internal data repository and stores it in the source-metabase.mb file?
I guess that this it is one of standard tool that I could use to open and edit some entries (I need to autamatically add some custom scripts for tables with BLOBs data migration )
You could also just suggest the way how to check most popular database formats: SqlServer Compact, MySQL, Access..
it is one of standard tool that I could use to open and edit some entries
I would not count on it :) It was a proprietary metadata format that has nothing to do with DB products that SSMA supports. It can store metadata for representing Oracle and also SQL Server among others, obviously formats are not connected with file structure that actual DBs use. SSMA format has no open docs, also it may fail to synchronize your changes after manual intervention if you reverse engineer it (due to the fact it was designed just as the migration tool to target SQL Server and was supposed to mostly create new objects there based on source database counterparts).
Can you just write some stored procedures or triggers in your database? For most DBs metadata is exposed as special tables/views anyway. Probably you need to do it only for SQL Server as it's your target db after migration, right? Looking into ways to directly parse or manipulate files managed by "big" DB (like SQL Server or Oracle) doesn't seem to be a good idea for most scenarios. (except digital forensics, for example)
SQL Server metadata related views are here and functions are here. You may profile your SQL Server instance while connecting to it with SSMA just to get some feel what it does to extract metadata (object names, columns of tables, source of SPs etc.)
Data manipulation is pretty much clear from the DB side if you need it too.
Generally to get the meta data from SQL Server backup files, we need to use TSQL commands like restore headeronly or restore filelistonly. However, there are some third party tools can read this information directly from the backup files, like this one http://www.yohz.com/sqlbakreader_details.htm. Since this tool don't have a command line version, which makes it less useful. I want to know whether there are some ways that I can read this data directly.
Thanks.
The .bak file is a Microsoft Tape Format file. Here's a PDF that contains the format.
Of interest to you will be:
For a quick dump (if you are on the SQL Server in question that created the backup), you can do select from the [msdb].[dbo].[backup*] tables.
See this article for more info.
I think you may be able to use SQL Servers SMO libraries and write your own in .net or Powershell. If you take a look at this page http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.management.smo.restore.readbackupheader.aspx there are code samples in VB.Net and Powershell.
I'm used to working with SQL Server and when I want to copy a DB there, I just need a handful of clicks in the wizard and voila...a complete copy of the DB, without taking the source DB offline.
We now also have an Oracle 11g because some machines require it, and I want to make a copy of the database. Just a copy on the same server, to use as a test DB for my software development.
All instructions that I find are pages full of steps, using RMAN or not, you have to write scripts, use command line stuff...I'm amazed at how inefficient such a common task is when using Oracle.
Aren't there any easy ways of copying a DB? Maybe just exporting everything to a SQL file, then editing it to use another DB name, and then executing it again?
I see that in SQL Developer you can choose 'Database Copy...' from the Tools menu, but it asks a destination connection. How can I select a destination when creating the destination DB is the whole point of running the wizard? Or is a connection not the same as a DB?
Thanks for helping me out here!
You're generally going to need a new database to copy the data to, and the data could be copied with datapump export/import. There aren't many ways of getting around that I'm afraid, but one option that you might consider is to make more use of VM's such as Oracle's own VirtualBox, as they can be cloned very easily with an absolute certainty of byte-by-byte fidelity.
Incidentally, one problem in making logical copies (via export/import) of a database is that it's easy to end up with a different physical pattern to the table and indexes, which can lead to unexpected differences in query optimisation.