I'm running a test using HSQLDB and I want to be able making select queries on database while this test to see what is changing. I suppose transaction or something else is blocking the database while test and I'm not able to make queries ...
Is it possible to configure hsql server in that way to be able to do these queries?
This answer is valid if you are starting a HyperSQL Server and connecting with the jdbc:hsqldb:hsql:xxxx connection URL.
The default transaction isolation model is LOCKS. In this model, the tables are locked when their rows are modified during a transaction. You need to use the MVCC model for the database to allow other connections to access the table.
However, when you modify the rows, these changes are only visible to the transaction that makes the change until it commits the data and the changes become visible to other connections.
Related
I heard that SQL Server SELECT statements causing blocking.
So I have MVC application with EF and SQL Server 2008 and it shares DB with another application which is very frequently writes some data. And MVC application generates some real-time reports based that data which comes from another application.
So given that scenario is it possible that while generating a report it will block some tables where another application will try to write data?
I tried to make some manual inserts and updates while report is generated and it handled fine. Am I misunderstood something?
This is one of the reasons why in Entity Framework 6 for Sql Server a default in database creation has changed:
EF is now aligned with a “best practice” for SQL Server databases, which is to configure the database’s READ_COMMITTED_SNAPSHOT setting to ON. This means that, by default, the database will create a snapshot of itself every time a change is made. Queries will be performed on the snapshot while updates are performed on the actual database.
So with databases created by EF 5 and lower, READ_COMMITTED_SNAPSHOT is OFF which means that
the Database Engine uses shared locks to prevent other transactions from modifying rows while the current transaction is running a read operation.
Of course you can always change the setting yourself:
ALTER DATABASE MyDb SET READ_COMMITTED_SNAPSHOT ON
READ UNCOMMITTED should help, because it doesn't issue shared locks on data that are being retrieved. So, it doesn't bother your other application that intensively updates the data. Another option is to use SNAPSHOT isolation leven on your long-running SELECT. This approach preserves data integrity for selected data, but for a cost of higher CPU, and more intense tempdb usage.
I use sqldeveloper (but this problem has also been duplicated on TOAD, so I don't think it's specifically related to sqldeveloper). The basic problem is after I run a complex SELECT query that uses a database link through sqldeleloper, it will notify that I have changes that need to be rolled back or committed when I go to close my session. The weird part is that I was only running a SELECT query and there are no changes to COMMIT. Can someone explain this behavior to me?
An implicit transaction occurs when selecting over a dblink.
When Oracle performs a distributed SQL statement Oracle reserves an
entry in the rollback segment area for the two-phase commit
processing. This entry is held until the SQL statement is committed
even if the SQL statement is a query
More on this here. I'll try to dig up an Oracle link if I can.
More from the horses mouth:)
Two-Phase Commit Mechanism
A database must guarantee that all statements in a transaction,
distributed or non-distributed, either commit or roll back as a unit.
The effects of an ongoing transaction should be invisible to all other
transactions at all nodes; this transparency should be true for
transactions that include any type of operation, including queries,
updates, or remote procedure calls.
More from Oracle's Distributed Database Concepts guide
What would be the best way to ensure that a SQL query won't alter the data of a database?
In my scenario, you don't have access to the database layer and can only do this logic on the application layer.
Would you recommend using a gem, a ruby custom script?
You can manage the permissions of the users so that they have access for reading the database but they don't have access to alter the database (i.e. not able to insert, update and delete). If you are using mysql, for instance, you can easily do this in phpmyadmin or equivalent tool.
Update based on your change. Even if you only have access through the application you are still connected to the database as a user who has or does not have privileges to update, delete, insert or select and as such the only way to ensure no such queries are executed is to alter that user's permissions.
A simple but far from foolproof method is to employ a blacklist of words that cannot be in the query, such as insert, update, etc.
Alternatively, you could use a parser on the sql query that will provide you with the necessary information to derive whether or not to allow the query.
I would take option 1 only as a last resort or if your checking needs are relatively simple.
On the database layer, make sure that the user the Rails app is accessing the database as only has the access that you desire, perhaps only SELECT.
Sequel has support for read only slave databases with a writable master database. Read-only slaves handle SELECT queries, other queries are done by the master database.
Maybe you can just setup master database as nil?
Another approach could be using hooks (before_save) to prevent writing to the database.
Is there a difference between the two?
For example within a hibernate transaction we can access the database, run some java code and then access the database again. We can't do that within a transaction done via SQL can we? Is this the difference?
The 2 directly relate to each other - a Hibernate transaction maps to and controls the JDBC (database) transaction.
You can do the same thing with direct JDBC / SQL, without Hibernate - though you'll need to call Connection.setAutoCommit(false) to get started. Otherwise, by default, a commit is called after each statement - making each statement run in its own transaction.
Some additional details are available at http://docs.oracle.com/javase/tutorial/jdbc/basics/transactions.html.
I'm wondering if it is possible to run multiple DDL statements inside a transaction. I'm specially interested on SQL Server, even though answers with other databases (Oracle, PostgreSQL at least) could also be interesting.
I've been doing some "CREATE TABLE" and "CREATE VIEW" for the created table inside a transaction and there seems to be some inconsistencies and I'm wondering if the DDLs shouldn't be done inside the transaction...
I could probably move the DDL outside the transaction but
I'd like to get some reference for this. What I have found this far:
MSDN page Isolation Levels in the Database Engine tells clearly that there are restrictions on what DDL operations can be performed in an explicit transaction that is running under snapshot isolation - but I'm not using snapshot isolation and this should result as an error.
This could be interpreted so that DDL operations can be performend in an explicit transaction under different isolation levels?
Oracle® Database Gateway for SQL Server User's Guide#DDL Statements states that only one DDL statement can be executed in a given transaction - is this valid also for SQL Server used straight?
For Oracle:
Within SO question Unit testing DDL statements that need to be in a transaction it is said that Oracle does implicit commit for a DDL statement? (even though no references)
If it matters something, I'm doing this with Java through the JTDS JDBC driver.
b.r. Touko
I know most databases have restrictions, but Postgres doesn't. You can run any number table creations, column changes and index changes in a transaction, and the changes aren't visible to other users unit COMMIT succeeds. That's how databases should be! :-)
As for SQL Server you can run DDL inside of a transaction, but SQL Server does not version metadata, and so changes would be visible to others before the transaction commits. But some DDL statements can be rolled back if you are in a transaction, but for which ones work and which ones don't you'll need to run some tests.
If you are creating tables, views, etc on the fly (other than table variables or temp tables), you may truly need to rethink your design. This is not stuff that should normally happen from the user interface. Even if you must allow some customization, the DDL statements should not be happening at the same time as running transactional inserts/updates/deletes. It is far better to separate these functions.
This is also something that needs a healthy dose of consideration and testing as to what happens when two users try to change the structure of the same table at the same time and then run a transaction to insert data. There's some truly scary stuff that can happen when you allow users to make adjustments to your database structure.
Also some DDL statements must always be the first statement of a batch. Look out for that too when you are running them.
For the general case and IIRC, it's not safe to assume DDL statements are transactional.
That is to say, there is a great deal of leeway on how schema alterations interact within a transaction (assuming it does at all). This can be by vendor or even by the particular installation (i.e., up to the dba) I believe. So at the very least, don't use one DBMS to assume that others will treat DDL statements the say.
Edit: MySql is an example of a DBMS which doesn't support DDL transactions at all. Also, if you have database replication/mirroring you have to be very careful that the replication service (Sybase's replication is the norm, believe it or not) will actually replicate the DDL statement.
Could it be that in MS SQL, Implicit transactions are triggered when DDL and DML statements are run. If you toggle this off does this help, use
SET IMPLICIT_TRANSACTIONS
EDIT: another possibility
- You can't combine CREATE VIEW with other statements in the same batch. CREATE TABLE is ok.
You separate batches with GO.
EDIT2: You CAN use multiple DDL in a transaction as long as separated with GO to create different batches.