The Experts below are selected from a list of 498 Experts worldwide ranked by ideXlab platform

Ching-hsien Hsu - One of the best experts on this subject based on the ideXlab platform.

  • Fault-tolerant system design on cloud logistics by greener Standbys deployment with Petri net model
    Neurocomputing, 2017
    Co-Authors: Fuu Cheng Jiang, Ching-hsien Hsu
    Abstract:

    The cost-aware exploration on enhancing fault-tolerant becomes an important issue of service quality from cloud platform. To approach this goal with greener design, a novel Server backup strategy is adopted with two types of Standby Server with warm Standby and cold Standby configurations. On such two-level Standby scheme, cost elaboration has been explored in terms of deployment ratio between warm Standbys and cold Standbys. The cold Standbys provide a greener power solution than those of conventional warm Standbys. The optimal cost policy has been proposed to maintain regulated quality of service for the cloud customers. On qualitative study, a Petri net is developed and designed to visualize the whole system operational flow. On quantitative research for decision support, the theory of finite source queue is elaborated and relevant comprehensive mathematical analysis on cost pattern has been made in detail. Relevant simulations have been conducted to validate the proposed cost optimization model as well. On green contribution, the saving of power consumption has been estimated on the basis of switching warm Standbys into cold Standbys, which amounts for the reduction of CO2emission. Hence the proposed approach indeed provides a feasibly Standby architecture to meet cloud logistic economy with greener deployment.

Fuu Cheng Jiang - One of the best experts on this subject based on the ideXlab platform.

  • Fault-tolerant system design on cloud logistics by greener Standbys deployment with Petri net model
    Neurocomputing, 2017
    Co-Authors: Fuu Cheng Jiang, Ching-hsien Hsu
    Abstract:

    The cost-aware exploration on enhancing fault-tolerant becomes an important issue of service quality from cloud platform. To approach this goal with greener design, a novel Server backup strategy is adopted with two types of Standby Server with warm Standby and cold Standby configurations. On such two-level Standby scheme, cost elaboration has been explored in terms of deployment ratio between warm Standbys and cold Standbys. The cold Standbys provide a greener power solution than those of conventional warm Standbys. The optimal cost policy has been proposed to maintain regulated quality of service for the cloud customers. On qualitative study, a Petri net is developed and designed to visualize the whole system operational flow. On quantitative research for decision support, the theory of finite source queue is elaborated and relevant comprehensive mathematical analysis on cost pattern has been made in detail. Relevant simulations have been conducted to validate the proposed cost optimization model as well. On green contribution, the saving of power consumption has been estimated on the basis of switching warm Standbys into cold Standbys, which amounts for the reduction of CO2emission. Hence the proposed approach indeed provides a feasibly Standby architecture to meet cloud logistic economy with greener deployment.

Tiwari, Vijay Kumar - One of the best experts on this subject based on the ideXlab platform.

  • Microsoft SQL Database Mirroring
    Journal of Advanced Research in Information Technology Systems & Management, 2018
    Co-Authors: Tiwari, Vijay Kumar
    Abstract:

    Database reflecting was presented with Microsoft SQL Serve innovation that can be utilized to outline highaccessibility and elite answers for database excess. It is intended to keep up a hot Standby Server with a transitionally predictable duplicate of the database. Reflecting is practical, rapid, requires no exceptional equipment, and guarantees value-based consistency. This article will portray the distinctive methods of database reflecting and how it is not quite the same as different advancements. Here won’t get into the specifics of the improvements, however, will take an abnormal state voyage through SQL Server Mirroring ideas. In database reflecting, exchange log records are sent straightforwardly from the important database to the mirror database. This stays up with the latest with the primary database, with no loss of submitted information. On the off chance that the main Server fizzles, the mirror Server consequently turns into the new important Server and recuperates the central database utilizing a witness Server under highaccessibility mode. We will examine these modes later. On a very basic level to compress there are three languages to comprehend – the Principal database is the dynamic live database that backings every one of the charges, Mirror is the hot Standby and witness which takes into account a majority if there should be an occurrence of the programmed switchover. In database reflecting, the exchange log records for a database are specifically exchanged starting with one Server then onto the next, subsequently keeping up a hot Standby Server. As the essential Server composes the database’s log cradle to circle, it all the while sends that piece of log records to the mirror case. The mirror Server ceaselessly applies the log records to its duplicate of the database. Reflecting is actualized on a for each database premise, and the extent of security that it gives is limited to a solitary client database. Database reflecting works just with databases that utilization the full recuperation demonstrate. The straightforward and mass logged recuperation models don’t bolster database reflecting. Similarly as with log shipping, in the database reflecting you should guarantee that all database conditions exist on the Standby Server so the framework can work accurately in case of a failover to the mirror Server

