We generate a lot of DDL views.I want to create a back-up of all the DDL views in the pg_catalog or information_schema which updates it self everyday.
For example:
If the number of views yesterday was 10 and I created 5 more views today, the backup table should update itself from 10 to 15 at a specific time.
You can write a scheduled lambda function that queries to find the number of views, then updates the backup table based on that query. Documentation for how to connect to a Redshift cluster from a lambda function can be found here.
Related
I have two tables: table 1 is disk based storage and table 2 is in memory storage. I create a DML trigger on table 2 and in that trigger, I insert a record into table 1. Will it be possible?
You can't, it's not possible in the same in-memory transaction using mvcc isolation access a disk-based table through the trigger.
For workaround this you could saving to a stage table memory-based inside the trigger and insert or update to table 1 from stage table using update-join between a memory-based-disk and table-based-disk although it cames with some admin to manage and control but works.
DDL Tiggers still doesn't work even SQL 2017.
According to http://blogs.msdn.com/b/sqlcat/archive/2011/10/17/updating-a-database-snapshot.aspx I should be able to successfully execute an INSERT, UPDATE and DELETE against a Database Snapshot.
The idea is to create a view of a table before you create the snapshot, and then create the snapshot, and update the View in the snapshot.
I have tried this on my SQL Server 2014 (v12.0.2269) and I still get the error
Failed to update database "Snapshot2015_07" because the database is read-only.
The reason I am keen for this to work is that financials need to be frozen at a particular date, but need to be updated if errors are found in the snapshot.
Has anyone had success recently doing this?
I know there are alternatives like AutoAudit, but it is a lot of work to implement for 1-2 updates/deletes on a database with multiple tables with 5 million + rows
The view has to specify the database name (which is the original database name, not the snapshot database name), along with the schema and table name. Ensure the view you created specifies those three parts of the fully qualified object name.
I want to create a plsql procedure which should get executed at 6 pm everyday and whole Data Of a day which is in a Temporary Table should Be Migrated to a base Table. After Successful Migration of Data it should Display a Count Of rows processed.
Your question is not much clear, what i understood is you wanted some data operation to be performed at specific time. For that i would suggest you to use Scheduler JOB's with Oracle. For more Details for creating/scheduling/stopping job refer this --> http://docs.oracle.com/cd/E11882_01/server.112/e25494/scheduse.htm#ADMIN12384
Working on redesigning some databases in my SQL SERVER 2012 instance.
I have databases where I put my raw data (from vendors) and then I have client databases where I will (based on client name) create a view that only shows data for a specific client.
Because of the this data being volatile (Google Adwords & Google DFA) I typically just delete the last 6 days and insert 7 days everyday from the vendor databases. Doing this gives me comfort in knowing that Google has had time to solidify its data.
The question I am trying to answer is:
1. Instead of using views, would it be better use a 'SELECT INTO' statement and DROP the table everyday in the client database?
I'm afraid that by automating my process using the 'DROP TABLE' method will not scale well longterm. While testing it myself, it seems that performance is improved because it does not have to scan the entire table for the date range. I've also tested this with an index on the 'date' column and performance still seemed better with the 'DROP TABLE' method.
I am looking for best practices here.
NOTE: This is my first post. So I am not too familiar with how to format correctly. :)
Deleting rows from a table is a time-consuming process. All the deleted records get logged, and performance of the server suffers.
Instead, databases offer truncate table. This removes all the rows of the table without logging the rows, but keeps the structure intact. Also, triggers, indexes, constraints, stored procedures, and so on are not affected by the removal of rows.
In some databases, if you delete all rows from a table, then the operation is really truncate table. However, SQL Server is not one of those databases. In fact the documentation lists truncate as a best practice for deleting all rows:
To delete all the rows in a table, use TRUNCATE TABLE. TRUNCATE TABLE
is faster than DELETE and uses fewer system and transaction log
resources. TRUNCATE TABLE has restrictions, for example, the table
cannot participate in replication. For more information, see TRUNCATE
TABLE (Transact-SQL)
You can drop the table. But then you lose auxiliary metadata as well -- all the things listed above.
I would recommend that you truncate the table and reload the data using insert into or bulk insert.
I am trying to understand the tempDB and following are the doubts popping in my mind.
What is the lifetime of data in tempDB? Say a query is doing some Order By and uses tempDB for performing that. After this query finishes, someone else also executes a query which utilizes the tempDB. Will the second query find records written by first query in the tempDB or will they be deleted?
Are there any visible tables created inside the tempDB by the Sql Engine? How can I know which temporary table is created because of this query? Is there any naming convention followed by the Sql engine for naming these temporary tables?
I am new to tempDB so please pardon me for asking such silly (if at all) questions :-)
It will be very nice if someone can point me to a good resource which can help me learn about tempDB.
Temp table is stored in tempdb until the connection is dropped (or in the case of a global temp tables when the last connection using it is dropped). You can also (and it is a good practice to do so) manually drop the table when you are finished using it with a drop table statement.
No, others cannot see your temp tables if they are local temp tables (They can see and use global temp tables) Multiple people can run commands which use the same temp table name but they will not be overlapping in a local temp table and so you can have a table named #test and so can 10,000 other users, but each one has its own structure and data.
You don't want to generally look up temp tables in tempdb. It is possible to check for existence, but that is the only time I have ever referenced tempdb directly. Simply use your temp table name. Example below of checking for existence
IF OBJECT_ID('TempDB.dbo.#DuplicateAssignments') IS NOT NULL
BEGIN
DROP TABLE #DuplicateAssignments
END
You name temp tables by prefacing the name with # (for local tables the ones you would use 999.9% of the time) and ## for global temp tables, then the rest of the name you want.
There's a few MSDN articles that are probably the best source of information on the tempDB database in SQL Server.
tempdb Database
The tempdb system database is a global
resource that is available to all
users connected to the instance of SQL
Server and is used to hold the
following:
Temporary user objects that are explicitly created, such as: global or
local temporary tables, temporary
stored procedures, table variables, or
cursors.
Internal objects that are created by the SQL Server Database Engine, for
example, work tables to store
intermediate results for spools or
sorting.
Row versions that are generated by data modification transactions in a
database that uses read-committed
using row versioning isolation or
snapshot isolation transactions.
Row versions that are generated by data modification transactions for
features, such as: online index
operations, Multiple Active Result
Sets (MARS), and AFTER triggers.
Operations within tempdb are minimally
logged. This enables transactions to
be rolled back. tempdb is re-created
every time SQL Server is started so
that the system always starts with a
clean copy of the database. Temporary
tables and stored procedures are
dropped automatically on disconnect,
and no connections are active when the
system is shut down. Therefore, there
is never anything in tempdb to be
saved from one session of SQL Server
to another. Backup and restore
operations are not allowed on tempdb.
There's also tempdb and Index Creation, this blog post along with Working with tempdb in SQL Server 2005 which states:
The SQL Server system database, tempdb, has undergone a number of changes in SQL Server 2005. There are new tempdb usages and internal optimizations in SQL Server 2005; tempdb architecture is mostly unchanged since SQL Server 2000.
The tempdb system database is very similar to a user database. The main difference is that data in tempdb does not persist after SQL Server shuts down.
The temporary tables created in TempDB are dropped when the query is completed.
I'm not sure on this (I would have to try it), but I think theoretically ALL tables created in TempDB are visible, although only the user that created the table has permission to access it.