Brian R Hitchcock - One of the best experts on this subject based on the ideXlab platform.

  • sybase database administrator s handbook
    1995
    Co-Authors: Brian R Hitchcock
    Abstract:

    1. Standard Server and Server. Machine Environment. You Are Not Alone Anymore. The MultiServer Environment. Why You Should Have a Standard Configuration. Standard for Overall Environment. Standard Configuration for All Server and DBA Machines. Standard Configuration for Servers. 2. Replication Server. Overview. What Replication Server Does. What Replication Server Doesn't Do. Example of the Process of Replicating Data. Configuration Issues. Installing Replication Server. Creating a Subscription. Users and Passwords. How Replication Server Links with SQL Servers. Affects on Existing and New Applications. Capacity Planning. Administration Using Replication Server Manager. Failure Modes. Function Strings. 3. Installation of SQL Server from Scratch. Preparing for Installation. Sybconfig for SQL Server. Sybinit for SQL Server System. Post sybconfig (sybinit for System 10). Sybconfig (sybinit for System 10) Errors. 4. Physical Server Design. Physical Disks. Raw Partitions vs. File Systems. SQL Server Logical Disk Devices. Disk Partitioning. Disk Controllers. Initializing Server Devices. Final Notes on disk init. Database Segments. Mirroring Server Devices. How to Layout the Devices and Segments of a Server. Summary. 5. Documenting a Server. The Servermap and Why You Need. Generating Servermap for Existing SQL Server. Generating Servermap for New SQL Server. Server Configuration. Database Usage and Relative Importance. Server Health. Server Machine Configuration. The Database System. 6. Physical Database Implementation. Transaction Log on Separate Server Device. Transaction Log Not on Separate Device. Sizing the Transaction Log. Placing a Database on Disks and Controllers. Placing Databases on Disks and Controllers. Mirroring Priorities. Why You Should Be Hesitant to Add Database Space. 7. The master Database Is Special. The master Database and Master Device. Sizing the Master Device. The logsegment of the master Database. Master Device Name and Mirroring. Master Device and disk init. Master Device and Default Server Disk Devices. Loading a Database Dump of the master Database. Moving Master Device to the Larger Partition. Clearing Server Configuration in master Database. 8. SQL Server Recovery. Recovery Planning Revolves Around the Cost of Downtime. The Database is Nothing without the Transaction Log. Recovery Is Transaction Based. Standby Server Strategies. Master Database Is Not for Users. The Use of dbcc. Mirroring. Archiving. More Server Devices Are Better. Recovery Notes. Database Dumps. Transaction Log Dumps. Logical Dumps and DataTools SQL BackTrack. Recovery Matrix. 9. Performance and Tuning. Theory Is Nice. What You Can Do in the Real World. Indexes and Queries. Spreading Segments Over Server Devices. Spreading Individual Tables. Archiving. Decision Support Server. Standard Set of Application Transactions. SQL Monitor. SQL Server Performance Tools. Application-Transparent Server Tuning. Preventing Downtime. Servermap and Performance and Tuning. 10. Capacity Planning. The Overall Database System. The Individual Server. Real-World Example. Capacity Planning for the Database System. 11. Operational Details of SQL Server. Interfaces File. Communication Among Servers. Creating Stored Procedure from SQL Script or defncopy Output. What sysusages Means. Reading the Errorlog. Impacts of Creating a New Database. Modifying System Tables Manually. bcp Command. Full Transaction Log or Other Segment (1105 Error). 12. Database Administration Versus Database System Size. Small Database Systems. Large Database Systems. Very Large Database Systems. Summary. 13. Upgrading SQL Server. Installation Guide, Release Notes, and EBF Cover Letter. Sybase Technical Support. Risks of the Upgrade Process. EBF Upgrades. Version Upgrades. Preparing to Upgrade 4.9.x to System. Upgrading 4.9.x to System 10. Post Upgrade 4.9.x to System 10. Actual Upgrade Output 4.9.x to System 10. Regressing from Failed System 10 Upgrade. Dependencies. 14. Transitioning to System 10. System 10 Changes to SQL Server. Transition to System 10 Won't Happen All at Once. SQL Server Upgrade Dependencies. Changes that Affect Existing Applications. Changes that Affect DBA. Compatibility with Other Sybase Products. Server Login Passwords. Server Login 'sa' versus Server Logins with sa_role. Backup Server. 15. Scripts. Dump Database Transaction Log (dumplog). Dump Databases for SQL Server 4.9.x (dumpdb). Load Databases for SQL Server 4.9.x (loaddb). Update statistics on All Tables (update_statistics_all_tables). Dump Commands to Recreate Databases (dump_db_create). Run dbcc Checks (checkdb). Dump Data from System Tables (dump_systables). Create Stored Procedure to Generate Database Creation Script (p_dbcreate). Create Stored Procedure to Check Mirrors (p_mirror). Create Stored Procedure to Output Device Space (p_devspace). Create Stored Procedure to Output All Segments on Devices (p_Servermap). Dump Databases for SQL Server System 10 (dumpdb_sys10_tape_disk). Load Databases for SQL Server System 10 (loaddb_sys10). Server Startup Script RUN_<Servername). 16. Recommended Reading. SQL Server Books. SQL Books. Database Design/Tuning Books. UNIX Books. System Administration Books. Data Modeling Books. Magazines. General. Index.

Sebastian Meine - One of the best experts on this subject based on the ideXlab platform.

  • fundamentals of sql Server 2012 replication
    2013
    Co-Authors: Sebastian Meine
    Abstract:

    It is a common requirement to make data that lives on one Server available on another. You might want to speed up cross-Server queries by providing a local copy of the data. You might want to make the data available to resource intensive reporting queries without affecting the OLTP load, maybe even with an intentional delay in synchronization, so that reports run against complete days only. You may wish to replicate a complete database to a secondary 'Standby' Server for high availability. In each case, SQL Server Replication is a viable option, and Fundamentals of SQL Server 2012 Replication provides the hands-on introduction you need to get started, and explores all of the technology's most important strengths and weaknesses. It will help you make an informed decision on whether replication is the right feature for your requirements, and on which type of replication most appropriate. Equally, it offers guidance on when to avoid replication in favor of features such as simple log shipping, or the "Always On" feature set. This is a practical guide, with all major concepts illustrated with exercises.